Les protocoles DeFi audités ont perdu 885 millions de dollars à cause d'attaques survenues complètement en dehors de leurs périmètres d'audit

Dans la finance décentralisée, "audité" est souvent présenté comme un verdict sur l'ensemble d'un projet. En pratique, un audit couvre généralement un code, des composants et des versions nommés à un moment donné. Tout ce qui est ajouté, exclu ou opéré autour de cette limite peut comporter un niveau d'assurance différent.

Un nouveau préprint quantifie cet écart. Des chercheurs affiliés à la société de sécurité ack3 et à l'Université technique tchèque de Prague ont examiné 135 incidents rapportés du premier semestre 2026, avec des pertes attribuées de 939,86 millions de dollars. Ils ont trouvé des audits publics pré-incidents identifiables pour 68 incidents.

Dans ce sous-ensemble de 68 incidents, les auteurs ont classé 46 chemins d'attaque comme étant en dehors de chaque périmètre d'audit qu'ils pouvaient identifier, 20 comme étant à l'intérieur d'au moins un périmètre et deux comme non résolus. Le groupe hors périmètre représentait 67,6 % des incidents mais 94,4 % de leurs pertes rapportées.

Ce pourcentage frappant n'est pas une estimation de l'efficacité de l'audit ni une preuve que les limites d'un audit ont causé une perte. Il décrit la distribution des pertes dans un ensemble sélectionné d'incidents rapportés. Deux grands cas dominent également : après avoir exclu 292 millions de dollars au Kelp DAO et 285 millions de dollars au Drift Protocol, la part hors périmètre tombe à 72,1 % des pertes dans le même sous-ensemble d'incidents audités.

Même avec ces limites, l'étude expose un problème d'assurance de base. Un projet peut dire en toute vérité qu'il a été audité tout en laissant les utilisateurs incapables de dire si le système en direct, le chemin contenant leurs fonds et les contrôles qui l'entourent ont été examinés.

Ce que les données montrent réellement

Le jeu de données ack3 couvre les incidents du 1er janvier au 29 juin. Ses auteurs ont classé 122 comme confirmés et 13 comme probables. Dans l'ensemble, 35 n'avaient pas d'audit identifié et 32 avaient un historique d'audit inconnu, donc aucun des deux groupes n'apparaît dans le calcul du périmètre des 68 incidents.

Pour ce groupe de 68 incidents, les incidents hors périmètre représentaient 680,97 millions de dollars des 721,24 millions de dollars de pertes rapportées, produisant le chiffre de 94,4 %. En retirant Kelp DAO et Drift Protocol, il restait 103,97 millions de dollars des 144,24 millions de dollars hors périmètre, soit 72,1 %. Le registre lisible par machine reproduit les comptes de seaux et les sommes de pertes.

Les étiquettes à l'intérieur ou à l'extérieur restent les jugements des chercheurs sur les preuves publiques. Ils ont recherché dans les archives des projets et des auditeurs, localisé des rapports pré-incidents et comparé les chemins d'attaque éventuels avec le code examiné, les versions et les exclusions. Le travail est un préprint de six pages produit avec l'éditeur du jeu de données, et deux auteurs sont affiliés à ack3, qui vend des revues de sécurité.

L'étude manque également d'un groupe de comparaison non exploité et d'une mesure de la durée d'exposition de chaque système. Elle ne peut pas établir si les protocoles audités sont globalement plus sûrs, estimer la probabilité d'incidents ou montrer que le fait de tomber en dehors du périmètre a causé chaque perte. Des audits non divulgués et des incidents privés peuvent manquer, tandis que les chiffres de pertes rapportés ne sont pas parfaitement comparables.

L'étude soutient donc une conclusion limitée : l'historique d'audit et le périmètre d'audit sont des variables différentes. Un contrat intelligent examiné ne confère pas automatiquement la même assurance sur une mise à niveau, une clé privilégiée, un front-end, un relayer, un oracle, un service cloud ou un processus de réponse aux incidents.

Deux incidents d'août illustrent cette distinction de différentes manières. Le réseau ICON fournit un exemple direct de code examiné échouant à la limite entre deux vérifications. L'incident aelf d'août fournit un cas contrasté car les preuves d'audit disponibles ne peuvent pas encore être liées à son chemin d'exécution rapporté.

Selon le rapport post-mortem de la Fondation ICON du 30 août, un contrat de migration a utilisé les bits élevés du numéro de série d'un message de retrait pour décider s'il était unique. La signature cryptographique ne couvrait que les 256 bits inférieurs. En modifiant les bits élevés non signés, un attaquant a soumis à nouveau deux messages de retrait légitimement signés 1 492 fois en environ 20 minutes. ICON a déclaré que 1 490 appels avaient réussi.

La limite audité qu'ICON a manquée

Les replays ont libéré 119,866 millions d'ICX et 531 600 bnUSD. Au moment du rapport post-mortem, ICON a estimé la perte nette confirmée à environ 150,2 ETH plus 31 204 USDC. Il a déclaré que 531 600 bnUSD et 1,366 million de SODA avaient été récupérés et que les dépôts, soldes et positions des utilisateurs n'avaient pas été affectés.

