Je considérais auparavant le problème de sécurité de @Dusk Dusk comme une vulnérabilité isolée ; après avoir lu l’analyse AEGIS, j’ai découvert que le risque franchissait quatre frontières. Dusk a été divulgué en mars 2026 et AEGIS a corrigé 39 problèmes d’audit interne, dont 7 étaient des niveaux Critical. Les causes profondes se situent à la fois dans l’alias du VM Piecrust et la désérialisation côté hôte, et touchent aussi le remboursement de frais lié à Phoenix ainsi que la construction de signatures BLS, affectant la détermination de l’exécution, la mémoire au sein des nœuds, l’intégrité de la chaîne d’approvisionnement et l’authentification de consensus.

Je l’ai découpé en quatre verrous de contrôle de risque pour l’institution de transaction : état d’isolement à l’exécution, validation des données externes avant analyse, liaison du remboursement des frais aux pièces justificatives originales, et signature de consensus avec une cartographie fiable vers une courbe. AEGIS a refondu la session et la propriété des instances ; la cohérence des frais est vérifiée à la fois dans le mempool et dans la VM, et le chemin de sécurité BLS utilise désormais un style hash-to-curve et une séparation de domaine de type RFC 9380.

Les 39 correctifs ne font que préciser que les surfaces d’attaque connues ont été traitées. L’officiel indique qu’aucun problème critique n’a été trouvé comme ayant été exploité avant la mise à niveau, tout en ajoutant 31 mesures de durcissement, couvrant l’exécution et le réseau, et s’étendant à la cryptographie et aux portefeuilles. Par la suite, je regarderai le taux de couverture des mises à jour de nœuds, les tests de non-régression et les données anormales sur le réseau principal ; le correctif liste les coordonnées de contrôle ; seuls des historiques de fonctionnement à long terme permettront de vérifier la solidité des défenses.

#dusk $DUSK