NEAR Intents a divulgué une exploitation d’environ 3,8 millions de USDT sur BNB Chain le 1er octobre 2026, en retraçant l’incident à une faille dans l’interaction entre son infrastructure de dépôt et de retrait Omni et le contrat intelligent NEAR Intents.
L’incident a principalement affecté la couche de cross-chain autour de NEAR Intents plutôt que la couche 1 du NEAR Protocol lui-même. NEAR a indiqué que le réseau continuait de produire des blocs et de traiter des transactions sans interruption, tandis que NEAR Intents a interrompu ses services et corrigé la vulnérabilité côté contrat. La classe précise de la faille et le composant exact ayant échoué n’avaient pas été publiés au 2 octobre, mais les faits disponibles pointent vers une faille critique dans la frontière de comptabilité des ponts et d’autorisation de retrait.
Point clé : L’exploitation de 3,8 millions de dollars par NEAR Intents montre pourquoi la sécurité des ponts doit prouver que chaque libération d’actif correspond à un dépôt ou débit réel, unique et non consommé auparavant sur chaque chaîne connectée. Un contrat intelligent corrigé est nécessaire, mais la défense complète doit couvrir les relayeurs, l’infrastructure de pont, les contrôles de signature et la logique de réconciliation.
Que s’est-il passé lors de l’exploitation de NEAR Intents ?
NEAR Intents a perdu environ 3,8 millions de USDT sur BNB Chain après que des attaquants ont exploité une faille dans l’interaction entre l’infrastructure de dépôt et de retrait Omni et le contrat intelligent NEAR Intents. La fuite était visible avant la divulgation publique, tandis que NEAR Intents a suspendu ses services, corrigé la faille côté contrat et a affirmé que les utilisateurs affectés seraient entièrement indemnisés.
L’activité sur la chaîne indique que de petits transferts de 10 USDT et 11 USDT ont quitté le contrat drainé le 30 septembre, heure de l’Est américain. Ces petits transferts sont cohérents avec une phase de validation lors de laquelle un attaquant teste si une voie de retrait, de comptabilisation ou de libération fonctionne comme prévu avant de tenter des extractions plus importantes.
Ensuite, cinq transferts plus importants ont été effectués entre 23:54 UTC le 30 septembre et 06:08 UTC le 1er octobre. Ces transferts variaient d’environ 35 000 $ à 1,5 million de dollars chacun. L’analyse de sécurité a estimé la perte à 3,865 millions de dollars à partir d’un portefeuille chaud sur BNB Smart Chain, tandis que la traçabilité sur la chaîne a trouvé environ 3,87 millions de USDT collectés depuis le contrat drainé.
NEAR Intents a publié la divulgation de l’exploitation vers 12:53 UTC le 1er octobre. Le protocole a indiqué que ses services avaient été arrêtés après que SHIELD a détecté une activité inhabituelle, et la correction du contrat a été déployée en environ une heure. Les dépôts et retraits sur 11 réseaux devaient rester indisponibles pendant environ 12 heures supplémentaires pendant que l’infrastructure était réparée.
| Étape de l’incident | Date ou heure | Événement concret | Pertinence pour la sécurité |
|---|---|---|---|
| Premiers essais | 30 septembre après-midi heure de l’Est américain | 10 USDT et 11 USDT quittent le contrat BNB Chain drainé | De petits transferts peuvent révéler si une voie de libération est exploitable |
| Début de la fuite principale | 30 septembre, 23:54 UTC | Premier des cinq transferts importants commencé | L’exploitation est passée du test à l’extraction |
| Fin de la fuite principale | 1er octobre, 06:08 UTC | Le cinquième transfert important terminé | La période d’extraction visible s’étalait sur plusieurs heures |
| Divulgation publique | 1er octobre, vers 12:53 UTC | NEAR Intents annonce l’arrêt des services et une faille dans l’interaction contrat-infrastructure | La communication est intervenue après la fuite sur la chaîne |
| Déclaration de délai de retour | 2 octobre, 00:18 UTC | Une fenêtre de 48 heures pour revenir les fonds est annoncée | La date limite est autour du 4 octobre, 00:18 UTC |
L’actif concerné rapporté publiquement était l’USDT sur BNB Chain. Ce périmètre est important car il distingue un incident applicatif et infrastructurel de celui d’une compromission du réseau de base NEAR ou d’un échec général de tous les actifs NEAR Intents.
NEAR Intents avait déjà traité plus de 30 milliards de dollars sur environ 35 blockchains, avec un tableau de bord affichant un volume total de 31,4 milliards de dollars au 22 septembre. Des systèmes de cette envergure ne nécessitent pas seulement des contrats intelligents sécurisés. Ils requièrent des hypothèses cohérentes sur l’état à travers les chaînes, les opérateurs de pont, les contrats de règlement, les systèmes de surveillance, et les procédures de pause opérationnelle.
Comment NEAR Intents déplace-t-il normalement des actifs entre chaînes ?
NEAR Intents règle les résultats cross-chain dirigés par l’utilisateur via son contrat intents.near, qui maintient un registre des soldes déposés, met à jour ces enregistrements lors des swaps, et ne libère les tokens que par le biais de retraits et de chemins de pont. L’exploitation concernait la frontière où l’infrastructure de dépôt et de retrait interagissait avec cette couche de règlement.
Un utilisateur de NEAR Intents signe un résultat prévu plutôt que de spécifier directement chaque étape d’exécution. Les solveurs et fabricants de marché se concurrencent pour remplir cet objectif, et le résultat sélectionné est validé sur la chaîne. Ce modèle peut améliorer l’exécution cross-chain, mais il crée aussi une large surface de confiance et de vérification : le registre de règlement doit reconnaître correctement ce qui a été déposé, échangé, et ce qui peut être retiré.
La documentation de NEAR Intents identifie trois systèmes de ponts avec des modèles de confiance différents :
- Omni Bridge, exploité par Near One.
- POA Bridge.
- HOT Bridge.
La conception du HOT Bridge est particulièrement pertinente pour l’analyse de l’incident, car l’analyse publique a identifié le contrat drainé sur BNB Chain comme étant l’adresse du trésor du HOT Bridge listé dans la documentation de NEAR Intents, plutôt que le coffre principal de NEAR Intents. Ce lien est une analyse plutôt qu’un diagnostic final officiel, et NEAR Intents n’avait pas confirmé, au 2 octobre, quel composant avait échoué.
Dans le HOT Bridge, les contrats de verrouillage sur chaque chaîne supportée détiennent des actifs natifs. Un contrat sur NEAR crée des omni-tokens en correspondance un-à-un. Les signatures MPC des validateurs autorisent les dépôts et retraits, et la conception stipule que chaque nonce doit être à usage unique.
Cette architecture possède plusieurs propriétés de sécurité non négociables :
- Une libération sur BNB Chain doit correspondre à un verrou ou débit réel ou à un droit réglé.
- Un message de dépôt ne doit pas pouvoir être réémployé après exécution.
- L’approbation du signataire doit être liée à la chaîne, l’actif, le destinataire, le montant et le nonce précis.
- Une demande de retrait ne doit pas être acceptée simplement parce qu’un composant externe affirme qu’elle est valide.
- Le solde du trésor doit être réconcilié en permanence avec le registre et l’état du pont autorisé.
D’après notre expérience en audit de contrats intelligents chez Soken, les échecs de pont les plus dangereux se produisent aux frontières du système. Un contrat peut faire respecter ses règles locales correctement tout en libérant des actifs parce qu’un message en amont, un service off-chain ou une hypothèse comptable inter-chaînes a été accepté sans vérification indépendante suffisante.
Les 11 réseaux en pause correspondaient à la liste des chaînes du HOT Bridge dans la documentation de NEAR Intents : BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll et Plasma. Ethereum, Base, Arbitrum, Solana et Bitcoin n’étaient pas en pause. Ces listes de chaînes corroborent une hypothèse centrée sur le HOT Bridge, mais ne prouvent pas le composant vulnérable exact.
Que sait-on sur la faille, et que reste-t-il inconnu ?
NEAR Intents a confirmé qu’une faille existait dans l’interaction entre l’infrastructure de dépôt et de retrait Omni et le contrat intelligent NEAR Intents. Cependant, au 2 octobre, NEAR Intents n’avait pas divulgué le composant précis ni la classe de vulnérabilité. Toute assertion selon laquelle le problème était définitivement une faille d’imposture de signature, une vulnérabilité de réutilisation, une erreur de comptabilisation ou une compromission du validateur dépasserait les preuves disponibles.
L’expression « interaction » est centrale. Elle laisse penser que la faille n’était pas nécessairement une simple erreur isolée dans une fonction de contrat unique. Les systèmes cross-chain échouent souvent lorsque deux composants raisonnables individuellement ne s’accordent pas sur la signification, la finalité ou l’unicité d’un changement d’état.
Par exemple, un chemin de libération du pont peut échouer si un composant en amont fournit une approbation pour un événement qui n’a jamais été finalisé, si un contrat accepte un message de retrait sans le consommer définitivement, ou si la couche de comptabilisation crédite un solde que le locker sous-jacent n’a pas réellement reçu. Ce sont des mécanismes techniques distincts, mais ils partagent la même faille de sécurité : des actifs sont libérés sans qu’un actif verrouillé équivalent ou un débit valide n’ait été effectué.
L’événement NEAR Intents ressemble à la forme générale de plusieurs incidents majeurs de ponts, tout en restant distinct dans ses détails confirmés.
| Incident | Date | Perte signalée | Forme de défaillance confirmée |
|---|---|---|---|
| Wormhole | février 2022 | Environ 325 millions de dollars | Une faille de vérification de signature permettait de falsifier l’approbation du gardien et de frapper 120 000 wETH sans collatéral |
| Nomad | août 2022 | Environ 190 millions de dollars | Une mise à niveau a fixé la racine de confiance à zéro, traitant chaque message comme prouvé |
| Kelp DAO sur LayerZero | avril 2026 | Environ 292 à 293 millions de dollars | Une configuration de vérificateur 1-sur-1 a permis un burn phantom pour libérer des fonds sur Ethereum |
| Liquid Network | 6 septembre 2026 | Environ 320 millions de dollars | Un bug de cache de vérification de preuve de plage a permis de peger des L-BTC non adossés vers du BTC réel |
| NEAR Intents | 1er octobre 2026 | Environ 3,8 millions de dollars | Un bug confirmé dans l’interaction infrastructure de dépôt et de retrait Omni avec le contrat intelligent NEAR Intents |
Wormhole, Nomad, Kelp DAO et Liquid Network partagent un même motif de défaillance côté libération : un pont a accepté un crédit, une preuve ou un message qui ne correspondait pas à un verrou ou débit réel. NEAR Intents n’a pas encore confirmé si l’exploitation du 1er octobre a suivi ce mécanisme précis, mais le contexte du trésor du pont en fait la première invariant que l’analyse post-mortem doit traiter.
Ronin Bridge constitue un contraste utile. L’incident Ronin de mars 2022 a impliqué la compromission de 5 des 9 clés de validateurs. Il s’agit principalement d’une défaillance de gestion de clés et de seuil de validateurs, plutôt que d’un cas où un contrat aurait reconnu à tort un crédit non adossé comme légitime.
NEAR Intents s’est engagé à intégrer la vérification formelle dans son processus de déploiement. Les méthodes formelles sont précieuses ici lorsqu’elles sont utilisées pour encoder directement les invariants du pont : une retrait valide ne peut pas dépasser le droit réglé d’un utilisateur, un message de retrait ne peut pas être exécuté deux fois, et les libérations agrégées ne peuvent pas dépasser le soutien vérifié dans tout le système de pont.
Pour les protocoles concevant une infrastructure similaire, les revues de sécurité technique doivent tester l’ensemble du cycle de vie de dépôt à libération plutôt que de considérer chaque contrat, service ou domaine de signataire comme une frontière de sécurité distincte.
Pourquoi les décisions de réponse et de containment sont-elles cruciales ?
NEAR Intents a maîtrisé l’incident en interrompant ses services après que SHIELD a détecté une activité inhabituelle, en corrigeant la faille côté contrat en environ une heure, et en suspendant les dépôts et retraits sur 11 réseaux affectés. Une réponse rapide limite la fuite supplémentaire, mais une récupération complète dépend de la traçabilité, de l’escalade juridique, et de la démonstration que les flux de pont redémarrés respectent l’invariance de sécurité corrigée.
L’arrêt immédiat des services était une réponse appropriée face à l’incertitude. Lorsqu’un chemin de retrait cross-chain peut produire des libérations non adossées, continuer l’exploitation normale peut transformer une fuite limitée en un épuisement général du trésor. Le compromis est une perturbation sévère pour les utilisateurs légitimes, c’est pourquoi les contrôles de pause du pont doivent être granulaires, répétés et observables.
NEAR Intents a indiqué avoir signalé l’incident aux autorités, et travaillé avec des partenaires en sécurité et en analyse blockchain pour tracer les fonds et poursuivre la récupération. Le rapport public a indiqué que les fonds volés ont été envoyés sur KuCoin et transférés sur Bitcoin. Une traçabilité séparée a retrouvé environ 1,5 million de USDT passant par le contrat de règlement CoW Protocol.
Un représentant de NEAR Intents a donné à l’attaquant une fenêtre de 48 heures pour restituer les fonds, publié des adresses de restitution sur Bitcoin, BNB Chain et Solana, sans offrir de prime déclarée. Au 2 octobre, aucune restitution ni calendrier de remboursement n’avaient été signalés.
L’engagement à indemniser compte aussi. Le co-fondateur de NEAR, Illia Polosukhin, a déclaré que tous les utilisateurs affectés seraient indemnisés intégralement. Cet engagement répond à l’impact client, mais ne remplace pas l’obligation technique de publier un post-mortem précis et un dossier de remédiation avant de rétablir les routes affectées.
Un package post-incident utile devrait comprendre :
- Le composant précis vulnérable et la classe de faille.
- Les changements dans le contrat et l’infrastructure qui éliminent la voie d’exploitation.
- Si un message, nonce, registre, signataire, ou invariant de réconciliation a échoué.
- Les résultats de l’audit indépendant pour la réparation.
- Un plan de restauration chaîne par chaîne pour BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll et Plasma.
- Des règles de surveillance permettant de détecter plus tôt un schéma de retrait anormal.
L’incident soulève aussi des questions de gouvernance et d’opération, au-delà du code. La publication d’adresses de retour, la traçabilité des fonds, la coordination avec les échanges, l’indemnisation des utilisateurs, et l’engagement avec les autorités offrent tous des enjeux juridiques et de divulgation. Les équipes préparant des procédures de récupération de pont doivent aligner contrôles techniques et soutien juridique et de conformité, notamment lorsque la garde, les revendications utilisateur, le filtrage des sanctions ou la récupération transfrontalière deviennent pertinents.
Que devraient changer les équipes cross-chain après l’incident NEAR Intents ?
Les équipes cross-chain devraient traiter chaque retrait de pont comme une preuve de conservation de valeur : la libération doit être liée à un verrou ou débit vérifié, à un message unique, à une destination précise et à un montant plafonné. L’incident NEAR Intents montre que la supervision et les arrêts d’urgence sont essentiels, mais la prévention repose sur la impossibilité d’autoriser des états invalides inter-composants.
La première tâche technique est de définir invariant central du pont en termes métier et technique. Pour un système de type HOT Bridge, l’invariant n’est pas simplement « la signature MPC est valide ». Il s’approche plutôt de : « cette retrait exact est autorisé une fois, pour cet actif et ce destinataire, après un dépôt ou un débit de registre correspondant, finalisé et non dépensé. »
Cet invariant doit être testé dans divers scénarios d’échec :
- messages en double et réutilisation de nonce ;
- identifiants de chaîne discordants ;
- adresses de tokens ou conversions décimales incohérentes ;
- approbations de signataires périmées ;
- interruptions partielles d’infrastructure ;
- incohérences entre le registre et le solde des lockers ;
- transitions de pause d’urgence ;
- tentatives de réexécution après des mises à jour ou migrations de contrat.
Deuxièmement, les protocoles doivent séparer la détection de la confiance. SHIELD a détecté une activité inhabituelle lors de l’événement NEAR Intents, ce qui a permis de déclencher le containment. Pourtant, la surveillance ne doit pas être la seule barrière entre une erreur comptable et une perte du trésor. Un système de surveillance doit identifier un comportement suspect après le début. Les règles de vérification des contrats et ponts doivent rejeter les mouvements de valeur invalides avant qu’un transfert ne soit exécutable.
Troisièmement, les équipes doivent bâtir des réconciliations comparant les verrouillages de la chaîne source, les crédits du registre de règlement, les libérations de la chaîne de destination et les autorisations de retrait en attente. Une divergence doit automatiquement réduire les limites ou arrêter la route affectée. Ce contrôle est particulièrement critique pour les chemins de portefeuilles chauds et de trésor, où une transaction présentant une apparence légitime peut autrement déplacer rapidement des actifs liquides.
Quatrièmement, la vérification formelle doit cibler des propriétés essentielles pour le modèle d’affaire du pont, et pas uniquement la sécurité arithmétique. L’engagement de NEAR Intents à intégrer la vérification formelle est pertinent si cela couvre les transitions d’état lors des dépôts, règlements, créations de messages de pont et exécution de retraits. Une preuve formelle d’une fonction de contrat ne suffit pas si un composant externe peut alimenter cette fonction avec une prémisse incorrecte mais acceptée.
Le centre de recherche de Soken étudie les modes récurrents de défaillance de contrats intelligents et de sécurité protocolaires, notamment la différence entre une vérification locale d’un contrat et une garantie de sécurité à l’échelle du système. Pour les équipes de pont, la leçon pratique est constante : le périmètre d’audit doit inclure contrats, formats de message, politique de signataires, contrôles opérationnels, télémétrie de surveillance, et procédures de récupération.
NEAR Intents doit maintenant transformer sa promesse de post-mortem en un plan de restauration vérifiable : identifier l’interaction défectueuse, démontrer pourquoi le chemin corrigé ne peut pas libérer des USDT non adossés, et tester séparément chaque route HOT Bridge reprise. Les équipes en infrastructure cross-chain comparable doivent commencer par cartographier chaque autorisation de retrait à son verrou ou débit sous-jacent, puis vérifier si cette liaison résiste à des tentatives de répétition, retards, mises à jour et ordres de messages adverses.