La société de sécurité CertiK indique qu'une attaque oracle financée par flash loan a faussé un rachat de CoreVault et vidé l'InsurancePool du protocole, transformant une défaillance d'entrée de prix en un événement immédiat de liquidité de rachat sur BNB Smart Chain. Pour les déposants et les fournisseurs de liquidité, la question centrale n'est pas seulement le montant extrait par l'attaquant, mais de savoir si le circuit de rachat, ses garde-fous oracle et le pool de backstop restent utilisables en toute sécurité pendant que le protocole établit les faits.

Ce que CertiK a rapporté

Dans une alerte publiée le 4 novembre 2026, CertiK Alert a indiqué qu'une attaque oracle financée par flash loan a gonflé un rachat de CoreVault d'environ 33 fois. Ce chiffre est une attribution d'une société de sécurité, pas encore un post-mortem de CoreVault confirmé de manière indépendante. Néanmoins, un résultat de rachat d'une telle ampleur est cohérent avec un calcul du protocole recevant un prix ou une entrée de conversion économiquement faussé.

CertiK a en outre déclaré que la manipulation a vidé l'InsurancePool et que l'attaquant a conservé 160,26 BNB — évalués par la société à environ 112,2 K$ — après avoir annulé la transaction. Dans les exploits par flash loan, les positions sont ouvertes et déroulées dans la fenêtre d'exécution d'une seule transaction, de sorte que les produits conservés peuvent différer fortement des fonds bruts ayant transité par le pool affecté. Si cela est exact, la vidange de l'InsurancePool a des implications bien au-delà de l'ampleur de l'extraction : une réserve conçue pour absorber les pertes ou soutenir les rachats ne peut plus être présumée amortir le prochain événement défavorable au bilan.

Séquence rapportée contre enregistrement confirmé

L'alerte de CertiK renvoie à la transaction d'exploit présumée, 0x072a10a579e2a8afa26a681205a2aaaa38f74bcb9d1064b12bd9e9ebe2c598b3, sur BscScan. La trace de l'explorateur n'était pas lisible de manière indépendante au moment de la recherche, de sorte que le chemin complet du flash loan, les appels oracle impliqués, les contrats affectés, les flux de soldes et l'annulation de transaction revendiquée restent non confirmés selon les preuves disponibles.

Dans une conception de vault, un oracle n'a pas besoin d'être la seule entrée comptable pour produire un décalage sévère de rachat. Une entrée compromise ou insuffisamment robuste peut fausser la valeur de l'actif ou le terme de conversion de parts utilisé par la fonction de rachat. Le gonflement du rachat rapporté constitue donc le principal signal de risque observable, tandis que la cause racine précise — dépendance au prix spot, données obsolètes, hypothèses de liquidité faibles ou autre défaillance d'intégration — n'a pas été établie.

Comment les flash loans amplifient le risque de manipulation d'oracle

Un flash loan est un emprunt limité à la transaction : la liquidité est empruntée, utilisée et remboursée avant que la transaction ne se termine, sinon toute la transition d'état est annulée. Dans la séquence décrite par CertiK, ce capital temporaire aurait fourni le poids de bilan nécessaire pour déplacer ou exploiter une condition de marché pertinente pour l'oracle, sans que l'attaquant ait à préfinancer la totalité de la position.

Le financement est distinct de la condition oracle

Le prêt lui-même n'est pas la preuve d'un défaut d'oracle. La question de sécurité est de savoir si la logique de rachat de CoreVault a fait confiance à un prix, une profondeur de liquidité ou une entrée de conversion pouvant être influencés économiquement dans la même fenêtre d'exécution atomique. Le gonflement du rachat rapporté par CertiK est la preuve d'une sortie anormale, pas une explication divulguée de la défaillance de contrôle.

Cette distinction importe pour les fournisseurs de liquidité : une pause de l'accès aux flash loans, même si elle était techniquement réalisable, ne réparerait pas en soi une dépendance de valorisation dangereuse. La vidange signalée de l'InsurancePool concentre plutôt l'attention sur l'ordre d'allocation des pertes du protocole — les utilisateurs doivent savoir quelles responsabilités se situent avant la réserve restante et si une comptabilité LP ou de parts de vault a été recalculée.

