0 sats \ 0 replies \ @ek OP 13 Jan freebie \ parent \ on: Zap to Zero Day 16 | Mad World meta
I see. I am sorry that I assumed based on your comment that you did indeed test this and verified that it's a vulnerability before replying; especially since it turned out to be a correct hypothesis.
However, I welcome people trying to break our code so the issue isn't necessarily with (responsibly) testing it.
What is important to me is that people disclose vulns (even potential ones) in a manner that does not put us into a situation where we are pressured to immediately fix something since the vuln was essentially fully disclosed [0] before we were made aware of it:
With the full disclosure approach, the full details of the vulnerability are made public as soon as they are identified. This means that the full details (sometimes including exploit code) are available to attackers, often before a patch is available. The full disclosure approach is primarily used in response or organisations ignoring reported vulnerabilities, in order to put pressure on them to develop and publish a fix.
-- Vulnerability Disclosure Cheat Sheet
What do you think would have been reasonable? Did you evaluate the impact such a bug could have in the wrong hands before writing this?
You can DM me on SimpleX (see my profile) or follow the instructions in the FAQ or README.
Anyway, no hard feelings; just wanted to mention this for the next time. Also wanted to mention this for everyone else reading.
[0] I consider your comment a full disclosure since your comment includes enough information to trigger the infinite withdrawal loop by anyone reading it. The severity of that loop is a topic that we could have discussed and compensation is based on that.