Audit Sherlock Ripple : 96 Bugs Evites Sur XRPL

Imaginez un instant qu’un simple oubli dans le code permette a un attaquant de vider n’importe quel compte sans jamais detenir sa cle privee. Pas besoin de phishing, pas de malware, juste une transaction soigneusement construite. C’est exactement le type de scenario que l’equipe de Ripple a evite de justesse au printemps 2026. Deux failles critiques, capables de detruire des soldes entiers, ont ete neutralisees avant meme d’atteindre le mainnet. Derriere ce sauvetage se cache un audit communautaire hors norme mene par Sherlock, qui a fait remonter 96 vulnerabilites en deux semaines seulement. L’histoire ne se resume pas a un simple chiffre. Elle interroge en profondeur la maniere dont l’industrie crypto gere (ou ne gere pas) la securite avant le deploiement.

Quand Un Concours D’Audit Devient Un Filet De Securite Pour Tout Un Reseau

Le 13 avril 2026, Sherlock ouvrait un concours d’audit d’une ampleur rare. Le prix mis en jeu atteignait 550 000 RLUSD. L’objet : cinq amendements proposes pour le XRP Ledger, encore en phase de developpement. Batch Transactions, Permission Delegation, integration MPT DEX, Confidential Transfers et Sponsored Fees. En quinze jours, les chercheurs ont soumis des rapports qui ont abouti a 96 findings valides. Deux critiques, six de severite haute, vingt-neuf moyennes et cinquante-neuf basses. Ripple a reverse 309 000 RLUSD aux contributeurs. Le reste a couvert les couts de la plateforme et les findings de moindre impact.

Ce n’etait pas un audit classique en chambre noire. Sherlock fonctionne sur un modele adversarial. Les chercheurs sont classes selon leurs performances et se disputent des primes. Le cadre attire des profils tres divers, y compris des outils d’intelligence artificielle comme Apex de Cantina. Pour un protocole couche 1 ecrit en C++, l’exercice restait inhabituel. La plupart des contests Sherlock concernent des smart contracts Solidity. Ici, il s’agissait de logique transactionnelle native, d’authorisations et de verifications cryptographiques a l’echelle du ledger lui-meme.

La distribution elle-meme raconte une histoire. Les findings moyens et bas ne menacent pas directement les fonds, mais ils revelent une densite de surface d’attaque non negligeable. Quand cinq fonctionnalités majeures avancent en parallele, chaque nouvelle logique transactionnelle ouvre des chemins d’exploitation potentiels. Le fait que deux d’entre elles aient atteint le niveau critique montre a quel point le filet externe etait necessaire.

Le Bug Batch Qui Aurait Pu Tout Vider

La faille la plus dangereuse n’est pas nee pendant le concours Sherlock. Elle a ete identifiee le 19 fevrier 2026 par le chercheur Pranamya Keshkamat, en parallele avec l’outil autonome Apex. A ce moment-la, l’amendement Batch original se trouvait encore en phase de vote validateur. Il n’avait jamais ete active.

Le mecanisme Batch permet d’executer jusqu’a huit operations de maniere atomique sous une transaction exterieure unique. L’idee est seduisante pour l’experience utilisateur. Le probleme residait dans la verification de signature de cette transaction exterieure. Une condition de sortie precoce pouvait etre satisfaite sans controler correctement qui autorisait les transactions interieures. En pratique, un attaquant pouvait construire un Batch contenant des Payment visant un compte victime, le vider jusqu’a la reserve, sans jamais detenir les cles de ce compte. Le meme trou logique autorisait des AccountSet, TrustSet ou AccountDelete non legitimement signes.

La verification du signataire dans la transaction exterieure pouvait passer sans confirmer que l’entite soumettant le batch controlait reellement les comptes references dans les operations interieures.

Rapport de divulgation xrpl.org

