De Binance à PHP2Shell : À l'ère de l'IA, la ligne de défense de la sécurité Web doit être redéfinie

Les attaquants pénètrent toute la chaîne de confiance, le d/acc de Vitalik tente également de réorienter la direction de l'accélération technologique vers la défense.

Le 30 octobre au matin, le marché des cryptomonnaies a de nouveau connu un incident historique de vol de fonds, cette fois-ci, c'était au tour de Binance.

Selon les premières enquêtes, les attaquants auraient pu accéder à un conteneur de service en piratant l'ordinateur portable d'un ingénieur DevOps, et soumettre des transactions de retrait non autorisées. Binance estime que l'impact total de l'incident pourrait atteindre 6,3 milliards de dollars, et a déjà gelé environ 3 milliards de dollars d'actifs connexes.

Il convient de noter que, au cours de l'année écoulée, les incidents de sécurité des principales bourses se sont multipliés de manière désespérante :

L'année dernière, Bybit a subi un vol d'actifs d'environ 1,46 milliard de dollars, et en septembre de cette année, Bitget a également vu environ 387,5 millions de dollars d'actifs transférés sans autorisation, et maintenant Binance est également impliqué dans une nouvelle tempête.

Si l'on observe les récents incidents de sécurité ensemble, on peut constater une tendance évidente : les attaquants s'attaquent de moins en moins directement à la cryptographie et aux clés privées elles-mêmes, mais commencent plutôt à se concentrer sur toute la « chaîne de confiance » ------ des terminaux des employés, des produits de sécurité tiers, jusqu'à la chaîne d'approvisionnement logicielle, aux conteneurs de service et même aux processus d'autorisation de transaction, toute faille à un maillon peut compromettre l'ensemble de la ligne de défense.

Le développement rapide de l'IA amplifie également ce risque.

Le 22 octobre, Vitalik Buterin, co-fondateur d'Ethereum, a proposé un nouveau jugement : À l'ère de l'IA, la fin de la cybersécurité pourrait favoriser les défenseurs, mais la période de transition vers cette fin sera très difficile.

I. De Bybit à PHP2Shell : les attaquants pénètrent toute la chaîne de confiance

Revenons sur ces incidents.

Leurs chemins d'attaque ne sont pas les mêmes, mais ils ont un point commun : les attaquants ne se sont pas simplement appuyés sur le piratage des clés privées ou la rupture des protocoles de blockchain sous-jacents, au contraire, ils ont simplement trouvé un maillon de confiance par défaut dans le système.

• Dans l'incident de Bybit, les attaquants ont infiltré l'appareil d'un développeur de Safe par des moyens d'ingénierie sociale, obtenant ses informations d'accès connexes, puis contrôlant les ressources frontales de l'infrastructure du portefeuille Safe ;
• Dans l'incident de Bitget, les attaquants ont exploité une vulnérabilité d'un produit de sécurité tiers pour obtenir des informations d'identification internes à haut niveau, puis ont contourné les mécanismes de contrôle des risques existants avec des instructions de retrait falsifiées ;
• Dans le dernier incident de Binance, le chemin d'attaque a très probablement commencé par l'intrusion de l'ordinateur portable d'un ingénieur DevOps ;

Ces trois incidents impliquent respectivement des infrastructures de portefeuille tierces, des produits de sécurité tiers et des environnements de développement et d'exploitation internes.

Cela explique également pourquoi les portefeuilles froids traditionnels et les mécanismes de multi-signatures ne peuvent pas tout résoudre, après tout, ce que les attaquants exploitent réellement, ce sont ces maillons de confiance qui peuvent influencer l'exécution finale des transactions, mais qui n'ont pas été suffisamment vérifiés de manière indépendante.

Et cette crise de la chaîne de confiance ne se limite pas aux échanges de cryptomonnaies.

