NEAR Intents gab am 1. Oktober 2026 einen Exploit in Höhe von etwa 3,8 Mio. USDT auf der BNB Chain bekannt, bei dem der Vorfall auf einen Fehler in der Interaktion zwischen seiner Omni-Einzahlungs- und Auszahlungsinfrastruktur und dem NEAR Intents Smart Contract zurückzuführen ist.
Der Vorfall betraf die Cross-Chain-Schicht rund um NEAR Intents, nicht die NEAR Protocol Layer 1 selbst. NEAR erklärte, dass das Netzwerk weiterhin Blöcke produzierte und Transaktionen ohne Ausfallzeiten verarbeitete, während NEAR Intents die Dienste einstellte und die Schwachstelle im Vertrag behob. Die genaue Fehlerklasse und die fehlerhafte Komponente wurden bis zum 2. Oktober noch nicht veröffentlicht, doch die verfügbaren Fakten deuten auf eine kritische Grenze bei der Brücken-Buchhaltung und der Autorisierung von Auszahlungen hin.
Wesentliche Erkenntnis: Der NEAR Intents $3,8M Exploit zeigt, warum die Sicherheit von Brücken nachweisen muss, dass jede Asset-Freigabe einer echten, eindeutigen und zuvor nicht verwendeten Einzahlung oder Belastung über alle verbundenen Chains entspricht. Ein gepatchter Smart Contract ist notwendig, aber der vollständige Schutz muss Relayer, Infrastruktur der Brücke, Signatorkontrollen und Abgleich-Logik abdecken.
Was geschah während des NEAR Intents Exploits?
NEAR Intents verlor etwa 3,8 Mio. USDT auf der BNB Chain, nachdem Angreifer einen Fehler in der Interaktion zwischen Omni-Einzahlungs- und Auszahlungsinfrastruktur und dem NEAR Intents Smart Contract ausgenutzt hatten. Die Abflussaktion war vor der öffentlichen Bekanntmachung sichtbar, während NEAR Intents die Dienste stoppte, das Vertragssystem patchte und versicherte, dass die betroffenen Nutzer vollständig entschädigt werden würden.
On-Chain-Aktivitäten deuten darauf hin, dass während des Nachmittags am 30. September US Eastern Time kleine Überweisungen von 10 USDT und 11 USDT den ausgelaugten Vertrag verließen. Diese kleinen Überweisungen sind typisch für eine Validierungsphase, in der ein Angreifer testet, ob ein Auszahlungs-, Buchungs- oder Freigabepfad wie erwartet funktioniert, bevor er größere Extraktionen versucht.
Danach folgten fünf größere Überweisungen, die vom 30. September 23:54 UTC bis zum 1. Oktober 06:08 UTC liefen. Diese Überweisungen lagen jeweils zwischen etwa 35.000 US-Dollar und 1,5 Mio. US-Dollar. Die Sicherheitsanalyse schätzte den Verlust auf 3,865 Mio. US-Dollar aus einem Hot Wallet der BNB Smart Chain, während eine separate On-Chain-Spur etwa 3,87 Millionen USDT sammelte, die vom ausgelaugten Vertrag stammten.
Am 1. Oktober gegen 12:53 UTC gab NEAR Intents den Exploit öffentlich bekannt. Das Protokoll teilte mit, dass die Dienste nach ungewöhnlicher Aktivität durch SHIELD eingestellt wurden, und die Fehlerbehebung im Infrastruktur-Contract innerhalb von etwa einer Stunde umgesetzt wurde. Es wurde erwartet, dass Ein- und Auszahlungen in 11 Netzwerken für ungefähr weitere 12 Stunden ausgesetzt bleiben, während die Infrastruktur repariert wurde.
| Phasen der Vorfalls | Datum oder Uhrzeit | Konkretes Ereignis | Sicherheitsrelevanz |
|---|---|---|---|
| Erste Tests | 30. September, Nachmittag US Eastern Time | 10 USDT und 11 USDT verließen den ausgelaugten BNB Chain Contract | Kleine Transfers können auf eine ausnutzbare Freigabemöglichkeit hinweisen |
| Hauptablauf beginnt | 30. September, 23:54 UTC | Erste größere Überweisung startet | Der Exploit wechselt vom Testen in die eigentliche Extraktion |
| Hauptablauf endet | 1. Oktober, 06:08 UTC | Fünfte größere Überweisung abgeschlossen | Der sichtbare Ausnutzungszeitraum erstreckte sich über mehrere Stunden |
| Öffentliche Bekanntmachung | 1. Oktober, ca. 12:53 UTC | NEAR Intents kündigte abgebrochene Dienste und einen Fehler in der Infrastruktur-Contract-Interaktion an | Die Kommunikation des Vorfalls erfolgte nach der On-Chain-Ausbeute |
| Rückgabefrist angekündigt | 2. Oktober, 00:18 UTC | Es wurde ein 48-Stunden-Zeitraum gesetzt, um Gelder zurückzugeben | Die Frist endete ungefähr am 4. Oktober, 00:18 UTC |
Das öffentlich genannte betroffene Asset war USDT auf der BNB Chain. Dieser Umfang ist relevant, weil er einen Unterschied zwischen einem Vorfall in der Anwendung und Infrastruktur der Brücke und einem Kompromiss des NEAR-Base-Netzwerks beziehungsweise einem generellen Fehler aller NEAR Intents-Assets macht.
NEAR Intents hatte über 30 Mrd. US-Dollar über etwa 35 Blockchains verarbeitet, mit einem Dashboard, das am 22. September ein Allzeitvolumen von 31,4 Mrd. US-Dollar anzeigt. Systeme dieser Größenordnung erfordern nicht nur sichere Smart Contracts. Sie benötigen auch konsistente Zustandsannahmen über Chains hinweg, Betreiber der Brücke, Abwicklungskontrakte, Überwachungssysteme und Betriebsstopp- Verfahren.
Wie bewegt NEAR Intents normalerweise Assets zwischen Chains?
NEAR Intents verarbeitet nutzergerichtete Cross-Chain-Ergebnisse über seinen intents.near Verifier-Contract, der ein Ledger der eingezahlten Token-Salden führt, diese bei Swap-Transaktionen aktualisiert und Token nur durch Auszahlungen und Brückenpfade freigibt. Der Exploit betraf die Grenze, an der Einzahlungs- und Auszahlungsinfrastruktur mit dieser Abwicklungsschicht interagiert.
Ein Nutzer von NEAR Intents signiert ein angestrebtes Ergebnis, anstatt jeden Ausführungsschritt direkt anzugeben. Solver und Market Maker konkurrieren um die Erfüllung dieses Ergebnisses, und das ausgewählte Resultat wird on-chain bestätigt. Dieses Modell kann die Cross-Chain-Ausführung verbessern, schafft aber auch eine breite Vertrauens- und Verifikationsfläche: Das Abwicklungs-Ledger muss korrekt erkennen, was eingezahlt, was getauscht und was ausgezahlt werden kann.
Die NEAR Intents Dokumentation nennt drei Brückensysteme mit unterschiedlichen Vertrauensmodellen:
- Omni Bridge, betrieben von Near One.
- POA Bridge.
- HOT Bridge.
Das Design der HOT Bridge ist besonders relevant für die Vorfallsanalyse, da die öffentliche Analyse den ausgelaugten BNB Chain Contract als das HOT-Bridge-Treasury-Address identifiziert hat, das in der NEAR Intents Dokumentation aufgelistet ist, anstatt das primäre NEAR Intents Vault. Diese Verbindung ist eine Analyse und keine endgültige offizielle Ursachenfeststellung, und NEAR Intents hatte bis zum 2. Oktober nicht bestätigt, welche Komponente ausgefallen war.
Im HOT Bridge verwahren Locker-Contracts auf jeder unterstützten Chain native Assets. Ein Contract auf NEAR prägte entsprechende omni-Token im Verhältnis 1:1. Validator-MPC-Signaturen autorisieren Einzahlungen und Auszahlungen, wobei jede Nonce eindeutig sein muss.
Diese Architektur weist mehrere unverhandelbare Sicherheitsmerkmale auf:
- Eine Freigabe auf BNB Chain muss einer echten Sperre, Belastung oder endgültigen Rechtfertigung entsprechen.
- Eine Einzahlungsmeldung darf nach Ausführung nicht wiederverwendbar sein.
- Die Zustimmung eines Signers muss an die exakte Chain, Asset, Empfänger, Betrag und Nonce gebunden sein.
- Eine Auszahlungsanfrage darf nicht nur akzeptiert werden, weil ein externer Baustein sie für gültig hält.
- Das Treasury-Guthaben muss kontinuierlich gegen das Ledger und den autorisierten Bridge-Status abgeglichen werden.
Nach unserer Erfahrung bei Soken sind die gefährlichsten Brücken-Ausfälle an Systemgrenzen. Ein Vertrag kann seine lokalen Regeln korrekt durchsetzen, doch trotzdem Assets freigeben, weil eine upstream-Nachricht, ein Off-Chain-Dienst oder eine Cross-Chain-Buchhaltungsvoraussetzung ohne ausreichende unabhängige Überprüfung akzeptiert wurde.
Die 11 pausierten Netzwerke entsprechen der HOT-Bridge-Chaionliste in der NEAR Intents Dokumentation: BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll und Plasma. Ethereum, Base, Arbitrum, Solana und Bitcoin waren nicht pausiert. Diese Matching-Chain-Listen stützen eine HOT-Bridge-F Hypothese, beweisen aber nicht die genaue verwundbare Komponente.
Was ist über den Fehler bekannt, was bleibt unklar?
NEAR Intents hat bestätigt, dass ein Fehler in der Interaktion zwischen Omni-Einzahlungs- und Auszahlungsinfrastruktur und dem NEAR Intents Smart Contract besteht, aber bis zum 2. Oktober wurde die genaue Komponente oder die Fehlerklasse noch nicht offengelegt. Jede Behauptung, das Problem sei eindeutig eine Signatur-Bypass, Replay-Fehler, Buchhaltungsfehler oder Validatoren-Kompromittierung, geht über die verfügbaren Beweise hinaus.
Der Begriff “Interaktion” ist zentral. Es legt nahe, dass die Schwachstelle nicht notwendigerweise eine einfache isolierte Programmierfehler im einzelnen Contract ist. Cross-Chain-Systeme versagen häufig, wenn zwei einzeln vernünftige Komponenten sich über die Bedeutung, Endgültigkeit oder Einzigartigkeit eines Zustandsübergangs uneinig sind.
Zum Beispiel kann eine Bridge-Ausgangsroute scheitern, wenn eine Off-Chain-Komponente eine Genehmigung für ein Ereignis ausgibt, das nie final war, wenn ein Contract eine Auszahlungsnachricht akzeptiert, ohne sie dauerhaft zu verbrauchen, oder wenn die Buchhaltungsschicht einen Saldo gutgeschrieben hat, den der zugrunde liegende Locker tatsächlich nicht erhalten hat. Das sind unterschiedliche technische Mechanismen, aber sie teilen die gleiche Sicherheitsfehlfunktion: Assets werden freigegeben, ohne dass ein äquivalent gesperrtes Asset oder eine gültige Belastung vorliegt.
Das Ereignis von NEAR Intents ähnelt in seiner Grundform mehreren großen Bridge-Vorfällen, bleibt aber in seinen bestätigten Details unterschiedlich.
| Vorfall | Datum | Gemeldeter Verlust | Bestätigte Fehlerform |
|---|---|---|---|
| Wormhole | Februar 2022 | Ca. 325 Mio. US-Dollar | Ein Signaturüberprüfungsfehler erlaubte die Fälschung der Guardian-Genehmigung und das Minten von 120.000 wETH ohne Sicherheit |
| Nomad | August 2022 | Ca. 190 Mio. US-Dollar | Ein Upgrade setzte die vertrauenswürdige Root auf Null, wodurch jede Nachricht als bewiesen behandelt wurde |
| Kelp DAO über LayerZero | April 2026 | Ca. 292-293 Mio. US-Dollar | Eine 1-zu-1-Verifizierer-Konfiguration erlaubte eine Phantom-Burn-Transaktion, um Mittel auf Ethereum freizugeben |
| Liquid Network | 6. September 2026 | Ca. 320 Mio. US-Dollar | Ein Fehler im Range-Proof-Überprüfungs-Cache ermöglichte ungesicherte L-BTC, an echtes BTC gekoppelt zu werden |
| NEAR Intents | 1. Oktober 2026 | Ca. 3,8 Mio. US-Dollar | Ein bestätigter Fehler in der Interaktion zwischen Omni-Einzahlungs- und Auszahlungsinfrastruktur und dem NEAR Intents Smart Contract |
Wormhole, Nomad, Kelp DAO und Liquid Network teilen ein ähnliches Fehlermuster bei der Freigabezustand. Hier akzeptierte eine Brücke eine Gutschrift, einen Beweis oder eine Nachricht, die nicht zu einer echten Sperrung oder Belastung führte. Bei NEAR Intents wurde noch nicht bestätigt, dass der Exploit am 1. Oktober genau diesem Mechanismus folgte, aber sein Kontext im Zusammenhang mit der Brücken-Treasure macht diese Unterscheidung zur wichtigsten, die ein Post-Mortem ansprechen sollte.
Ronin Bridge ist ein nützlicher Kontrast. Der Vorfall im März 2022 bei Ronin betraf den Kompromiss von 5 der 9 Validator-Schlüssel. Das ist in erster Linie ein Problem des Schlüsselmanagements und der Validatoren-Schwelle, nicht ein Fall, bei dem ein Contract fälschlicherweise eine ungesicherte Gutschrift als legitim erkannt hätte.
NEAR Intents hat sich verpflichtet, eine formale Verifikation in den Veröffentlichungsprozess zu integrieren. Formal Methods sind besonders wertvoll, wenn sie genutzt werden, um Bridge-Invarianten direkt zu codieren: eine gültige Auszahlungsanweisung darf die endgültige Berechtigung eines Nutzers nicht übersteigen, eine Auszahlungsanweisung darf nicht doppelt ausgeführt werden, und aggregierte Freigaben dürfen die verifizierte Unterstützung über die Bridge nicht übersteigen.
Für Protokolle, die eine ähnliche Infrastruktur entwerfen, sollten technische Sicherheitsprüfungen den gesamten Ablauf von Einzahlung bis Freigabe testen, anstatt jeden Contract, Service oder Signer-Bereich als separate Sicherheitsgrenze zu behandeln.
Warum sind die Reaktions- und Eindämmungsmaßnahmen entscheidend?
NEAR Intents begrenzte den Vorfall, indem es die Dienste nach der Entdeckung ungewöhnlicher Aktivitäten durch SHIELD stoppte, die Schwachstelle im Vertrag innerhalb von etwa einer Stunde patchte und Ein- sowie Auszahlungen auf 11 betroffenen Netzwerken pausierte. Schnelle Eindämmung beschränkt weitere Abzüge, aber eine vollständige Wiederherstellung hängt von der Nachverfolgung, rechtlicher Eskalation und dem Nachweis ab, dass die wieder gestarteten Brückenflüsse die korrigierte Sicherheitsinvariante erfüllen.
Der sofortige Dienststopp war eine angemessene Reaktion auf die Unsicherheit. Wenn ein Cross-Chain-Auszahlungsweg möglicherweise ungesicherte Freigaben erzeugt, kann das Fortsetzen des normalen Betriebs einen begrenzten Exploit in eine umfassendere Depletion des Treasury verwandeln. Die Abwägung ist eine erhebliche Störung für legitime Nutzer, weshalb Brücken-Pausensteuerungen granular, probenartig und beobachtbar sein sollten.
NEAR Intents gab bekannt, dass es den Vorfall den Strafverfolgungsbehörden gemeldet hat und mit Sicherheits- sowie Blockchain-Analysep Partnern zusammenarbeitet, um die Gelder nachzuverfolgen und die Rückführung zu verfolgen. Öffentliches Reporting deute darauf hin, dass Diebesgut auf KuCoin überwiesen und in Bitcoin gehoben wurde. Eine separate Spur fand etwa 1,5 Mio. USDT, die durch den CoW Protocol Settlement Contract bewegt wurden.
Ein Vertreter von NEAR Intents gab dem Exploitierer ein 48-Stunden-Fenster, um die Gelder zurückzugeben, veröffentlichte Rückgabeadressen auf Bitcoin, BNB Chain und Solana und bot keine Staking- oder Belohnungs-Reward an. Bis zum 2. Oktober wurde keine Rückführung oder Rückzahlung angekündigt.
Das Verpflichtung zur Entschädigung ist ebenfalls relevant. NEAR-Mitbegründer Illia Polosukhin erklärte, dass alle betroffenen Nutzer voll kompensiert werden. Diese Zusage adressiert die Auswirkungen auf die Kunden, ersetzt jedoch nicht die technische Anforderung, einen genauen Post-Mortem- und Behebungsbericht zu veröffentlichen, bevor die betroffenen Routen wiederhergestellt werden.
Ein nützliches Paket nach einem Vorfall sollte umfassen:
- Die exakte verwundbare Komponente und Fehlerklasse.
- Die Änderungen an Smart Contracts und Infrastruktur, die den Exploit-Pfad entfernen.
- Ob eine Nachricht, Nonce, Ledger, Signer oder Abgleich-Invariante versagt hat.
- Ergebnisse unabhängiger Überprüfungen der Reparatur.
- Ein schrittspezifischer Wiederherstellungsplan für BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll und Plasma.
- Überwachungsregeln, die dieselbe abnormale Auszahlungsform frühzeitig erkennen.
Der Vorfall wirft auch governance- und betriebliche Fragen auf, die über den Code hinausgehen. Die Veröffentlichung von Rückgabeadressen, das Nachverfolgen von Geldern, Koordination mit Börsen, Nutzerentschädigungen und Zusammenarbeit mit Strafverfolgungsbehörden beinhalten rechtliche und Offenlegungsentscheidungen. Teams, die Brückenwiederherstellungsverfahren entwickeln, sollten technische Kontrollen mit rechtlicher und Compliance-Unterstützung abstimmen, insbesondere bei Fragen zu Custody, Nutzeransprüchen, Sanktionsprüfungen oder grenzüberschreitender Rückführung.
Was sollten Cross-Chain-Teams nach dem NEAR Intents Vorfall ändern?
Cross-Chain-Teams sollten jede Brücken-Auszahlung als einen Beweis für die Wertkonservierung behandeln: Die Freigabe muss an eine verifizierte Sperre oder Belastung, eine eindeutige Nachricht, ein bestimmtes Ziel und einen Höchstbetrag gebunden sein. Der NEAR Intents Vorfall zeigt, dass Überwachung und Notabschaltungen essentiell sind, aber Prävention darauf beruht, ungültige Zustände in der Cross-Component-Logik unmöglich zu machen.
Die erste technische Aufgabe besteht darin, die Kern-Invariante der Brücke in Geschäfts- und Techniksprache zu definieren. Für ein HOT-Bridge-System ist die Invariante nicht nur “die MPC-Signatur ist gültig”. Sie ist eher: “Diese genaue Auszahlung ist einmal genehmigt, für dieses Asset und Empfänger, nach einer entsprechenden finalisierten und ungenutzten Einzahlung oder Ledger-Belastung.”
Diese Invariante muss in verschiedenen Fehlerfällen getestet werden:
- Duplizierte Nachrichten und Nonce-Wiederverwendung;
- Mismatched Chain-Identifikatoren;
- Nicht übereinstimmende Token-Adressen oder Dezimalumrechnungen;
- Veraltete Signer-Genehmigungen;
- Teilweise Infrastruktur-Ausfälle;
- Inkonsistente Ledger- und Locker-Salden;
- Übergänge beim Notbetrieb;
- Replay-Versuche nach Upgrades oder Contract-Migrationen.
Zweitens sollten Protokolle die Erkennung von Vertrauen trennen. SHIELD konnte bei NEAR Intents ungewöhnliche Aktivitäten erkennen, was die Eindämmung erleichterte. Doch Überwachung sollte nicht die einzige Barriere gegen Buchhaltungsfehler und Treasury-Verlust sein. Ein Überwachungssystem sollte verdächtiges Verhalten erst erkennen, wenn es beginnt. Contract- und Bridge-Verification-Regeln sollten ungültige Wertbewegungen ablehnen, noch bevor eine Überweisung ausgeführt wird.
Drittens sollten Teams Reconciliation-Mechanismen implementieren, die Quell-Chain-Sperren, Abrechnungs-Credits im Ledger, Ziel-Chain-Freigaben und ausstehende Auszahlungsgenehmigungen vergleichen. Eine Diskrepanz sollte automatisch Grenzen einschränken oder die betroffene Route anhalten. Diese Kontrolle ist insbesondere für Hot-Wallets und Treasury-Routen wichtig, bei denen eine plausible Transaktion sonst schnell flüssige Assets bewegen könnte.
Viertens sollte formale Verifikation sich auf Eigenschaften konzentrieren, die für das Geschäftsmodell der Brücke relevant sind, nicht nur auf arithmetische Sicherheit. NEAR Intents’ Vorhaben, formale Verifikation einzusetzen, ist grundsätzlich richtig, wenn es um Zustandsübergänge bei Einzahlungen, Solver Settlement, Erzeugung von Bridge-Nachrichten und Ausführung von Auszahlungen geht. Ein formaler Beweis einer einzelnen Contract-Funktion reicht nicht aus, wenn externe Infrastruktur-Komponenten der Funktion falsche, akzeptierte Voraussetzungen füttern können.
Das Forschungszentrum von Soken untersucht wiederkehrende Fehler in Smart Contracts und die Sicherheitsmuster von Protokollen, einschließlich des Unterschieds zwischen lokalen Contract-Prüfungen und systemweiten Sicherheitsgarantien. Für Brücken-Teams lautet die praktische Lektion: Audit-Umfang muss Contracts, Nachrichtenformate, Signer-Policy, operative Kontrollen, Überwachungs-Telemetrie und Recovery-Prozeduren umfassen.
NEAR Intents muss nun sein angekündigtes Post-Mortem in einen verifizierbaren Wiederherstellungsplan umwandeln: die fehlerhafte Interaktion identifizieren, demonstrieren, warum der gepatchte Pfad keine ungesicherte USDT mehr freigeben kann, und jede wiederaufgenommene HOT-Bridge-Route unabhängig testen. Teams, die vergleichbare Cross-Chain-Infrastruktur betreiben, sollten damit beginnen, jede Auszahlungsgenehmigung ihrer zugrunde liegenden Sperre oder Belastung zuzuordnen, und prüfen, ob diese Verbindung auch bei Wiederholungen, Verzögerungen, Upgrades und adversarialer Nachrichtenreihenfolge Bestand hat.