Quatre jours apres la decouverte, RippleX publiait la version 3.1.1 de rippled. Les amendements Batch et fixBatchInnerSigs etaient marques comme non supportes. Les validateurs ne pouvaient plus voter pour leur activation. Aucun fonds n’a ete perdu. L’amendement n’avait jamais atteint le seuil de 80 % necessaire. La version de remplacement, BatchV1_1, est arrivee dans la 3.3.0 avec la condition de sortie precoce elimine, des gardes d’autorisation supplementaires et une verification indepandante de chaque transaction interieure.

Permission Delegation Et Le Drain Silencieux Par Frais

La seconde faille critique fonctionnait de facon plus insidieuse. Une divulgation de septembre 2025 avait deja documente le principe. L’implementation originale de Permission Delegation permettait a un attaquant de faire saigner progressivement le solde XRP d’un compte delegue sans jamais acceder a ses cles.

Le piege reposait sur une particularite ancienne du traitement des transactions sur le XRP Ledger. Une transaction qui echoue avec une erreur de classe tec engendre quand meme des frais. Les erreurs detectees plus tot, avant la verification de signature, n’en engendre pas. Cette distinction existe pour limiter le spam : une transaction correctement formee et signee mais refusee pour des raisons metier doit etre penalisee. Or le code original de Permission Delegation verifiait d’abord si le compte delegue detenant la permission avant de valider la signature. Un attaquant pouvait donc soumettre en boucle des transactions offline-signees invalides avec des frais eleves. Chaque echec debitait le solde de la victime.

Le cout pouvait grimper tres vite. L’attaquant fixait arbitrairement le niveau des frais. Le proprietaire du compte voyait son solde diminuer sans aucun paiement sortant visible. Diagnostiquer l’origine exigeait d’examiner les metadonnees brutes des transactions. La correction a reclasse l’erreur en ter et a reordonne les controles : plus aucun frais ne peut etre preleve avant que la signature soit validee. L’amendement de remplacement, PermissionDelegationV1_1, porte par defaut la designation No dans le registre de la 3.3.0. Les validateurs doivent voter activement pour l’activer. Ce choix conservateur reflete la sensibilite du probleme initial.

Pourquoi Deux Reecritures Completes Ont Voyage Dans La Meme Version

Le 6 aout 2026, xrpld 3.3.0 sortait avec le code de six propositions (les cinq features plus un amendement de nettoyage fixCleanup3_3_0). Aucune n’etait activee. Sous le processus d’amendement du XRP Ledger, chaque proposition doit maintenir plus de 80 % de soutien validateur pendant deux semaines consecutives avant d’entrer en production.

Cette separation entre disponibilite du code et activation de la fonctionnalite constitue un avantage structurel rare. Sur Ethereum, un contrat deploye est immediatement live. Sur XRPL, le code peut etre livre, examine pendant la fenetre de vote, et toujours bloque si les validateurs perdent confiance. Les reecritures Batch et Permission Delegation avaient deja traverse le concours Sherlock, un re-audit Halborn sans finding critique ou haute, et des mois de tests internes. La periode de vote ajoute encore une couche de defense avant que le moindre fond reel soit touche.

La meme version a retire cinq anciens amendements (Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve, fixUniversalNumber). L’objectif etait d’eliminer des chemins de code morts qui auraient pu s’accumuler comme surface d’attaque latente. Les cinq nouvelles fonctionnalites representent l’expansion la plus large des capacites XRPL a ce jour. Confidential Transfers introduisent le chiffrement EC-ElGamal et des preuves a connaissance nulle pour les Multi-Purpose Tokens. Sponsored Fees permettent aux applications de prendre en charge les couts reseau. DynamicMPT autorise les emetteurs a modifier certaines proprietes de tokens apres creation. Ensemble, ces pieces ciblent clairement les institutions financieres regulees qui ont besoin de confidentialite, de reglement atomique et d’operations deleguees sans sacrifier l’auditabilite.