Juste une semaine avant l'attaque de Binance, le fondateur de Binance, CZ, avait spécifiquement tweeté pour rappeler à tout le monde d'être particulièrement prudent lors de la visite de tout site Web dans les jours à venir ------ à l'époque, deux vulnérabilités critiques dans le moteur PHP de PHP2Shell (CVE-2026-109618 et CVE-2026-109619, avec un score CVSS v4.0 atteignant 9,2) suscitaient une panique générale sur Internet.

En tant que langage de serveur open source soutenant environ 70 % des sites Web mondiaux, des plateformes majeures comme WordPress, Magento et Drupal sont toutes construites sur PHP.

Et ces deux vulnérabilités de gestion de mémoire et de réinitialisation d'état global, qui ont dormi pendant plus de dix ans, permettent aux attaquants d'exécuter du code à distance (RCE) simplement en effectuant une requête Web spécifique, sans authentification, avant que le code de l'application du site ne soit exécuté, prenant directement le contrôle du serveur et implantant des portes dérobées ou volant des informations d'identification des utilisateurs.

Les données de scan des agences de cybersécurité Palo Alto Networks et Censys montrent que plus de 22,6 millions à 36,7 millions d'instances exposées au public sont à risque.

Plus incroyable encore, selon les agences de sécurité, ces deux vulnérabilités de l'état de mémoire sous-jacentes, qui ont dormi pendant plus de dix ans et sont extrêmement difficiles à détecter par des auditeurs humains, ont été découvertes grâce à la technologie de l'IA, en d'autres termes, l'IA a considérablement réduit le seuil pour transformer des défauts logiques sous-jacents cachés en charges d'attaque exploitables.

Nous avons également discuté à plusieurs reprises des trois transformations majeures des méthodes d'attaque à l'ère de l'IA (pour en savoir plus, lisez « Lorsque les hackers utilisent l'IA de manière « plus efficace », comment la course aux armements entre le « bouclier et la lance » de Web3 évolue ? ») :

• L'« industrialisation » de l'exploitation des vulnérabilités zero-day (0-day) : Auparavant, la recherche de vulnérabilités de mémoire profonde dans le moteur PHP ou au niveau du firmware nécessitait des experts en sécurité de haut niveau pour passer des mois à effectuer des audits de code manuels et des tests de fuzzing, maintenant l'IA peut scanner les dépôts de code open source mondiaux 24 heures sur 24 à un coût très bas, transformant en masse des bugs anciens de dix ans en armes mortelles ;
• La compression extrême de la « fenêtre de correction » (N-day) : Une fois que les informations sur les vulnérabilités sont divulguées ou que le code de correctif est soumis, les attaquants malveillants peuvent utiliser l'IA pour inverser le correctif en quelques minutes, générer automatiquement des variantes d'exploit et effectuer des scans et injections automatisés sur l'ensemble du réseau, rendant les calendriers de mise à niveau calculés en jours ou en semaines par les équipes d'exploitation traditionnelles insignifiants face aux scripts d'attaque de l'IA qui répondent en millisecondes ;
• La chaîne d'approvisionnement logicielle et DevOps devenant le principal point de rupture : Les systèmes modernes de Web3 et financiers ne sont pas construits dans le vide, l'interaction frontale, les conteneurs arrière, les dépendances tierces NPM/PyPI, et l'environnement de développement local des ingénieurs constituent une chaîne d'approvisionnement open source extrêmement vaste et fragile ;

Comme l'attaque de ce conteneur DevOps de Binance a été infiltrée, et la falsification de la chaîne d'approvisionnement frontale de Bybit, étant donné que les attaques sur la chaîne sont les plus faciles à monétiser directement, l'industrie des cryptomonnaies est en train de vivre une « vague mondiale d'attaques de hackers IA de niveau pandémique ».

Bien sûr, tous les incidents d'attaque mentionnés ci-dessus ne sont pas directement initiés ou exécutés par l'IA, mais l'IA amplifie simultanément les capacités des attaquants et des défenseurs, et dans le cadre actuel des systèmes d'ingénierie logicielle, cet effet d'amplification aggrave en fait l'asymétrie structurelle qui existe déjà entre les deux parties.

