XRPL corrige la délégation des autorisations après la découverte d’un bug critique
XRPL a retiré son amendement Permission Delegation après qu’un rapport de bug bounty a révélé une faille à haut risque lors des tests. Une version V1.1 renforcée fait actuellement l’objet d’un examen de sécurité et de contrôles qualité.
Cet épisode montre pourquoi la délégation au niveau du protocole nécessite des garde-fous qui vont au-delà de la fonctionnalité de base elle-même.
XRPL remanie Permission Delegation après un signalement de bug
Permission Delegation, connue sous le nom de XLS-75, permet à un compte d’accorder à un autre des pouvoirs précis pour agir en son nom. Ces autorisations sont censées être limitées, et non donner au délégué le contrôle de l’ensemble du compte.
J. Ayo Akinyele, responsable de l’ingénierie chez RippleX, a expliqué que l’implémentation initiale V1.0 avait été retirée après le signalement d’une vulnérabilité dans le cadre du programme de bug bounty, avant son déploiement sur le réseau principal de XRPL. Au lieu de corriger cette version directement, l’équipe a introduit la V1.1 afin de distinguer l’implémentation initiale de la version renforcée.
Un chercheur nommé Shotes a découvert un problème de gravité élevée lié à des autorisations de délégation irrévocables : un délégué pouvait supprimer son compte, puis le recréer tout en conservant les autorisations qui lui avaient été accordées par un autre compte, sans que le compte d’origine puisse les révoquer.
Les changements vont au-delà d’un simple bug. La version V1.1 corrige des cas limites liés à l’identité du délégataire et empêche que des fonctionnalités plus récentes, notamment les opérations Vault et Lending, soient déléguées involontairement. Elle corrige également le calcul des réserves pour les paiements délégués et ferme une voie de signature multiple qui pouvait contourner les vérifications de délégation. Le comportement de révocation a également été renforcé.
L’examen a également révélé un dépassement de capacité d’entier non signé de gravité moyenne dans isDelegable, qui pourrait faire interpréter une valeur de permission mal formée comme un type de transaction délégable. Les chercheurs ont toutefois indiqué que ce problème n’avait pas d’impact significatif en l’absence de comportement malveillant de la part du délégant.
Les tests couvrent davantage les mécanismes de délégation du XRPL
Un rapport d’assurance qualité publié par Ramkumar SG le 26 août fait état de 179 tests consacrés à la délégation des permissions, dont 112 tests fonctionnels, 48 tests de sécurité adversariaux et 19 tests portant sur plusieurs fonctionnalités. Les tests ont également couvert les interactions avec Batch, Confidential MPT, la file d’attente des transactions et la signature multiple.
XRP Ledger Operations a indiqué que tous les problèmes avaient été corrigés dans la version V1.1 et vérifiés par la société de sécurité Cantina. Son équipe d’assurance qualité a également signalé qu’aucune régression n’avait été constatée sur 5 088 tests et qu’aucun bug interne ouvert n’était classé comme critique. Elle a conclu que la fonctionnalité était prête à être utilisée en production pour la version testée.
La délégation des autorisations a été introduite en mai 2025, déclarée non prise en charge en septembre 2025 dans l’attente d’un correctif de sécurité, renommée PermissionDelegationV1_1 en octobre, puis de nouveau prise en charge en juin 2026.
Comme CryptoPotatoComme indiqué la semaine dernière, un tableau de bord public créé par le développeur Denis Angell suit de près la manière dont les amendements XRPL sont testés sur devnet avant d’atteindre le mainnet, et la délégation figurait parmi les amendements qu’il avait signalés comme incomplets.
Pour les utilisateurs et les dépositaires, la fonctionnalité prévue reste inchangée. Comme l’a expliqué Akinyele, V1.1 ne change pas ce que XLS-75 peut faire ; elle modifie plutôt les conditions dans lesquelles cette fonctionnalité est activée.
Source : CryptoPotato