Deux failles critiques dans PHP, le langage qui fait tourner l’essentiel du web, sont sondées par des attaquants dès le lendemain des correctifs, et aucun exchange, wallet ou prestataire de conservation de cryptoactifs n’a, à ce stade, été montré du doigt comme victime. Le projet PHP a publié des versions corrigées le 21 octobre en début d’après-midi (UTC) pour ces bugs, surnommés PHP2Shell et référencés CVE-2026-109618 et CVE-2026-109619. Les deux affichent un score CVSS v4.0 de 9,2 sur 10 et permettent l’exécution de code à distance, selon l’avis de sécurité de PHP sur GitHub. Côté français, le CERT-FR de l’ANSSI a diffusé une alerte dès le 20 octobre.
Coinbase et BitGo disent ne pas être concernés. BNB Chain affirme ne pas utiliser PHP. Binance indique avoir mis des protections en place avant le correctif et terminé sa remédiation. Changpeng Zhao, le fondateur de Binance, a demandé à ses abonnés d’être « extrêmement prudents » sur n’importe quel site web pendant quelques jours. Le directeur général de Cloudflare, Matthew Prince, a écrit sur X que les tentatives d’exploitation observées sur le réseau de l’entreprise sont passées de quelques milliers avant l’annonce à des millions dans la nuit de mercredi à jeudi.
Pour le lecteur de cryptos, l’histoire concerne moins les grandes plateformes que la longue traîne : boutiques WordPress qui acceptent des paiements en crypto, tableaux de bord auto-hébergés, explorateurs de blocs et interfaces de nœuds qui font tourner PHP quelque part dans leur pile technique, sans oublier le phishing qui suit presque toujours une faille très médiatisée.
Faille PHP2Shell : ce que font CVE-2026-109618 et CVE-2026-109619
La première faille, CVE-2026-109618 (avis GitHub GHSA-w8hw-w9fx-j79w), est une corruption de mémoire qui peut être déclenchée lorsque PHP manque de mémoire en traitant une requête. La seconde, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), vient d’un état global périmé qui survit d’une requête à la suivante. L’une comme l’autre peut permettre à un attaquant d’exécuter du code sur le serveur : c’est ce que recouvre l’expression « exécution de code à distance », et la raison du 9,2.
La configuration la plus exposée est mod_php, le module qui exécute PHP à l’intérieur du serveur web Apache. Selon l’avis, une seule requête envoyée par une personne non authentifiée peut y lancer l’attaque avant même que le code du site ne s’exécute, et l’équipe PHP a démontré une exécution de code via HTTP avec les limites de mémoire par défaut. PHP-FPM, le gestionnaire de processus associé à Nginx sur de nombreux hébergements, est jugé vulnérable, mais aucun exploit complet n’avait été démontré à la date de publication. FrankenPHP et LSAPI de LiteSpeed sont probablement vulnérables, sans validation à ce jour.
Ce détail explique pourquoi le conseil habituel, « mettez à jour vos extensions », ne suffit pas ici. Le bug se trouve dans l’environnement d’exécution PHP installé sur le serveur, sous WordPress, WooCommerce ou n’importe quel code maison. Cloudflare le dit dans son article : smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il faut corriger PHP lui-même, car mettre à jour les applications qui tournent dessus ne suffit pas.
Versions de PHP corrigées et fin de support
Quatre versions corrigées sont sorties le 21 octobre, une par branche encore prise en charge. La préversion 8.6.0 RC4, publiée le même jour, contient aussi les correctifs, mais c’est une version de test que PHP déconseille en production.
| Branche PHP | Version corrigée | Statut |
|---|---|---|
| 8.5 | 8.5.12 | Prise en charge |
| 8.4 | 8.4.27 | Prise en charge |
| 8.3 | 8.3.36 | Prise en charge |
| 8.2 | 8.2.35 | Correctifs de sécurité jusqu’au 31 décembre 2026 |
| 8.1, 8.0, 7.4 | Aucune version officielle | Fin de vie ; correctifs source minimaux publiés par l’équipe de sécurité de PHP |
Les distributions Linux ont reçu les correctifs en avance : les paquets Debian, Ubuntu ou Red Hat peuvent donc déjà les intégrer sous leur propre numérotation. Le jour de la publication, le CERT-EU a relevé que le dépôt de Remi, source courante de versions récentes de PHP pour les systèmes de type Red Hat, n’avait pas encore de mise à jour. Les logiciels qui embarquent leur propre copie de PHP peuvent aussi être exposés ; le CERT-EU renvoie les administrateurs vers un dépôt GitHub tenu par le NCSC néerlandais, qui recense les produits concernés.
L’équipe PHP affirme que la mise à jour est la seule atténuation complète. Pour les serveurs qui ne peuvent pas être mis à jour tout de suite, elle et le CERT-EU énumèrent des mesures partielles, qui réduisent le risque sans le supprimer : fixer memory_limit à -1 d’une façon que les applications ne puissent pas modifier, maintenir post_max_size à 8M ou 32M, limiter la taille des requêtes au niveau du proxy, désactiver session.upload_progress.enabled et, sur PHP 8.5, mettre fatal_error_backtraces à 0. Ils déconseillent d’utiliser les limites système RLIMIT_AS ou RLIMIT_DATA.
Les tentatives d’exploitation grimpent, mais aucune victime n’est nommée
Cloudflare indique avoir activé des règles de pare-feu applicatif (WAF) contre ces failles à 03 h 02 UTC le 21 octobre, environ neuf heures avant la divulgation publique, puis avoir constaté du trafic d’attaque visant ses clients, avec des attaquants qui modifient leurs charges utiles pour contourner les règles. L’article du blog de Cloudflare ne donne aucun chiffre. La protection est active par défaut pour les sites du forfait gratuit, via les règles « Generic Rules – Anomalous Execution » du Managed Free Ruleset ; les clients payants doivent activer le Cloudflare Managed Ruleset en mode blocage.
Le chiffre qui circule dans beaucoup de titres vient de Matthew Prince. Dans un message sur X publié à 01 h 25 UTC le 22 octobre, il écrit que Cloudflare a vu des milliers de tentatives dans les dix heures précédant l’annonce, des dizaines de milliers dans les 45 minutes suivantes, des centaines de milliers en deux heures, et « des millions maintenant ». Ce sont des tentatives, pas des intrusions réussies. Environ un site web sur cinq fait transiter son trafic par Cloudflare, d’après l’entreprise citée par Cointelegraph : sa vision est large, mais incomplète.
D’autres signaux vont dans le même sens sans trancher sur l’ampleur. Le directeur technique de Cloudflare, Dane Knecht, a parlé d’« attaques précoces », rapporte Fortune. Amazon a repéré une tentative d’exploitation remontant au 17 octobre, quatre jours avant la publication, selon Bitcoin.com News, qui cite un billet du blog sécurité d’AWS. « Les défenseurs ne doivent pas supposer que la date de divulgation publique est la première date d’exploitation », a déclaré CJ Moses, responsable de la sécurité des systèmes d’information d’Amazon, d’après le même article. Le CERT-EU a indiqué que des détails techniques publics et de premières preuves de concept circulaient. L’agence américaine de cybersécurité CISA, dans son alerte du 21 octobre, disait ne pas avoir observé d’exploitation au moment de la publication.
Des administrations des Pays-Bas et de Finlande ont mis hors ligne certains sites par précaution, a rapporté Fortune en citant Reuters ; Decrypt fait le même constat. Le FBI et la NSA ont appelé à mettre à jour. Fortune décrit les intrusions confirmées comme « limitées et en cours » et ne nomme aucune victime.
Deux chiffres sont souvent confondus. PHP fait tourner environ 69 % des sites dont le langage côté serveur est connu, selon des données de W3Techs reprises par Cointelegraph. C’est une mesure d’usage, pas d’exposition, comme le rappelle Cointribune : un site sur une version corrigée ou hors mod_php n’est pas dans la même situation qu’un vieux serveur Apache. Fortune rapporte par ailleurs que Palo Alto Networks a dénombré 22,6 millions d’instances potentiellement vulnérables, un chiffre issu d’un seul média.
Une publication avancée après une fuite
PHP avait annoncé la version de sécurité le 20 octobre, pour le lendemain à 14 h 00 UTC. Selon Decrypt, la publication coordonnée était d’abord prévue le 22 octobre et a été avancée après la fuite de certains détails. Le CERT-EU situe la publication des correctifs à 13 h 30 UTC le 21 octobre.
OpenAI se place au centre de la découverte. Son président, Greg Brockman, a affirmé que le bug dormait dans PHP depuis 14 ans et qu’une version limitée avait été repérée en 2024 sans être « jugée significative », rapporte Decrypt, dont l’auteur qualifie ce message de coup de communication. Fortune donne un récit plus complet : la société de red teaming Calif a trouvé la première faille le 1er août avec GPT-5.6 Sol d’OpenAI, OpenAI a ensuite enquêté et en a trouvé d’autres, et l’éditeur de sécurité cloud Wiz a découvert la première de son côté le 19 août avec plusieurs modèles, dont Gemini 4 Argon de Google. OpenAI a piloté une coalition avec Wiz, Calif, la fondation PHP, Cloudflare et plusieurs agences américaines, d’après Fortune. L’article de Cloudflare cite Calif, Wiz, OpenAI et Quarkslab comme les quatre organisations à l’origine de la divulgation, et l’avis GitHub crédite quatre découvreurs par leur pseudonyme.
Ce n’est pas la faille WordPress de juillet. Celle-ci, connue sous le nom de wp2shell (CVE-2026-63030 et CVE-2026-60137), a été corrigée dans WordPress 6.9.5 et 7.0.2. PHP2Shell se situe une couche plus bas et exige une mise à jour de PHP, quelle que soit la version de WordPress.
Ce que disent Coinbase, BitGo, BNB Chain et Binance
Le responsable de la sécurité de Coinbase, Jeff Lunglhofer, a écrit sur son compte personnel X le 21 octobre à 20 h 32 UTC : « Coinbase a terminé un balayage de son environnement et n’a trouvé aucune trace d’instance PHP exposée. » Il a ajouté que l’entreprise travaillait aussi avec ses fournisseurs tiers pour une assurance supplémentaire. BitGo n’est pas touché non plus, rapporte Bitcoin.com News, sans citation de la société.
BNB Chain a déclaré que sa pile technique « n’utilise pas PHP », d’après Coingape, qui ajoute qu’un membre de l’équipe de Trust Wallet, Felix Fan, a indiqué que la pile du wallet ne comporte pas de PHP. La société de sécurité blockchain SlowMist a appelé exchanges, wallets et plateformes DeFi à vérifier leur infrastructure, selon EthNews, tout en soulignant que l’activité d’attaque observée jusqu’ici ne permet pas de dire si une plateforme crypto a été compromise.
Changpeng Zhao a publié le 21 octobre à 22 h 06 UTC : « Traitez-moi de paranoïaque, mais soyez extrêmement prudents en visitant N’IMPORTE QUEL site web ces prochains jours. » Dans le même message, il cite les deux CVE et dit que certains administrateurs web tardent à appliquer les correctifs de sécurité.
Le compte officiel de Binance a suivi le 22 octobre à 06 h 18 UTC. La plateforme affirme que ses équipes de sécurité ont « mis en place des protections de manière proactive avant la publication du correctif officiel et réalisé la remédiation nécessaire », et qu’elle continue de surveiller la situation. Elle n’a pas précisé si certains de ses systèmes faisaient tourner une version vulnérable de PHP : la « remédiation » peut donc désigner un correctif, un filtrage ou une vérification qui n’a rien trouvé.
Ces déclarations portent sur les systèmes propres aux entreprises. La mention des fournisseurs par Jeff Lunglhofer montre où l’exposition peut subsister pour une grande plateforme : chez les prestataires et les outils externes qu’elle n’exploite pas elle-même. Certains médias ont publié des articles qui demandent s’il faut retirer ses fonds des exchanges. Rien de ce qui a été publié à ce jour ne l’étaye : aucun exchange n’a signalé d’incident, et aucun n’est nommé par des chercheurs ou des agences.
Alerte du CERT-FR et de l’ANSSI : la référence pour les entreprises françaises
Le CERT-FR, rattaché à l’Agence nationale de la sécurité des systèmes d’information (ANSSI), a publié l’alerte CERTFR-2026-ALE-014, « Multiples vulnérabilités dans PHP », le 20 octobre, puis l’a mise à jour le 21 octobre. Elle indique que les deux CVE peuvent permettre l’exécution de code arbitraire à distance et que les correctifs sont disponibles chez l’éditeur. En Italie, le CSIRT de l’agence nationale de cybersécurité (ACN) a diffusé dans la soirée du 21 octobre l’alerte AL07/261021/CSIRT-ITA, intitulée « PHP2Shell: sanate vulnerabilità critiche in PHP ».
Ni l’AMF ni l’ACPR n’avaient publié quoi que ce soit sur ces failles au moment de la rédaction, et la question fiscale ne se pose pas. Pour une entreprise de crypto établie en France, l’alerte du CERT-FR est le document à verser au dossier d’incident, et la page à surveiller pour savoir si l’exploitation est confirmée.
Faille PHP : que faire si vous gérez un site crypto, un front de nœud ou un plugin de paiement
L’essentiel du risque se situe chez les petits opérateurs : un commerçant qui fait tourner une passerelle de paiement crypto sur WooCommerce, un projet qui héberge son propre explorateur ou tableau de bord de staking, un validateur avec une page d’administration en PHP. Les avis officiels fixent un ordre de travail clair.
- Mettez à jour PHP sur le serveur ou dans l’image de conteneur vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers le paquet corrigé de votre distribution. Une mise à jour de WordPress ou d’une extension ne règle pas le problème.
- Sur un hébergement mutualisé, demandez à l’hébergeur quelle version de PHP tourne sur votre compte et quand elle a été corrigée.
- Cherchez le PHP que vous ignorez avoir : extensions de paiement crypto, tableaux de bord de wallet ou de facturation, explorateurs de blocs auto-hébergés, interfaces de nœuds et de staking, panneaux d’administration et images Docker construites sur une base PHP.
- Sous PHP 8.1 ou plus ancien, passez à une branche prise en charge, appliquez un correctif de l’éditeur ou retirez le système d’Internet, comme le recommande la CISA.
- Si vous ne pouvez pas corriger aujourd’hui, appliquez les réglages partiels cités plus haut, placez le site derrière un WAF (le forfait gratuit de Cloudflare inclut les règles) et surveillez les processus PHP qui lancent des shells, un signe de compromission que liste la CISA.
Traitez en priorité tout serveur qui a manipulé des clés privées, des clés d’API de comptes d’exchange ou des identifiants de hot wallet. Un bug PHP n’atteint pas des clés stockées ailleurs, mais une page de paiement compromise peut changer l’adresse de dépôt affichée aux clients sans toucher au wallet. Plus tôt cette semaine, le cas des clés faibles d’eMudhra avait déjà poussé des équipes crypto à mettre à jour bots et serveurs, et ce matin la faille chez Railway a demandé à tous les utilisateurs de cette plateforme d’hébergement de renouveler leurs secrets.
Utilisateurs de wallets et d’exchanges : les bons réflexes
Les clés conservées sur un hardware wallet ne sont pas exposées par un bug de serveur web. Le risque vient des pages que vous visitez. Un site pris en main via PHP peut injecter un script de drainer de wallet ou remplacer une adresse de dépôt, et l’attaquant n’a pas besoin de vos clés si c’est vous qui signez la transaction à sa place.
Vérifiez chaque adresse de réception sur l’écran de l’appareil, pas seulement dans le navigateur. Ouvrez vos exchanges depuis un favori plutôt que depuis les résultats de recherche ou des liens reçus par e-mail. Activez les listes blanches d’adresses de retrait et, quand la plateforme en propose un, le code anti-phishing qui apparaît dans ses vrais e-mails. Attendez-vous à des messages sur une « mise à jour de sécurité PHP » qui vous demandent de vous connecter ou de reconnecter un wallet : aucun exchange n’a besoin de cela à cause de ce bug. Notre guide pour repérer et signaler les arnaques crypto détaille les formes courantes de ces tentatives, et aucun message authentique ne vous demandera votre phrase de récupération : notre guide sur la sécurité de la seed phrase explique comment la garder hors ligne. En France, les cas d’escroquerie peuvent être signalés sur la plateforme Cybermalveillance.gouv.fr et, pour les offres frauduleuses d’actifs numériques, auprès de l’AMF.
Rien, dans les faits publiés jusqu’ici, ne justifie de déplacer ses fonds dans la précipitation. Un retrait précipité vers une adresse mal saisie ou substituée est une manière plus probable de perdre de l’argent cette semaine qu’une intrusion chez un exchange dont personne n’a fait état.
Ce qu’on ignore encore et les prochaines échéances
Le nombre de serveurs réellement compromis n’est pas connu, et aucune plateforme crypto n’a signalé ni n’a été montrée comme victime d’une intrusion via PHP2Shell. Les « millions » de Matthew Prince comptent des tentatives, et Cloudflare n’a publié aucune ventilation de celles qui ont réussi. Binance n’a pas dit en quoi consistait sa remédiation, et BitGo n’a pas été cité directement. Au-delà des quatre pseudonymes GitHub et des sociétés nommées dans la presse, les personnes qui ont signalé les bugs ne sont pas identifiées.
La prochaine échéance est celle du calendrier de PHP : la branche 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026, ce qui laisse environ dix semaines aux sites qui y sont encore. Surveillez les pages du CERT-FR et de l’ACN, ainsi que le catalogue des vulnérabilités exploitées connues (KEV) de la CISA : une confirmation d’exploitation active ferait passer le conseil de l’urgence de correction à l’évaluation d’une compromission.