II. Vitalik : La fin pourrait favoriser la défense, mais la « période de transition » sera extrêmement difficile

Face aux discussions sectorielles suscitées par l'exploitation par l'IA de vulnérabilités sous-jacentes comme PHP2Shell, Vitalik Buterin a donné un jugement très calme le 22 octobre : La fin à long terme de la cybersécurité pourrait favoriser les défenseurs, mais la période de transition sera très difficile.

Pourquoi ?

Parce qu'il existe une asymétrie naturelle entre les attaquants et les défenseurs dans le cadre actuel des paradigmes d'ingénierie logicielle. Un grand système logiciel peut contenir des millions de lignes de code historique, des centaines de dépendances externes, ainsi qu'un grand nombre de chemins d'autorisation et d'exécution complexes.

Les défenseurs doivent s'assurer que tous les maillons critiques sont suffisamment sécurisés, tandis que les attaquants n'ont besoin de trouver qu'une seule faille non découverte.

Vitalik a particulièrement souligné que s'appuyer uniquement sur des chercheurs en sécurité pour découvrir les vulnérabilités dans les logiciels déjà publiés avant les hackers ne peut pas réellement établir un avantage défensif, car si les deux parties utilisent des IA de plus en plus puissantes, alors en essence, il s'agit toujours de voir qui peut trouver les vulnérabilités le plus rapidement.

Ce qui doit vraiment changer, c'est la manière dont le logiciel lui-même est construit, par exemple, il a proposé deux directions clés, la vérification formelle (Formal Verification) et la minimisation de la base de calcul de confiance (Trusted Computing Base, TCB).

Tout d'abord, la vérification formelle vise à remplacer le « débogage basé sur l'expérience » par des preuves mathématiques.

Les tests logiciels traditionnels ne peuvent prouver que « aucun bug a été trouvé dans les scénarios testés », mais ne peuvent jamais prouver que « le code n'a absolument aucun bug », tandis que la vérification formelle utilise une logique mathématique rigoureuse pour prouver qu'un morceau de code de programme respecte strictement les normes de sécurité prévues dans tous les cas d'entrée possibles et de transitions d'état, sans débordement de mémoire, état non réinitialisé (comme PHP2Shell) ou défauts de réentrance logique.

Dans le passé, le coût de la vérification formelle était extrêmement élevé, la quantité de code nécessaire pour écrire des preuves mathématiques était souvent plusieurs fois celle du code métier, seuls l'aérospatial ou les protocoles cryptographiques essentiels pouvaient se le permettre.

Mais à l'ère de l'IA, l'IA peut non seulement trouver des vulnérabilités, mais aussi devenir un super assistant pour rédiger des preuves de vérification formelle, donc Vitalik prédit que l'avenir de la « vérification formelle assistée par IA » deviendra la forme ultime du développement logiciel ------ que ce soit pour des protocoles de communication cryptés comme Signal, TLS, ZK-EVM, ou pour des contrats intelligents au niveau des applications, tout cela pourra être automatiquement généré par l'IA pour produire des preuves de sécurité mathématiques de bout en bout avant la publication du code.

Lorsqu'un morceau de code est mathématiquement prouvé « infaillible », même si la puissance de calcul de l'IA des attaquants est très forte, ils ne pourront pas trouver de vulnérabilités qui n'existent pas.

Ensuite, il y a la minimisation de la base de calcul de confiance (TCB), qui vise à réduire au maximum la surface d'attaque.

Qu'est-ce que la base de calcul de confiance (TCB) ? En termes simples, c'est l'ensemble de tous les composants matériels et logiciels que le système doit « faire confiance sans condition à leur bon fonctionnement » pour garantir la sécurité.