ICON a déclaré que le contrat de migration avait subi un audit externe et que des recommandations avaient été mises en œuvre, y compris des changements dans le même domaine. Il a également déclaré que la logique de relais pertinente avait reçu un examen dédié. L'archive d'audit de SODAX répertorie huit rapports à travers différents composants, y compris un audit de relais de novembre 2025.

Pourtant, le rapport post-mortem a indiqué que le décalage précis entre la vérification d'unicité et la valeur signée était en dehors de ces conclusions. Un badge au niveau du projet ne pouvait pas indiquer à un utilisateur si les deux extrémités du chemin de retrait s'accordaient sur ce qui rendait un message unique.

La chronologie de la réponse ajoute un second type de limite. La première alerte automatisée d'ICON s'est déclenchée à 02:08 UTC, environ sept minutes après le début de l'exploitation. Le personnel a ouvert une enquête vers 03:40, a suspendu le contrat affecté à 03:53 et a arrêté le réseau à 06:18:54.

ICON a attribué l'écart d'environ 90 minutes entre la première alerte et une réponse complète à l'incident à un réglage des alertes. La classe d'alerte avait produit des faux positifs lors d'incidents de connectivité non liés et n'a pas alerté l'équipe de garde avec la gravité nécessaire. La fondation a déclaré qu'elle prévoyait un déclencheur d'arrêt automatique, des seuils de disjoncteur plus bas et un examen de suivi axé sur l'unicité des messages et les protections contre les replays.

Ces contrôles ne remplacent pas un audit. Ils fournissent des preuves pour une question différente : lorsque la prévention échoue, à quelle vitesse la détection peut-elle devenir une containment ?

aelf montre pourquoi l'assurance doit rester actuelle

aelf's incident d'août teste l'argument dans une autre direction. Son dossier public décrit un compromis d'exécution et une récupération contrôlée, mais il ne fournit pas suffisamment de preuves pour placer le chemin à l'intérieur ou à l'extérieur d'un audit pré-incident spécifique.

La société a annoncé une pause du réseau le 18 août. Dans sa mise à jour de progrès du 26 août, aelf a déclaré qu'un contrat intelligent non autorisé pouvait utiliser des paramètres de transaction pour livrer des assemblages et des instructions .NET encodés dans le chemin d'exécution du nœud.

Le compte provisoire a lié l'incident à des lacunes dans les vérifications pour la réflexion d'exécution et le chargement dynamique, ainsi qu'à une isolation faible entre l'exécution des contrats et les ressources sensibles du nœud ou de l'infrastructure. aelf a identifié 155 transactions associées et cinq assemblages de charges utiles uniques avec des capacités comprenant l'exécution de commandes hôtes, la communication sortante tentée, l'accès à la clé du nœud et la reconnaissance de l'infrastructure.

La capacité n'est pas la même que l'exécution confirmée. aelf a déclaré que les charges utiles ne prouvaient pas que chaque assemblage avait été exécuté, que chaque identifiant ciblé avait été obtenu ou que des données sensibles avaient quitté ses systèmes. La société a indiqué qu'elle faisait tourner les clés de signature et les identifiants d'infrastructure selon une norme d'exposition potentielle.

Le statut public est resté provisoire le 11 septembre : l'index du blog de aelf ne contenait aucun élément spécifique à l'incident publié après le 26 août. La déclaration du 26 août s'était engagée à fournir une autre mise à jour et un examen final éventuel.

La documentation de sécurité actuelle de aelf indique que ses contrats de blockchain et de jetons ELF ont subi plusieurs audits sans problèmes de sécurité identifiés. Mais les pages disponibles ne relient pas un rapport pré-incident spécifique au chemin d'exécution décrit en août. Qualifier l'incident soit de manque d'audit soit d'échec hors de portée dépasserait donc les preuves.

Cette incertitude est en soi utile. Un historique d'audit daté peut se détacher du code actuel d'un système, de ses dépendances et de son état opérationnel. Les utilisateurs ont besoin d'un enregistrement d'assurance qui soit versionné et suffisamment spécifique pour révéler cette dérive.

Un tel enregistrement devrait nommer le dépôt examiné et l'engagement, les adresses déployées, les composants exclus, les rôles privilégiés et les dépendances. Il devrait également enregistrer les mises à jour depuis l'examen, la garde et la rotation des clés, l'isolement d'exécution, le comportement d'alerte et de disjoncteur, ainsi que l'état de récupération daté qui sépare la perte confirmée de l'exposition gelée ou non résolue.

Cela ne réduit pas la valeur d'un audit. Cela rend la revendication proportionnelle au travail effectué et relie ce travail au système en fonctionnement maintenant.

Un badge d'audit ne peut pas répondre à la question de savoir si l'artéfact examiné, le système déployé et la machinerie qui répond à l'échec partagent toujours la même frontière de sécurité.