Zum Hauptinhalt springen
dontkyc.me Logo
Scam-Pattern der Woche: "Inflation-Bugs" – wenn ein Software-Fehler Millionen aus dem Nichts erzeugt

Scam-Pattern der Woche: "Inflation-Bugs" – wenn ein Software-Fehler Millionen aus dem Nichts erzeugt

D dontkyc.me Team • 22.10.2026 • 5 Min. Lesezeit • 2 Aufrufe
Teil der Serie: Scam-Pattern der Woche

Am 28. August 2026 registriert ein Angreifer bei der Privacy-Kryptowährung Zano eine sogenannte Gateway-Adresse und nutzt eine Schwachstelle in genau dieser Funktion aus. Am 29. August und erneut am 25. September erzeugt er auf diesem Weg rund 36,9 Millionen ZANO sowie etwa 1,8 Billiarden des stabilen Zano-Tokens fUSD – aus dem Nichts, unautorisiert, nicht von echten Coins zu unterscheiden. Keine sechs Wochen später, am 14. Oktober 2026, passiert bei der Privacy-Kryptowährung Pirate Chain etwas auffällig Ähnliches: Ein Angreifer nutzt zwei Validierungslücken nahe einer kurz zuvor aktivierten Protokoll-Erweiterung, um rund 39,8 Millionen ARRR unautorisiert zu erzeugen – eine Erhöhung der umlaufenden Menge um etwa 20 Prozent an einem einzigen Tag.

Zwei verschiedene Projekte, zwei verschiedene Programmiersprachen, zwei verschiedene technische Schwachstellen – aber ein auffällig ähnliches Muster, sowohl beim Angriff selbst als auch bei der Reaktion danach. Genau dieses Muster lohnt sich zu verstehen, wenn du in kleinere oder mittelgroße Kryptoprojekte investierst oder sie nutzt.

Das Muster: eine Funktion, die eigentlich niemand missbrauchen können sollte

Bei beiden Vorfällen steckte der Fehler nicht in einer offensichtlich riskanten Stelle wie einer Exchange-Hot-Wallet, sondern tief in einer Funktion, die Coins überhaupt erst entstehen lässt. Bei Zano war es eine sogenannte Gateway-Adresse – eine Funktion, über die sich normalerweise legitime Vorgänge wie Swaps abwickeln lassen, die aber unter bestimmten Bedingungen auch das unbegrenzte Erzeugen neuer Coins erlaubte. Bei Pirate Chain lag der Fehler in der transparenten Buchhaltungsschicht nahe einer erst am 3. Oktober 2026 aktivierten Protokoll-Erweiterung namens "Ironwood", wo unter anderem eine eigentlich vorgesehene Prüfung der Emissionsgrenze umgangen werden konnte.

Beide Fälle teilen damit einen Kern: Je komplexer und "privilegierter" eine Funktion im Coin-Erzeugungsprozess ist, desto größer der Schaden, wenn genau dort ein Fehler übersehen wird – und desto wichtiger wird es, wie frisch und wie gründlich geprüft diese Funktion war. Die Pirate-Chain-Lücke saß ausgerechnet in einer Erweiterung, die erst elf Tage zuvor live gegangen war; neue, noch wenig in der Praxis erprobte Protokoll-Änderungen sind erfahrungsgemäß ein überdurchschnittlich häufiger Ort für genau solche Fehler.

Die Reaktion: kein Admin-Knopf, sondern ein Vertrauensvorschuss von allen

Noch bemerkenswerter als der Angriff selbst ist, wie beide Projekte reagierten – nämlich gerade nicht mit einem einfachen "Wir setzen das zurück"-Beschluss des Teams. Bei Zano veröffentlichte das Kernteam zwar eine gepatchte Node-Version, wirksam wurde der rund einmonatige Rollback der Blockchain aber erst dadurch, dass die Mehrheit der unabhängigen Node-Betreiber diese Version tatsächlich übernahm. Kein einzelner Akteur – auch nicht das Entwicklerteam selbst – konnte das Netzwerk im Alleingang zurücksetzen.

Bei Pirate Chain verlief es sogar noch holpriger: Ein zunächst angekündigter Rollback-Plan wurde kurz danach öffentlich für technisch nicht durchführbar erklärt. Erst durch das gemeinsame, freiwillige Vorgehen von Community, Node-Betreibern, Mining-Pools, Börsen und den sogenannten dPoW-Notaren sowie ein verpflichtendes Software-Update (v6.0.14) ließ sich die Kette am Ende doch auf den Block vor dem Angriff zurücksetzen und die unrechtmäßig erzeugten Coins entfernen.

