Der Dusk-PLONK-Fehler – eine Privacy-Layer im Wert von 600.000 US-Dollar wurde fast von einem Proof-Fake durchschlagen
Nachdem ich den Sicherheitsbericht gelesen hatte, den OtterSec am 30. April 2026 offengelegt hat, starrte ich ungefähr fünf Minuten lang. Der Verifizierer von dusk-plonk hat die vier Polynom-Commitments, die vom Prover bereitgestellt werden, nie verifiziert. Einfach gesagt: Angreifer können einen gefälschten Zero-Knowledge-Beweis konstruieren und ohne echte Assets DUSK-Token prägen sowie illegal erzielte Gewinne transferieren. Ein Privacy-Protokoll, das für regulierte Finanzmärkte entwickelt wurde, hat in seinem kryptografischen Kern eine Schwachstelle, die es Angreifern ermöglicht, aus dem Nichts Token zu erzeugen. Eine als Infrastruktur gepriesene Lösung, die Institutionen beim On-Chain-Betrieb Sicherheit geben soll – und doch gibt es auf der Privacy-Layer eine grundlegende Lücke.
Die Compliance-Erzählung im Whitepaper klingt schön, aber im Code war fast eine Hintertür für unbegrenztes Prägen eingebaut. Du kannst sagen, der Bug sei inzwischen gefixt. Aber wenn so eine Schwachstelle auf der Verifikationsstufe der Privacy-Layer auftritt, ist das an sich schon eine Ohrfeige für die Ausrichtung „privacy first“. Ein Projekt, das von ZK lebt, hat Probleme mit seiner ZK-Implementierung. Die erste Frage, die mir nach dem Lesen des Berichts durch den Kopf ging, lautet daher: Wenn eine ZK-basierte Privacy-Chain solche Schwachstellen in der Implementierung hat – was garantiert, dass nicht noch etwas anderes schiefgeht? Duseks Marktkapitalisierung ist vom Allzeithoch aus deutlich gefallen; 600.000 US-Dollar entsprechen zum damaligen Kurs. Wenn Angreifer diesen Bug nutzen und massenhaft Token prägen, könnte der Preis direkt durchgeschlagen werden. @Dusk
Ich habe mir außerdem einen Dusk-Audit-Bericht angesehen. Auditor ist Dust Labs, und der Prüfrahmen deckt nur einen Teil der Module ab. Deckt der Prüfrahmen die Verifizierungslogik von dusk-plonk ab? Dafür habe ich keine eindeutige Aussage gefunden. Wenn der Kerncode der Privacy-Layer im Audit ausgelassen wurde oder das Audit selbst nicht bis zu dieser Stelle vorgedrungen ist, muss der Wert dieses Audit-Berichts neu bewertet werden. Ein Audit ist nicht etwas, das man einmal macht und dann ist es erledigt.
Ich sage nicht, dass Dusk unseriös ist. Aber ein Projekt, das „Privacy“ in den Namen schreibt, und das solche grundlegenden Schwachstellen in der allerwichtigsten ZK-Verifikationsschicht hat – damit kann ich mich schwer überzeugen, weiterzuhalten. Lass erst den kryptografischen Kern nach ein paar weiteren Validierungsrunden neu bewerten. Ich nehme es vorerst wieder auf die Beobachtungsliste und schaue, ob danach noch weitere Schwachstellen offengelegt werden. Wenn in demselben Modul erneut Probleme auftreten, ist das nicht mehr nur ein technisches Problem, sondern ein Prozessproblem.
#dusk $DUSK
Nachdem ich den Sicherheitsbericht gelesen hatte, den OtterSec am 30. April 2026 offengelegt hat, starrte ich ungefähr fünf Minuten lang. Der Verifizierer von dusk-plonk hat die vier Polynom-Commitments, die vom Prover bereitgestellt werden, nie verifiziert. Einfach gesagt: Angreifer können einen gefälschten Zero-Knowledge-Beweis konstruieren und ohne echte Assets DUSK-Token prägen sowie illegal erzielte Gewinne transferieren. Ein Privacy-Protokoll, das für regulierte Finanzmärkte entwickelt wurde, hat in seinem kryptografischen Kern eine Schwachstelle, die es Angreifern ermöglicht, aus dem Nichts Token zu erzeugen. Eine als Infrastruktur gepriesene Lösung, die Institutionen beim On-Chain-Betrieb Sicherheit geben soll – und doch gibt es auf der Privacy-Layer eine grundlegende Lücke.
Die Compliance-Erzählung im Whitepaper klingt schön, aber im Code war fast eine Hintertür für unbegrenztes Prägen eingebaut. Du kannst sagen, der Bug sei inzwischen gefixt. Aber wenn so eine Schwachstelle auf der Verifikationsstufe der Privacy-Layer auftritt, ist das an sich schon eine Ohrfeige für die Ausrichtung „privacy first“. Ein Projekt, das von ZK lebt, hat Probleme mit seiner ZK-Implementierung. Die erste Frage, die mir nach dem Lesen des Berichts durch den Kopf ging, lautet daher: Wenn eine ZK-basierte Privacy-Chain solche Schwachstellen in der Implementierung hat – was garantiert, dass nicht noch etwas anderes schiefgeht? Duseks Marktkapitalisierung ist vom Allzeithoch aus deutlich gefallen; 600.000 US-Dollar entsprechen zum damaligen Kurs. Wenn Angreifer diesen Bug nutzen und massenhaft Token prägen, könnte der Preis direkt durchgeschlagen werden. @Dusk
Ich habe mir außerdem einen Dusk-Audit-Bericht angesehen. Auditor ist Dust Labs, und der Prüfrahmen deckt nur einen Teil der Module ab. Deckt der Prüfrahmen die Verifizierungslogik von dusk-plonk ab? Dafür habe ich keine eindeutige Aussage gefunden. Wenn der Kerncode der Privacy-Layer im Audit ausgelassen wurde oder das Audit selbst nicht bis zu dieser Stelle vorgedrungen ist, muss der Wert dieses Audit-Berichts neu bewertet werden. Ein Audit ist nicht etwas, das man einmal macht und dann ist es erledigt.
Ich sage nicht, dass Dusk unseriös ist. Aber ein Projekt, das „Privacy“ in den Namen schreibt, und das solche grundlegenden Schwachstellen in der allerwichtigsten ZK-Verifikationsschicht hat – damit kann ich mich schwer überzeugen, weiterzuhalten. Lass erst den kryptografischen Kern nach ein paar weiteren Validierungsrunden neu bewerten. Ich nehme es vorerst wieder auf die Beobachtungsliste und schaue, ob danach noch weitere Schwachstellen offengelegt werden. Wenn in demselben Modul erneut Probleme auftreten, ist das nicht mehr nur ein technisches Problem, sondern ein Prozessproblem.
#dusk $DUSK