En revenant à l'incident de sécurité de 6,3 milliards de dollars de Binance et à l'incident de détournement de multi-signatures de Bybit : pourquoi l'algorithme de clé privée sous-jacent n'a pas été compromis, mais les actifs ont été perdus ? Parce que leur TCB était trop vaste ------ un vaste cluster de conteneurs, des pipelines de permissions d'exploitation complexes, le système d'exploitation de l'ordinateur portable des développeurs, les bibliothèques JavaScript rendues en front-end, tout cela a été inclus dans la chaîne de confiance « qui, une fois compromise, entraînerait une perte de fonds ».

L'idée centrale de la minimisation de la TCB est de faire des soustractions et des isolations : réduire les fonctionnalités réellement impliquées dans la protection des clés privées, la vérification des signatures et l'autorisation centrale à un environnement de sécurité plus petit, aux frontières plus claires, pouvant accepter des audits stricts, tandis que d'autres fonctionnalités complexes doivent être exécutées dans des environnements périphériques à permissions limitées.

Même si le navigateur, les plugins, les services front-end ou les agents IA sont attaqués, ils ne devraient pas obtenir la capacité de manipuler les actifs des utilisateurs sans restriction.

De ce point de vue, c'est aussi la valeur des portefeuilles non custodiaux comme imToken. En utilisant des échanges centralisés, les actifs des utilisateurs doivent passer par des comptes de plateforme, des portefeuilles custodiaux et des systèmes de retrait internes ; tandis qu'en utilisant imToken, les utilisateurs conservent eux-mêmes leurs clés privées, gèrent directement leurs actifs sur la chaîne et initient des transactions, réduisant ainsi l'étape intermédiaire de la garde centralisée.

Une chaîne de confiance plus courte signifie donc moins d'exposition aux risques au niveau de la plateforme, et il n'est pas nécessaire de s'inquiéter d'un échange suspendant les retraits ou gelant le solde du compte de la plateforme. Bien sûr, les utilisateurs doivent également assumer la responsabilité de la garde des clés privées et de la sécurité des appareils.

III. De l'accélération technique à l'accélération défensive : pourquoi avons-nous besoin de d/acc ?

Si la vérification formelle et la minimisation du TCB répondent à la question « comment être plus sûr sur le plan technique », alors le d/acc, prôné depuis longtemps par Vitalik, tente de répondre à une question plus macro :

Alors que l'IA et d'autres technologies de pointe changent rapidement le monde, comment devrions-nous prioriser le développement technologique ?

Le d/acc, ou Accélération Défensive, est un concept que Vitalik a systématiquement proposé pour la première fois en 2023 et qu'il a approfondi dans "d/acc : un an plus tard" en 2025.

Il ne s'oppose pas aux progrès technologiques, mais souligne une accélération sélective : prioriser le développement de technologies qui peuvent renforcer la capacité de défense sociale, décentraliser le pouvoir et réduire les risques systémiques.

Contrairement à l'accélération totale mise en avant par e/acc, le d/acc se concentre davantage sur la question de savoir si la technologie renforce la capacité d'attaque ou améliore la capacité de défense (pour en savoir plus, voir "Quand Web3 rencontre d/acc : que peut faire Crypto à l'ère de l'accélération technologique ?").

Dans la vision du d/acc, ce système de défense couvre quatre dimensions de construction en profondeur :

• Défense réseau : réduire le taux de réussite des attaques réseau grâce à la cryptographie, à la vérification formelle, à l'isolation des logiciels et à la détection des vulnérabilités, protégeant ainsi les actifs numériques et les données ;
• Défense biologique : améliorer la capacité de la société à faire face aux risques de sécurité biologique grâce à la détection des pathogènes, à la surveillance de l'air, au développement de vaccins et aux technologies de santé publique ;
• Défense physique : réduire la vulnérabilité des infrastructures critiques du monde réel face aux attaques grâce à des énergies distribuées, des réseaux de communication résilients et la construction de la résilience des infrastructures ;
• Défense de l'information : résister à la désinformation, à la falsification profonde et à la manipulation massive de l'information grâce à la protection de la vie privée, à la vérification des sources d'information et à des mécanismes de collaboration décentralisés ;