Des incidents de manipulation de prix ont soulevé des préoccupations similaires ailleurs dans la DeFi, notamment une attaque signalée sur le marché monétaire de Nostra Finance. Le rapport CoreVault est plus étroit, mais son impact de rachat déclaré met en évidence la même ligne de faille de conception : la liquidité qui semble disponible sous une valorisation manipulée peut être retirée avant que les arbitragistes ordinaires ne puissent rétablir le prix.

Ce que les utilisateurs de CoreVault doivent surveiller

Aucune annonce officielle de CoreVault, divulgation d'adresse de contrat, avis de pause, déclaration d'impact utilisateur ou plan de remédiation n'était disponible dans les données au moment de la publication. Les utilisateurs doivent donc considérer le statut actuel des rachats comme inconnu jusqu'à ce que des communications vérifiées du protocole ou une mise à jour attribuable d'un fournisseur de sécurité indiquent le contraire — plutôt que de déduire la sécurité d'une transaction réussie via l'interface.

La liste pratique de surveillance est concise : disponibilité des rachats, mises à jour des paramètres oracle ou de tarification, changements des soldes de l'InsurancePool, et un post-mortem identifiant les contrats affectés et le plan de remédiation. Deux points de suivi méritent une attention égale : savoir si une analyse on-chain indépendante corrobore ou révise le récit transactionnel de CertiK, et si le protocole choisit de recapitaliser l'InsurancePool ou de restructurer la façon dont la réserve soutient les rachats. La vidange signalée rend ces points plus importants que les commentaires secondaires du marché, car ils déterminent si la liquidité restante peut honorer les sorties à une valeur liquidative défendable.

Reportings confirmés et questions non résolues

L'enregistrement vérifié se limite à l'alerte de CertiK : la société a rapporté le rachat gonflé, la vidange de l'InsurancePool et les produits post-annulation, tandis que la transaction sous-jacente n'a pas été analysée de manière indépendante. Les affirmations selon lesquelles CoreVault aurait suspendu ses opérations, remboursé les utilisateurs, mis à niveau des contrats ou quantifié les pertes seraient prématurées, car aucune déclaration de ce type du protocole n'était incluse dans les preuves.

Pour un contexte de sécurité plus large, le tableau de bord de CertiK, marqué comme mis à jour le 4 novembre 2026, affichait 183,0 M$ de pertes totales pour sa période de chiffres clés de novembre 2026. Ce chiffre du tableau de bord est un contexte sectoriel plutôt qu'une attribution à CoreVault, mais il souligne pourquoi les avis d'incident non vérifiés devraient toujours susciter un examen attentif de l'exposition oracle et des contrôles de retrait.

Évaluation du risque du protocole

Le risque immédiat de smart contract se concentre à la frontière rachat-oracle et dans la disponibilité de l'InsurancePool après la vidange signalée. La gouvernance doit désormais déterminer si les paramètres, la conception de l'oracle, les permissions d'urgence ou les règles d'allocation des réserves nécessitent des changements ; aucune date de prochain vote de gouvernance n'a été identifiée dans les preuves disponibles. Dans la DeFi, le durcissement de cette frontière prend généralement la forme de prix moyens pondérés dans le temps, de flux oracle multi-sources, de contrôles de déviation rejetant les cotations hors d'une plage définie, ou de contrôles de retrait déclenchés par la détection d'anomalies — les preuves disponibles n'établissent pas lesquels, le cas échéant, CoreVault emploie actuellement.

Jusqu'à ce que CoreVault publie des conclusions attribuables au niveau des contrats, la liquidité reste exposée à un risque de concentration partout où un seul circuit de rachat, une dépendance de prix ou un pool de backstop régit la capacité de sortie. Les déposants et fournisseurs de liquidité devraient privilégier le statut de rachat vérifié et toute remédiation approuvée par la gouvernance plutôt que des hypothèses de récupération spéculatives — particulièrement si le protocole confirme que le rachat anormal signalé a affecté la comptabilité du collatéral partagé.

Cet article a été publié à l'origine sur DefiLiban.