Dusk’s PLONK vulnerability: a privacy layer with a $600,000 market cap was almost broken through by a forged proof
After I read the security report disclosed by OtterSec on April 30, 2026, I just sat there for about five minutes. The dusk-plonk verifier had never verified the four polynomial commitments provided by the prover. In simple terms, an attacker could forge a fake zero-knowledge proof to mint DUSK tokens and transfer illicit proceeds without any real assets. This is a privacy protocol designed for regulated financial markets, yet its cryptographic core contains a flaw that enables attackers to create tokens out of thin air. This is a foundational infrastructure that claims to give institutions confidence in putting things on-chain—while such a basic defect exists in the privacy layer.
The compliance narrative in the whitepaper looks great, but the code nearly left an infinite minting backdoor. You could say the vulnerability has been fixed. But a vulnerability like this appearing in the validation step of the privacy layer is a slap in the face of the project’s “privacy-first” positioning. A project that makes money from ZK had trouble with its ZK implementation. After reading the report, the first question that popped into my head was—if a privacy chain built on ZK has this kind of bug in its ZK implementation, what else can possibly go right? Dusk’s market cap has already fallen quite a bit from its peak; the $600,000 figure, when translated to the token’s price at the time, means that if the attacker used this vulnerability to mint large amounts of tokens, the price could be directly smashed through. @Dusk
I pulled up a Dusk audit report and skimmed it. The auditor was Dust Labs. The audit scope only covered some modules—was the dusk-plonk verification logic included within that scope? I couldn’t find a clear statement. If the core privacy-layer code was omitted from the audit, or if the audit simply didn’t cover it, then the value of that audit report needs to be reassessed. Audits aren’t something you do once and then you’re done.
I’m not saying Dusk can’t be trusted, but for a project that writes “privacy” into its name, to have such a fundamental vulnerability in the most core ZK verification layer, it’s hard for me to convince myself to keep holding it. Let’s wait until the cryptographic core has gone through a few more rounds of verification. For now, I’m putting it back on my watch list to see whether any new vulnerabilities are disclosed afterward. If the same module breaks again, then it won’t just be a technical problem—it’ll be a process problem. #dusk $DUSK
After I read the security report disclosed by OtterSec on April 30, 2026, I just sat there for about five minutes. The dusk-plonk verifier had never verified the four polynomial commitments provided by the prover. In simple terms, an attacker could forge a fake zero-knowledge proof to mint DUSK tokens and transfer illicit proceeds without any real assets. This is a privacy protocol designed for regulated financial markets, yet its cryptographic core contains a flaw that enables attackers to create tokens out of thin air. This is a foundational infrastructure that claims to give institutions confidence in putting things on-chain—while such a basic defect exists in the privacy layer.
The compliance narrative in the whitepaper looks great, but the code nearly left an infinite minting backdoor. You could say the vulnerability has been fixed. But a vulnerability like this appearing in the validation step of the privacy layer is a slap in the face of the project’s “privacy-first” positioning. A project that makes money from ZK had trouble with its ZK implementation. After reading the report, the first question that popped into my head was—if a privacy chain built on ZK has this kind of bug in its ZK implementation, what else can possibly go right? Dusk’s market cap has already fallen quite a bit from its peak; the $600,000 figure, when translated to the token’s price at the time, means that if the attacker used this vulnerability to mint large amounts of tokens, the price could be directly smashed through. @Dusk
I pulled up a Dusk audit report and skimmed it. The auditor was Dust Labs. The audit scope only covered some modules—was the dusk-plonk verification logic included within that scope? I couldn’t find a clear statement. If the core privacy-layer code was omitted from the audit, or if the audit simply didn’t cover it, then the value of that audit report needs to be reassessed. Audits aren’t something you do once and then you’re done.
I’m not saying Dusk can’t be trusted, but for a project that writes “privacy” into its name, to have such a fundamental vulnerability in the most core ZK verification layer, it’s hard for me to convince myself to keep holding it. Let’s wait until the cryptographic core has gone through a few more rounds of verification. For now, I’m putting it back on my watch list to see whether any new vulnerabilities are disclosed afterward. If the same module breaks again, then it won’t just be a technical problem—it’ll be a process problem. #dusk $DUSK