Audit Avant Activation Contre Correctif Apres Exploit

Le contraste avec le reste de l’industrie est brutal. Au cours des cinq premiers mois de 2026, les exploits DeFi ont depasse 840 millions de dollars sur plus de cinquante incidents. Cela represente une hausse de 70 % par rapport a la meme periode de 2025. Les acteurs lies a la Coree du Nord ont concentre 76 % des pertes mondiales sur les quatre premiers mois. Le chiffre le plus revelateur reste celui-ci : 70 % des contrats exploites avaient ete audites, mais ne disposaient d’aucun monitoring post-deploiement. Seulement 4 % des projets suivis combinaient audit, bug bounty actif et controles tiers de surveillance.

Le modele Ethereum, qui concentre la plus grande part de valeur en smart contracts, fonctionne selon une logique inverse. Le contrat est live des qu’il est deploye. Si une faille apparait ensuite, les options se limitent a deployer un nouveau contrat et migrer les utilisateurs, a utiliser un pattern de proxy (qui introduit sa propre surface d’attaque), ou a accepter le risque. Le hack Wormhole de 2022 a coute 320 millions parce qu’une fonction de verification depreciee restait en production. L’exploit Ronin d’aout 2024 a couté 12 millions parce qu’une mise a jour de contrat n’avait pas initialise correctement les poids des operateurs. Dans les deux cas, des audits avaient eu lieu. Les echecs se sont produits apres deploiement.

Les chiffres de 2026 confirment la tendance. L’attaque KelpDAO du 18 avril a drainé environ 293 millions de dollars, le plus gros exploit DeFi de l’annee. Celle de Drift Protocol sur Solana le 1er avril a atteint 286 millions, record pour cette chaine. Selon les donnees DeFiLlama, l’industrie a collectivement perdu 16,69 milliards de dollars en hacks, exploits de bridges et incidents de securite. Ces montants ne sont plus des exceptions. Ils constituent le taux d’echec de base d’un ecosysteme qui deploie d’abord et corrige ensuite.

Le processus d’amendement XRPL inverse la sequence. Le code voyage dans une release, mais les fonctionnalites restent dormantes jusqu’a l’approbation des validateurs. Pendant la fenetre de vote, chercheurs, operateurs de nœuds et auditeurs concurrents peuvent examiner le codebase live avec un contexte complet. Si un probleme emerge, les validateurs retiennent simplement leur vote. Pas de patch d’urgence, pas de migration, pas de contrat proxy. Le bug Batch de fevrier 2026 a suivi exactement ce chemin : l’amendement etait en phase de vote, la vulnerabilite a ete identifiee, une release d’urgence a empeche l’activation. Zero fonds en risque, zero impact utilisateur.

Ce Que Cela Change Pour Le Positionnement Institutionnel

Ripple a construit en 2026 une pile d’infrastructure institutionnelle a un rythme agressif. L’acquisition pour 1,25 milliard de dollars de Hidden Road, rebrandee Ripple Prime, a fourni une passerelle regulee vers la finance traditionnelle. RLUSD a atteint 1,72 milliard de capitalisation en moins d’un an et a fait circuler plus de 18 milliards de volume de transactions au seul premier trimestre. Goldman Sachs a declare une position de 153,8 millions de dollars a travers quatre ETF XRP. L’entreprise a obtenu une licence EMI complete au Luxembourg en fevrier, des permissions FCA au Royaume-Uni en janvier, et une licence MiCA CASP le 6 juillet.

Les fonctionnalites institutionnelles de la version 3.3.0 constituent le pendant technique de cette poussée commerciale. Confidential Transfers repondent aux exigences de confidentialite des banques qui ne peuvent pas exposer les details de transactions sur un ledger public. Sponsored Fees eliminent le friction d’onboarding qui a longtemps tenu les applications grand public a l’ecart des reseaux decentralises. Permission Delegation, une fois sa reecriture validee, permet des modeles d’acces controles exiges par les departements de conformite.