Diese Holprigkeit ist kein Zufall, sondern ein strukturelles Merkmal dezentraler Netzwerke: Ein Rollback ist dort keine Funktion, die jemand per Knopfdruck auslöst, sondern ein Vertrauensvorschuss, den ein Großteil unabhängiger Teilnehmer gemeinsam geben muss. Das macht die Reaktion zwar widerstandsfähiger gegen einen einzelnen böswilligen Akteur – es bedeutet aber auch: In beiden Fällen waren zwangsläufig auch legitime, in der Zwischenzeit abgewickelte Transaktionen vom Rollback betroffen, und die Wiederherstellung von Nutzer-Guthaben läuft bei Zano über Entwicklungsfonds und Teammittel statt über eine saubere technische Rückabwicklung.

Was das für dich als Nutzer bedeutet

Ein Inflation-Bug ist kein Phishing-Trick, den du durch Wachsamkeit allein vermeiden kannst – die Verwundbarkeit liegt im Code des Projekts selbst, nicht in deinem Verhalten. Trotzdem gibt es ein paar Dinge, die das Risiko für dich senken:

1
Mit frisch aktivierten Protokoll-Erweiterungen zurückhaltend sein. Wenn ein Projekt gerade erst eine neue, größere Funktion live geschaltet hat, ist das statistisch ein überdurchschnittlich wahrscheinlicher Zeitpunkt für genau solche Fehler – nicht, weil das Projekt unseriös wäre, sondern weil neuer Code naturgemäß weniger in der Praxis erprobt ist.
2
Auf Audit-Historie und Bug-Bounty-Programme achten. Projekte, die ihre Kernfunktionen regelmäßig unabhängig prüfen lassen und offene Bug-Bounty-Programme betreiben, reduzieren – ohne Garantie – die Wahrscheinlichkeit, dass genau solche Lücken erst nach einem echten Angriff auffallen.
3
Verstehen, dass ein Rollback bei einer dezentralen Kette dauert und wehtut. Anders als bei einer zentralen Börse, die im Zweifel selbst entscheidet, braucht ein Rollback bei einer echten Blockchain die freiwillige Mitwirkung eines Großteils der Netzwerkteilnehmer. Das kann Tage bis Wochen dauern und betrifft im Zweifel auch deine eigenen, völlig legitimen Transaktionen aus diesem Zeitraum.
4
Größere Bestände nicht in einem einzigen, frisch gepatchten Netzwerk konzentrieren. Gerade nach einem bekannt gewordenen Vorfall ist Geduld sinnvoller als Panik – aber auch sinnvoller als sofortiges blindes Vertrauen in den ersten Patch, bevor sich das Netzwerk tatsächlich stabilisiert hat.

Was das mit uns zu tun hat

Wir listen beide Vorfälle mit allen hier beschriebenen Details auch im jeweiligen Dienst-Eintrag, inklusive Quellenangaben und Auswirkung auf die Bewertung. Das ist kein Grund, Zano oder Pirate Chain pauschal zu meiden – beide Projekte haben transparent kommuniziert und den Schaden durch koordiniertes, dezentrales Handeln tatsächlich begrenzt, was selbst nicht selbstverständlich ist. Es ist aber ein gutes Beispiel dafür, warum wir bei dontkyc.me nicht nur erfassen, ob ein Dienst KYC verlangt oder deine Daten sammelt, sondern auch, was einem Projekt technisch schon passiert ist und wie es damit umgegangen ist. Gerade bei kleineren, aber ambitionierten Privacy-Coins lohnt sich dieser Blick zusätzlich zur reinen Datenschutz-Frage.

Quellen: CryptoTimes, Pirate-Chain-Update nach 39,8-Mio.-Exploit, CryptoTimes, Rollback-Plan zunächst verworfen, KuCoin News, Rollback auf Block 4.176.944, CryptoBriefing – sowie der bei uns bereits erfasste Zano-Vorfall vom 28.08.–25.09.2026.

Teilen:
War dieser Artikel hilfreich?

0 Kommentare

Melde dich an, um zu kommentieren.

Anmelden

Noch keine Kommentare. Sei der Erste!