Verus Ethereum Bridge Exploit: Dezelfde Bug van $11.58M
Op 18 mei 2026 plunderde iemand de Verus-Ethereum-bridge voor $11,58 miljoen. Volgens de berichtgeving van CoinDesk was het de achtste bridge-hack van het jaar. De Verus Ethereum-bridge-exploit betrof geen exotische nieuwe aanvalscategorie. Het was dezelfde fout die we bridges hebben zien verwoesten sinds 2021: het contract gaf middelen vrij op de ene chain zonder correct te verifiëren wat er op de andere werkelijk was gebeurd.
De kwetsbare functie had deze keer een naam. checkCCEValues. Dat is de routine die de cross-chain exportwaarden moest bevestigen voordat er op de Ethereum-kant gemunt of vrijgegeven werd. Die deed zijn werk niet, en de aanvaller liep ermee weg.
Ik heb vier jaar besteed aan het bouwen van bridge-gerelateerde infrastructuur in een gereguleerde context, en het deprimerende is hoe voorspelbaar dit is geworden. We blijven dezelfde wond een nieuwe naam geven.
De Verus Ethereum-bridge-exploit was een bronvalidatiefout
Schrap de branding en elke bridge doet één ding. Hij observeert een gebeurtenis op chain A (een storting, een vergrendeling, een export) en produceert een overeenkomstige actie op chain B (een minting, een ontgrendeling, een vrijgave). Het hele beveiligingsmodel herleidt zich tot één vraag: gelooft chain B daadwerkelijk wat chain A hem vertelde, en heeft hij dat gecontroleerd?
Wanneer de validatie die de bedragen aan de bronkant bevestigt onjuist is, wordt het antwoord "nee". De aanvaller vervalst of vergroot de geclaimde exportwaarde, het doelcontract vertrouwt erop, en tokens die nooit gedekt waren worden gemunt of vrijgegeven. The Block meldde het verlies op ongeveer $11,58 miljoen, weggezogen via precies dit soort boekhoudkundig gat in de cross-chain exportcontrole.
Dit is bronbedragvalidatie in een bridge, en het is de meest dragende functie van het hele systeem. Eén vergelijking fout en de bridge wordt een gratis geldprinter.
checkCCEValues is alleen de nieuwste naam voor een oude kwetsbaarheid
De checkCCEValues-kwetsbaarheid is structureel identiek aan bugs die de sector al miljarden hebben gekost. De namen wisselen. Het mechanisme niet.
- Wormhole, 2022: een gat in de handtekeningverificatie stelde een aanvaller in staat 120.000 wrapped ETH te minten die nooit gestort waren.
- Nomad, 2022: een mislukte initialisatie van de merkle root zorgde ervoor dat elk bericht als geldig werd gevalideerd, waarna de bridge door een menigte werd leeggeplunderd via copy-paste.
- Multichain, 2023: sleutels en vertrouwensaannames die niemand van buitenaf kon verifiëren.
Elk van deze was in de kern hetzelfde: de doelchain gaf waarde vrij zonder een deugdelijk bewijs van de brongebeurtenis. checkCCEValues is de spelling van 2026 van hetzelfde woord.
Ik denk dat de sector dit keer op keer behandelt als individuele technische fouten, terwijl het een categorieprobleem is. Je lost een categorie niet op door één functie beter te auditen.
Tornado Cash financierde de aanvaller, wat iets zegt over de intentie
De wallet van de aanvaller werd via Tornado Cash gefinancierd voordat het misbruik plaatsvond. Dat detail doet er minder toe voor attributie dan voor wat het zegt over de voorbereiding. Dit was geen whitehat die aan een contract prutste en verrast werd door het resultaat. Het patroon van een via Tornado Cash gefinancierde aanvaller is het kenmerk van iemand die dagen van tevoren operationele dekking had opgezet en verwachtte dat de fondsen op de uitweg witgewassen zouden moeten worden.
Dat is het deel dat verdedigers onderschatten. Tegen de tijd dat de exploit-transactie binnenkomt, is de uitweg al gebouwd. Achteraf traceren helpt aanklagers, maar het doet vrijwel niets voor het protocol dat net achtcijferige verliezen heeft geleden.
Bridge-beveiligingsfouten zijn nu een maandelijkse tol
Zoom je uit, dan is de Verus-hack een kostenpost, geen uitzondering. Volgens PeckShield-gegevens geciteerd door Bitcoin.com bedroegen crypto bridge-exploits in mei 2026 alleen al ongeveer $328 miljoen. Acht bridge-incidenten in minder dan vijf maanden van het jaar.
De markt heeft dit stilletjes ingeprijsd als een kostenpost voor cross-chain activiteiten. Dat is de verkeerde les. Een terugkerend negencijferig maandelijks verlies is geen volatiliteit, maar een structureel gebrek dat de ontwerpruimte weigert aan te pakken.
Voor iedereen die echte waarde verplaatst, is de conclusie ongemakkelijk: de meeste bridges zijn vertrouwensaannames in een mathematisch kostuum. Ik heb eerder betoogd, in How Stablecoin Bridges Actually Fail, dat de veiligste bridge vaak degene is die toegeeft hoe weinig hij daadwerkelijk verifieert.
Hoe een daadwerkelijk verdedigbare bridge-controle eruitziet
Als je een bridge bouwt of auditet, is de validatie van het bronbedrag de plek waar je een onevenredig groot deel van je paranoia aan moet besteden. Een aantal zaken die ik als niet-onderhandelbaar beschouw:
- Het doelcontract moet een cryptografisch bewijs van de brongebeurtenis verifiëren, niet op het woord van een relayer afgaan. Light-client- of zk-bewijzen boven multisig-attestaties, waar het latentiebudget het toelaat.
- Bedragcontroles moeten uitputtend zijn op elk pad. De
checkCCEValues-klasse van bugs verbergt zich doorgaans in een branch die sommige invoeren overslaan. Fuzz de vergelijking, bekijk hem niet op het oog. - Rate limits en stroomonderbrekers per asset, zodat een vervalste waarde de hele reserve niet in één transactie kan leegtrekken. Een limiet die automatisch pauzeert bij bijvoorbeeld 5% van de TVL per uur zou de meeste incidenten van 2026 hebben afgezwakt.
- Onafhankelijke invariantmonitoring die het totaal geslagen versus het totaal vergrendelde in realtime bewaakt en stopt bij afwijking.
Niets van dat alles is nieuw. De audit-stack om dit te ondervangen bestaat, en ik ben er dieper op ingegaan in het audit-stack-artikel. Het probleem is dat bridges de validatie blijven uitbrengen als een bijzaak in plaats van als het kernproduct.
De volgende bridge-hack van 2026 is al in de maak. Hij krijgt een andere functienaam en dezelfde grondoorzaak, en we zullen opnieuw verrast doen. Dat zouden we niet moeten.