La semaine dernière, un chercheur en sécurité a révélé un cas alarmant : dans une mise à jour d’un portefeuille le 24 décembre, un code de porte dérobée a été injecté, entraînant la fuite de données privées des utilisateurs (y compris la phrase de récupération), avec des pertes dépassant 2 millions de dollars.

Cet incident peut sembler nouveau au premier abord, mais en y regardant de plus près, il reflète en réalité un problème ancien des portefeuilles — les utilisateurs n’ont aucun contrôle sur leurs limites de sécurité.

**VRAI RISQUE DES PORTFEUILLES PLUG-IN**

Beaucoup de discussions sur ce genre d’incidents ont tendance à rejeter la faute sur l’utilisateur : « A-t-il importé la phrase de récupération ? A-t-il fait une erreur ? » Mais du point de vue de la conception du produit, le problème ne se situe pas là. Le vrai risque réside dans le mécanisme de mise à jour automatique lui-même.

Les portefeuilles plug-in ont une réalité incontournable :

Chaque mise à jour automatique revient à donner une autorisation totale sur l’ensemble de vos actifs.

Tant que le code dans le package de mise à jour est compromis — que ce soit par une faille interne ou, plus couramment, par une attaque sur la chaîne d’approvisionnement (processus CI/CD, environnement de build, canal de distribution infiltré) — une logique malveillante peut s’exécuter à l’insu de l’utilisateur. Et l’utilisateur ne s’en rend même pas compte.

Ce qui est encore plus inquiétant : ce risque ne se limite pas aux portefeuilles chauds. Même si vous utilisez un plugin pour connecter un portefeuille matériel, le danger reste le même. Car le plugin contrôle :

- le contenu des transactions que vous voyez
- l’adresse de réception que vous confirmez
- toutes les informations affichées avant et après votre signature

Un portefeuille matériel peut garantir que la « clé privée ne quitte jamais la puce », mais il ne peut pas garantir que vous signez la transaction que vous pensez signer. Si le plugin a de mauvaises intentions, il peut vous faire signer quelque chose, et au final, la chaîne exécutera autre chose.

**Pourquoi cela devient-il un problème systémique**

Le problème réside dans : le contrôle centralisé des mises à jour. Une fois que l’utilisateur installe un plugin, il confie le destin de sa sécurité entièrement à l’équipe de développement. Cette équipe peut être fiable, mais si l’infrastructure, le processus de publication ou l’ordinateur d’un employé sont compromis, cela peut entraîner une perte massive d’actifs.

Et du côté de l’utilisateur, c’est totalement passif — vous ne voyez pas ce qui a été mis à jour, ni ne pouvez refuser une version spécifique.

C’est pour cela que toute la communauté Web3 commence à repenser la conception des portefeuilles. Certains projets explorent des mécanismes de mise à jour basés sur la séparation des clés, vérifiables par l’utilisateur, voire des architectures prioritaires locales — l’objectif étant de donner à l’utilisateur un contrôle réel sur la sécurité de ses actifs, plutôt que de faire aveuglément confiance.