Mais l’adoption institutionnelle repose sur la confiance, et la confiance dans une infrastructure blockchain se mesure d’abord a la piste de securite. Le fait que Ripple ait capture deux bugs critiques, reecrit deux implementations entieres, paye 309 000 dollars a des chercheurs externes et livre quand meme les cinq features dans les delais constitue un argument de vente plus solide que n’importe quelle fonctionnalite isolee. Cela suggere une culture ou trouver des bugs est recompense et ou le shipping reste subordonne a la verification.

Plus de 300 institutions financieres dans 55 pays utilisent deja RippleNet, avec des corridors On-Demand Liquidity actifs dans plus de 70 marches. Pour ces acteurs, les resultats de l’audit Sherlock ne sont pas abstraits. Ils constituent une preuve que le code qui fait circuler leurs paiements transfrontaliers a ete mis sous pression par des chercheurs adversariaux dotes d’incentives financiers pour le casser. La feuille de route quantique en quatre phases, visant une completion en 2028, renforce encore le signal : l’entreprise engenere pour des horizons institutionnels mesures en decennies, pas en cycles de deploiement.

Les Objections Des Sceptiques Restent Pertinentes

Trouver 96 bugs avant release peut se lire de deux facons. Preuve d’une rigueur exceptionnelle, ou preuve que le developpement interne laisse passer des problemes que des regards exterieurs detectent ensuite. Les deux vulnerabilites critiques etaient presentes dans les implementations originales. Elles avaient donc traverse les revues internes. Le bug Batch de fevrier n’a pas ete trouve par l’equipe Ripple, mais par un chercheur independant et un outil d’IA. Si le filet de securite principal reste externe, des lacunes de qualite interne finiront peut-etre par produire une faille qu’aucun reviewer externe ne capturera a temps.

Deuxiemement, la force du modele d’amendement XRPL – la capacite a bloquer l’activation pendant le vote – constitue aussi une contrainte de vitesse. La volonte d’Ethereum de deployer et d’iterer a permis un rythme d’innovation que XRPL ne peut pas egaler. Les cinq amendements de la 3.3.0 ont passe des mois en cycles de developpement et de revue. L’amendement Batch original datait de 2025. Pour des protocoles qui se disputent l’attention des developpeurs dans des marches rapides, un pipeline de securite de six mois peut s’averer trop lent pour attirer l’ecosysteme de builders qui genère les effets de reseau.

Il existe aussi un risque de concentration dans le set de validateurs. Le seuil d’activation a 80 % signifie qu’un nombre relativement restreint d’entites, dont beaucoup entretiennent des liens etroits avec Ripple, controle effectivement le passage en production des amendements. Les critiques y voient moins une gouvernance decentralisee qu’un processus d’approbation curate habille de langage consensus. Quand le validateur de Ripple a vote yes sur des amendements de lending ces dernieres semaines, cela a souligné l’influence que l’entreprise conserve sur un reseau nominalement decentralise.

Enfin, le versement de 309 000 dollars sur une pool de 550 000 interroge l’alignement des incentives. Les chercheurs de premier plan commandent des tarifs horaires superieurs a ce que les modeles de contest paient generalement. Si les auditeurs les plus competents contournent les contests XRPL parce que le gain attendu par finding reste inferieur a des engagements prives, la revue adversariale peut etre large sans etre suffisamment profonde pour capturer les vecteurs d’attaque les plus sophistiques.

Ces objections ont du poids. XRP cotait autour de 1,03 dollar fin juillet 2026, environ 71 % sous son plus haut de cycle a 3,65 dollars atteint le 17 juillet 2025. Le marche n’a pas encore integre pleinement le narrative institutionnel. Que la piste de securite se traduise en adoption dependra de facteurs qui depassent la qualite du code : clarte reglementaire, positionnement concurrentiel face aux solutions layer-2 Ethereum, et la question de savoir si les institutions privilegient les audits pre-deploiement a la taille de l’ecosysteme.

