Sharing this because I’m genuinely interested in how other security researchers would assess it.
I recently had two independent prover soundness bugs confirmed and fixed by a project. The review process was professional, communication was clear, and they stayed within their stated SLA. I genuinely appreciate the time they invested in reviewing both reports.
The team explained that the findings were classified as Low because, under the current architecture, exploitation would require control of privileged proving infrastructure. They also explicitly acknowledged that the same class of bugs could become Critical once permissionless proving is introduced.
Personally, I understand the reasoning, but I’m curious how other auditors and whitehats look at this type of issue.
From a security engineering perspective, how would you normally classify confirmed prover soundness vulnerabilities where the underlying cryptographic soundness is broken, but the current deployment architecture limits practical exploitation?
I’m interested in technical reasoning rather than opinions on any specific project. Curious to hear how others approach severity in cases like this.#bugbounty
A bug bounty report should not be closed solely because it “looks AI-written.”
If the finding is invalid, explain why.
If it is out of scope, explain why.
If the PoC fails, explain why.
But technical reports should be judged on evidence, not writing style. @immunefi
I struggle to find and send valid bugs on @immunefi , invest time and effort into finding and validating them, send them, just to be ghosted, lowballed, disrespected, while criminals just steal the money, and get paid
> checks note
~$3M as "whitehat bounty" ...
This triggers me, really. I still have an Immunefi mediation which was open back on Feb 10, where the protocol HAS NOT RESPONDED ANYTHING, although they FIXED the bug in January ...
Literally, the protocol did not reply anything about the mediation, although it was open more than 3 months ago, and the bug was fixed more than 4 months ago.
This is how whitehats get treated and below you can see how criminals are treated as "whitehats"
🤡🌎
If this issue was truly known for months, then the responsible path was clear:
acknowledge the report, confirm duplicate scope, explain remediation status, and ensure downstream ZK Stack chains were protected or notified.
Silence followed by a one-line close is not enough for a Critical protocol issue.
8 days ago I submitted a Critical ZKsync Era report through Immunefi.
It concerns a protocol-level issue where authenticated transaction intent and execution semantics can diverge for a class of Ethereum-compatible transactions.
I’m not publishing technical details because this may affect live protocol paths.
But the handling deserves scrutiny.
🧵
Responsible disclosure is a two-way process.
Researchers should not publish live exploit details.
Projects should not leave Critical reports unacknowledged, then close them as “known internally” without explaining duplicate scope, remediation status, or whether live/downstream deployments are protected.