Ces domaines semblent très variés, mais ils tournent tous autour d'un objectif commun : alors que la technologie continue d'améliorer les capacités des individus et des organisations, elle doit également leur donner la capacité de se protéger en conséquence, empêchant ainsi des technologies plus puissantes de se concentrer uniquement entre les mains de quelques entités disposant de ressources et de pouvoir.

C'est également dans le cadre de la discussion sur la vague de vulnérabilités PHP que Vitalik a réaffirmé une de ses positions fondamentales dans le cadre du d/acc : face aux chocs asymétriques causés par l'IA de pointe, il est nécessaire d'aborder avec prudence la progression désordonnée de l'IA agressive à haut risque ; en même temps, la société dans son ensemble devrait investir systématiquement plus de 1 % de son PIB dans la cybersécurité, la sécurité biologique et le renforcement de la sécurité du monde physique.

Pourquoi avons-nous besoin d'un tel investissement systématique à grande échelle ?

Parce que les bénéfices des avancées technologiques peuvent souvent être rapidement évalués et commercialisés par le marché, mais la valeur des infrastructures de sécurité est souvent sous-estimée.

Les entreprises sont prêtes à investir des sommes considérables dans des modèles d'IA plus puissants, des capacités de calcul plus rapides et des outils de développement logiciel plus efficaces, mais elles ne sont pas nécessairement prêtes à fournir un soutien d'ampleur équivalente pour la maintenance à long terme des logiciels open source, la vérification formelle et les audits de sécurité. Si cette mauvaise allocation de ressources n'est pas corrigée, les grandes structures numériques reposant sur des bases open source fragiles deviendront de plus en plus dangereuses.

En conclusion

Des risques d'infrastructure Internet mondial révélés par PHP2Shell aux événements de sécurité majeurs survenus chez Bybit, Bitget et Binance, la situation de la cybersécurité en 2026 rappelle à tous le coût réel :

La compétition d'attaque et de défense à l'ère de l'IA ne consiste plus seulement à voir qui peut découvrir les vulnérabilités le plus rapidement, mais à savoir si l'ensemble de l'écosystème logiciel peut établir un système de défense suffisamment fiable.

La sécurité ne peut jamais être acquise une fois pour toutes, mais cela ne signifie pas que c'est une guerre d'usure sans victoire possible.

Au cours des dernières décennies, la cryptographie a prouvé que certaines capacités de défense peuvent être établies sur des principes mathématiques offrant des garanties de sécurité très solides, et non simplement en comptant sur les défenseurs pour investir plus de main-d'œuvre.

La combinaison de l'IA avec la vérification formelle et les technologies de minimisation des calculs de confiance offre également l'opportunité d'étendre cette idée à l'ensemble du système logiciel.

Pour les utilisateurs ordinaires, cette philosophie de sécurité peut également se traduire par le choix de la méthode de gestion des actifs.

Choisir un portefeuille non custodial comme imToken, c'est essentiellement garder le contrôle de ses actifs, réduire la dépendance à l'égard des plateformes centralisées et des systèmes d'exploitation internes. Bien sûr, cela signifie également que les utilisateurs doivent accorder plus d'importance à la garde des phrases de récupération, à la sécurité des appareils et à chaque autorisation de transaction. Mais au moins, la possibilité de disposer de ses actifs ne dépend plus entièrement du bon fonctionnement d'une plateforme centralisée.

C'est peut-être cela que Vitalik entend par le fait que la fin de la cybersécurité pourrait être favorable aux défenseurs : il ne s'agit pas d'attendre qu'un jour, l'IA ne trouve plus aucune vulnérabilité, mais de faire en sorte que nos systèmes clés, sur lesquels nous comptons, puissent continuer à fonctionner de manière fiable, même face à des attaquants de plus en plus intelligents, en s'appuyant sur des cœurs de confiance plus petits, des limites d'autorisation plus strictes et des mécanismes de sécurité plus vérifiables.

Les progrès technologiques méritent d'être accélérés, mais la capacité à protéger les résultats technologiques et les actifs individuels doit également être accélérée.