Top 3 Sicherheitsvorfälle im Juni
Die drei größten Vorfälle im Juni gingen nicht auf einen einzelnen Fehler zurück. Sie legten ein gemeinsames Versagen offen. Nach außen hin schienen Sicherheitsgarantien intakt, doch im Verborgenen wurden sie nie tatsächlich durchgesetzt. Ein MEV-Bot vertraute Trades, die profitabel erschienen, ohne zu prüfen, ob Allowances wirklich verbraucht worden waren. Zwei eingestellte Rollups akzeptierten Beweise, die formal gültig waren, aber nie an den Settlement-Zustand gebunden waren, den sie vorzugeben behaupteten. Der Signing-Code einer Wallet ließ stillschweigend die eine geheime Eingabe fallen, von der seine Sicherheit abhing, und verwandelte einen Wert, der unvorhersehbar sein sollte, in etwas, das jeder aus öffentlichen Daten neu berechnen konnte. Keines dieser Systeme wurde durch kryptanalytische Brute-Force-Angriffe gebrochen. Sie wurden durch eine Annahme gebrochen, die niemand jemals überprüft hatte.
JaredFromSubway: ~$15M
Am 20. Juni 2026 wurde JaredFromSubway, ein Ethereum-MEV-Bot-Betreiber, durch einen Honeypot-Angriff um approximately $15M geleert.
Der Angreifer baute eine gefälschte Trading-Umgebung mit gefälschten Wrapper-Token und gefälschten Uniswap-V2-ähnlichen Pools, die realistische Swap- / Sync-Events emittieren. In einem legitimen Ablauf sollte die wrapTo()-Funktion des Wrapper-Contracts intern transferFrom() auf dem zugrunde liegenden echten Token aufrufen und dabei die zuvor vom Bot erteilte Allowance verbrauchen. Der gefälschte Wrapper-Token-Contract übersprang diesen Schritt jedoch vollständig und lieferte dennoch einen kleinen, vom Angreifer konstruierten Gewinn über unwrap() zurück. Da der Bot nicht überprüfte, ob Allowances tatsächlich verbraucht wurden, und keine verbleibenden Genehmigungen widerrief, häuften sich unverbrauchte Allowances an und wurden später über withdraw() abgeschöpft. Eine betroffene Wallet verlor ungefähr 1.474,58 WETH, 2.870.573 USDC und 2.035.760 USDT. JaredFromSubway meldete später einen Gesamtverlust von approximately $15M über alle betroffenen Wallets.
Die Lehre daraus ist, dass MEV-Bots unbekannten Token- und Pool-Code als feindlich behandeln müssen, auch wenn Simulationen profitabel erscheinen. Automatisierte Strategien erfordern strenge Spender-Allowlists, Code-Hash-Prüfungen, Allowance-Verifizierung nach dem Trade sowie die Bereinigung verbleibender Genehmigungen.
Aztec Legacy Rollup-Vorfälle: ~$4,35M
Im Juni 2026 wurden zwei separate Legacy-Aztec-Deployments ausgenutzt, was zusammen zu Verlusten von approximately $4,35M führte. Obwohl die Grundursachen verschieden waren, ereigneten sich beide Vorfälle an der Grenze zwischen Beweisvalidität und Settlement-Semantik.
Der erste Vorfall traf Aztec Connects RollupProcessorV3 am 14. Juni 2026 und verursachte Verluste von approximately $2,15M. Der Angreifer setzte numTxs auf 1, während er eine echte Einzahlung in einen späteren, dekodierten Slot schmuggelte, sodass der Beweispfad den Wert intern gutschrieb, während die L1-Settlement-Logik den entsprechenden decreasePendingDepositBalance()-Aufruf überging. Der Angreifer zog das daraus resultierende ungedeckte Guthaben anschließend über normale Kanäle ab.
Der zweite Vorfall traf ein separates Legacy-PrivateRollupBridge-/RollupProcessor-Deployment am 18. Juni 2026 und verursachte Verluste von etwa $2,2M. Dieses Deployment hatte noch einen escapeHatch(bytes,bytes,bytes)-Pfad offen, und sein Circuit schränkte die private Join-Split-Membership-Root nie dahingehend ein, dass sie mit dem öffentlichen oldDataRoot übereinstimmen musste, der von L1 konsumiert wird. Dies erlaubte dem Angreifer, den Besitz hochwertiger Notes in einem gefälschten privaten Baum zu beweisen, während er den echten L1-dataRoot als öffentliche Root veröffentlichte. Der Verifier akzeptierte den Beweis, und der L1-Contract führte die Auszahlung aus.
Zusammen zeigen diese Vorfälle, dass die Beweisverifizierung allein nicht ausreicht. Jeder Wert, der Settlement-Grenzen regelt, muss an die genauen öffentlichen Eingaben gebunden sein, die der Beweis verifiziert, und jeder private Witness muss explizit so eingeschränkt werden, dass er mit dem öffentlichen Zustand übereinstimmt, den das Settlement tatsächlich konsumiert.
SecondFi: ~$2,4M
Am 23. Juni 2026 legte SecondFi (früher Yoroi), eine von EMURGO entwickelte Browser-Wallet-Erweiterung, einen kritischen Fehler in seiner Ed25519-Signing-Implementierung offen, der die Versionen v10.0.3 bis v10.0.6 betrifft.
Der fehlerhafte Code leitete die Signing-Nonce ausschließlich aus der öffentlichen Transaktionsnachricht ab und ließ dabei ein erforderliches geheimes Nonce-Präfix weg. Dadurch wurde die Signaturgleichung auf eine einzige Unbekannte reduziert, sodass jeder den privaten Schlüssel einer Wallet direkt aus öffentlichen On-Chain-Daten rekonstruieren konnte. Zwei Angreifer nutzten den Fehler unabhängig voneinander aus und leerten approximately $2,4M (16M ADA) aus 374 Wallets, bevor EMURGO weitere 129M ADA rettete.
Die Lehre daraus ist, dass Wallet-Signing-Code die gleiche Sorgfalt wie kryptografische Verfahren auf Protokollebene erfordert. Das Weglassen einer einzigen geheimen Eingabe – selbst einer, die unbedeutend erscheint – kann private Schlüssel vollständig kompromittieren. Daher sollten benutzerdefinierte Ed25519-Implementierungen einem unabhängigen Audit unterzogen werden, anstatt wie eine Standardbibliothek als vertrauenswürdig eingestuft zu werden.
Ehrenwerte Erwähnung: Zcash Orchard Soundness-Bug
Es schaffte es nicht in die Top-3-Rangliste, da keine Ausnutzung bestätigt wurde, aber Zcashs Orchard-Soundness-Bug war eine der bedeutendsten Offenlegungen im Juni. Der am 4. Juni 2026 öffentlich bekannt gegebene Bug war eine fehlende Gleichheitsbeschränkung im Orchard-Shielded-Pool-Circuit, die es ermöglicht hätte, dass dieselbe geschützte Note unterschiedliche Nullifier erzeugt und mehr als einmal ausgegeben wird. Der Fehler existierte seit der Aktivierung von Orchard im Mai 2022 und wurde durch das NU6.2-Notfall-Upgrade behoben.
Der Vorfall bekräftigt die tiefere Lehre aus dem Aztec-Fall. In einem ZK-System hängt die Sicherheit davon ab, was der Circuit tatsächlich einschränkt – nicht davon, was das umgebende Protokoll annimmt, dass er einschränkt.
Den Zcash Orchard Bug-Analyse lesen
Die obigen Informationen basieren auf Daten vom 00:00 UTC, 1. Juli 2026.
Damit endet der Sicherheitsvorfalls-Bericht für Februar.
Weitere Informationen finden Sie in unserer Bibliothek der Sicherheitsvorfälle.
Bleiben Sie informiert und bleiben Sie sicher!