Les Indicateurs A Suivre Dans Les Prochains Mois

Le premier signal sera le niveau de soutien validateur pour les cinq amendements de la 3.3.0. Si BatchV1_1 et PermissionDelegationV1_1 franchissent les 80 % des le premier cycle de vote, cela indiquera une confiance dans les reecritures. Un blocage prolongerait les doutes residuels sur le code reecrit.

Le vrai test de la thoroughness de l’audit Sherlock arrivera apres activation. Zero finding critique dans les 90 premiers jours validerait le modele pre-release. Toute vulnerabilite post-activation affaiblirait la these entiere.

L’adoption de RLUSD sur Confidential Transfers constituera un barometre institutionnel concret. Un volume significatif sur des rails confidences confirmerait une demande reelle pour un reglement conforme aux exigences de confidentialite. Les metriques du premier trimestre post-activation seront le signal le plus clair.

La decision de Ripple de poursuivre ou non avec des contests adversariaux pour les prochains amendements indiquera a quel point le modele pre-release est ancre dans la culture de developpement. Un retour exclusif aux audits prives traditionnels suggérerait que l’experience Sherlock restait exceptionnelle plutot que systemique.

Enfin, chaque nouvel exploit majeur sur Ethereum ou Solana qui remonte a une vulnerabilite post-deploiement renforce mecaniquement l’argument en faveur du pipeline audit-vote-activate de XRPL. La comparaison ne reste forte que tant que le reste de l’industrie continue de preferer deployer d’abord et corriger ensuite.

Une Culture De Securite Qui Se Mesure En Absence De Catastrophe

Le recit dominant de 2026 dans la crypto reste celui des pertes record et des exploits a repetition. Dans ce contexte, le fait qu’un protocole majeur ait neutralise deux failles capables de vider des comptes avant qu’elles n’atteignent le moindre wallet constitue une anomalie positive. Pas une garantie absolue. Pas une preuve que le modele est parfait. Mais une demonstration concrete qu’une autre sequence est possible : ecrire, exposer a des regards adversariaux incentives, reecrire si necessaire, livrer le code, laisser voter, et n’activer que lorsque le consensus de confiance est atteint.

La distinction n’est pas cosmétique. Elle change la nature du risque. Dans le modele deploy-and-hope, le cout d’une erreur est paye par les utilisateurs apres coup, souvent de facon irreversible. Dans le modele audit-vote-activate, le cout d’une erreur est principalement paye en temps de developpement et en primes de bug bounty, avant que les fonds reels ne soient exposes. Pour des institutions qui gerent des flux transfrontaliers et des exigences de conformite strictes, cette difference de timing n’est pas secondaire. Elle est structurante.

Reste a voir si le reste de l’industrie tirera les leçons de cet episode. Les 840 millions perdus en cinq mois montrent que la pression reste forte pour livrer vite. Les contests de type Sherlock sont coutueux et exposent publiquement les faiblesses. Beaucoup d’equipes preferent encore les audits prives discrets suivis d’un deploiement rapide. Tant que cette preference dominera, les exploits post-activation continueront de ponctuer l’actualite. Le cas Ripple-Sherlock demontre simplement qu’une alternative existe, et qu’elle peut etre mise en œuvre a l’echelle d’un ledger de couche 1 avec des enjeux institutionnels reels.

La version 3.3.0 n’est pas encore activee dans ses fonctionnalites les plus sensibles. Les prochains cycles de vote diront si les validateurs partagent la confiance que l’equipe a placee dans ses reecritures. En attendant, le principal enseignement reste celui-ci : 96 bugs ont ete trouves, deux critiques ont ete neutralises, et aucun wallet n’a ete touche. Dans une industrie ou les pertes se comptent encore en centaines de millions, ce silence-la vaut mieux que beaucoup de communiques de victoire.