PHP expose une vulnérabilité à haut risque « au niveau d'Internet » : comment résoudre le « point faible hors chaîne » de Web3 ?

Titre original : « PHP expose une vulnérabilité critique « au niveau d'Internet » : comment corriger le « point faible hors chaîne » de Web3 ? » Auteur original : Équipe de sécurité SlowMist

Que s’est-il produit ?

Le 21 octobre, le projet PHP a publié une mise à jour de sécurité d’urgence pour corriger deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, pouvant entraîner une exécution de code à distance non authentifiée (RCE) ; toutes deux ont reçu la note CVSS v4.0 de 9,2. PHP a officiellement indiqué qu’avant la correction, toutes les installations PHP fournissant des services web externes pouvaient être affectées.

Le 20 octobre, les détails de la vulnérabilité ont fuité avant la divulgation officielle, et le correctif n’était pas encore publié. L’équipe de sécurité PHP a dû avancer la sortie d’urgence, initialement prévue le 22 octobre, au 21 octobre à 14h00 (UTC).

Plus inquiétant encore, des attaques auraient pu précéder la divulgation. L’équipe de renseignement sur les menaces d’Amazon a signalé avoir observé, le 17 octobre, des tentatives d’exploitation ciblant php2shell sur son réseau de potes à miel MadPot, soit quatre jours avant la divulgation publique.

SlowMist a également publié immédiatement des rappels et recommandations de sécurité après l’annonce anticipée officielle de PHP.

Quelles sont ces deux vulnérabilités ?

CVE-2026-109618 (corruption mémoire par dépassement de mémoire) : lorsque PHP manque de mémoire, le flux de traitement est interrompu et les données en cours ne sont que partiellement préparées. Lors du nettoyage, PHP traite ces données incomplètes comme si elles étaient complètes, ce qui provoque une corruption mémoire.

CVE-2026-109619 (état global périmé) : après le traitement d’une requête, la mémoire est libérée, mais l’état associé « demeure en place ». Lorsque le même processus de travail traite la requête suivante, il peut utiliser cet état expiré avant son initialisation normale. Les autorités ont confirmé que cela peut servir à attaquer PHP-FPM et obtenir une exécution de code à distance.

Du point de vue du vecteur d’attaque, le danger de ce type de vulnérabilité réside dans le fait que les attaquants n’ont pas besoin d’obtenir d’abord un compte sur le site, ni de contourner les vérifications de connexion, de permissions ou de clés API au niveau métier. L’envoi d’une requête spécialement conçue à une application PHP exposée sur Internet public peut permettre une exécution arbitraire de code avec les privilèges du processus du service web.

Périmètre d’impact : les versions PHP 5.4 à 8.5.11 sont toutes concernées. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les versions antérieures ne bénéficient plus d’un support amont régulier ; aucun correctif ne sera donc disponible via les canaux habituels, et une migration vers des versions encore prises en charge est indispensable.

Pourquoi le monde entier est-il inquiet ?

Parce que PHP est tout simplement trop répandu. Selon les statistiques de W3Techs, parmi les sites web dont le langage côté serveur est identifiable, 69,3 % utilisent PHP. Des systèmes familiers tels que WordPress, WooCommerce et Magento reposent tous sur lui.

Les réactions de divers pays illustrent également le problème : le Centre national néerlandais de cybersécurité a préventivement fermé des sites web ; le Bureau présidentiel sud-coréen a convoqué une réunion d’urgence sur la cybersécurité, et le gouvernement a relevé le niveau d’alerte en matière de cybersécurité.

En outre, selon des rapports, presque tous les sites web officiels de Corée du Nord, y compris les médias officiels et les portails gouvernementaux, sont hors ligne depuis plus de 24 heures, sans qu’il soit encore établi si cela est lié à cette vulnérabilité.

Impact sur Web3

Ce n’est pas un problème qui concerne uniquement l’exploitation et la maintenance traditionnelles de sites web. Pour le Web3, même si les contrats déployés sur la blockchain ne présentent aucune vulnérabilité, le grand nombre de « composants hors chaîne » entourant leur fonctionnement — notamment les pages frontales, les API, les portefeuilles gérés, les services de signature, les pages de réclamation d’airdrop, les backends opérationnels et les services de données — repose souvent sur PHP (WordPress, WooCommerce, Magento, etc.). L’absence de vulnérabilités dans les contrats eux-mêmes ne garantit pas la sécurité de ces composants.

Selon les statistiques du système d’intelligence sur les menaces MistEye, développé par SlowMist, sur les 1 488 domaines liés au secteur crypto qu’il a analysés, 793 présentaient des empreintes directes de PHP, soit environ 53,3 %. Il convient de souligner que cela indique uniquement l’utilisation de PHP, sans signifier que ces sites comportent des vulnérabilités ou ont été compromis.

1. Du côté des plateformes : plusieurs chemins de risque typiques

Altération du frontend pour inciter les utilisateurs à signer frauduleusement.

Si les serveurs de sites DeFi, de portefeuilles ou de pages d’airdrop sont compromis, les attaquants peuvent remplacer les adresses RPC, les cibles d’autorisation, les adresses de contrats ou les invites de signature affichées sur la page, transformant ainsi une transaction normale en autorisation malveillante, interaction malveillante avec un contrat ou processus de dépôt factice. Les attaquants n’ont pas besoin de pénétrer le contrat : il leur suffit que l’utilisateur signe lui-même une autorisation malveillante.

Fuites de clés et d’identifiants.

Une fois le serveur compromis, les attaquants peuvent lire les fichiers de configuration, les mots de passe de base de données, les jetons d’API, les variables d’environnement, etc. Si le backend utilise PHP pour se connecter aux services RPC ou aux portefeuilles chauds, la fuite de clés d’API ou de jetons de session peut permettre le transfert d’actifs détenus dans des portefeuilles chauds ou l’abus de permissions de signature.

Prise de contrôle du backend et des API.

Les plateformes d’échange, les marchés NFT, les ponts interchaînes, les passerelles de paiement et les fournisseurs de services de nœuds disposent généralement de backends opérationnels, ainsi que d’interfaces KYC/gestion des risques, d’allocation d’adresses de dépôt, d’examens de retraits, de systèmes de tickets, etc. Une fois les droits obtenus, les attaquants peuvent modifier les configurations, voler des données utilisateurs, créer des comptes à privilèges élevés ou contourner les processus métier.

Déplacement latéral via la chaîne d’approvisionnement.

Les privilèges d’un processus PHP ne correspondent généralement pas aux privilèges maximaux du serveur, mais s’il peut lire des clés CI/CD, des sockets d’exécution de conteneurs, des identifiants de base de données ou des jetons d’accès au cloud, la portée de l’attaque peut s’étendre d’un simple nœud web aux bases de données, aux systèmes de construction ou même à l’ensemble du compte de production.

Plugins de paiement et services tiers.

On sait que les solutions de paiement crypto telles que Binance Pay, Crypto.com Pay, BitPay, CoinGate et CoinPayments proposent toutes des intégrations WooCommerce, et les serveurs non mis à jour présentent des risques d’exposition graves. Les services tiers tels que les nœuds RPC, les explorateurs de blocs et les plateformes d’analyse de données peuvent également devenir des points d’entrée si leurs backends ou systèmes opérationnels reposent sur des environnements PHP affectés. Bien entendu, les nœuds RPC, les contrats intelligents, les explorateurs de blocs et les portefeuilles eux-mêmes ne dépendent pas intrinsèquement de PHP : cela dépend de la pile technologique spécifique du produit.

Toutefois, il est essentiel de noter qu’un serveur compromis ne signifie pas nécessairement que des actifs sur chaîne ont été volés. Le passage d’une violation de service web à une perte financière réelle dépend de la capacité des attaquants à accéder à des identifiants sensibles, aux processus de signature, aux privilèges administratifs ou aux points d’interaction utilisateur. Le fait que les portefeuilles chauds soient isolés de la couche web, que les clés soient stockées dans des modules de sécurité matériels (HSM) ou des services de gestion des clés (KMS), et que les privilèges soient minimisés déterminent directement le niveau maximal de pertes potentielles.

2. Pour les utilisateurs ordinaires : devez-vous retirer vos cryptomonnaies ?

Non.

La raison en est simple :

Cette vulnérabilité affecte uniquement les environnements serveur répondant à des conditions spécifiques ; elle ne signifie pas que les portefeuilles de tous les utilisateurs sont exposés.

Naviguer sur un site web et y connecter un portefeuille ne revient pas à exposer sa clé privée. La vulnérabilité elle-même ne permet pas de craquer directement les portefeuilles ou signatures des utilisateurs.

Le fait qu’un projet utilise PHP ne signifie pas qu’il a déjà été compromis. Rien ne justifie de supposer que toutes les plateformes d’échange ont été attaquées, encore moins de retirer tous ses actifs à cause de cela. Ce que les utilisateurs doivent véritablement surveiller, c’est si les sites qu’ils visitent ont été compromis. Or, les utilisateurs ne peuvent pas déterminer si un site a été corrigé : cet incident rappelle donc qu’il ne faut pas faire aveuglément confiance aux interfaces web. Les attaquants peuvent aussi exploiter l’attention médiatique pour diffuser des pages de connexion factices, des portails de compensation trompeurs ou des demandes malveillantes de connexion de portefeuille.

Si un projet confirme officiellement que son site web ou son backend a été compromis, les utilisateurs doivent suivre l’impact réel divulgué pour décider s’il convient de suspendre leurs interactions, vérifier la présence de transactions anormales et révoquer les autorisations suspectes. Si la fuite de clés privées de signature ou de phrases secrètes est confirmée, cela doit être traité comme un incident de compromission de clé : changer simplement les mots de passe ou se déconnecter du site ne suffit pas. Les utilisateurs de bots de trading, d’outils d’exécution automatisée ou de services hébergés dans le cloud doivent également vérifier si ces services ont publié des versions affectées ou des avis de rotation d’identifiants.

Comment réagir

1. Plates-formes et équipes projets :

Étape 1 : Faire l’inventaire de vos actifs et mettre à jour immédiatement

Recensez tous vos actifs PHP, publics ou internes : hôtes, images conteneur, charges de travail Kubernetes, CMS anciens, backends d’administration, environnements hébergés par des partenaires, extensions tierces et services gérés. Les empreintes techniques ne sont que des indices et ne constituent pas une preuve concluante de « vulnérabilité confirmée ».

Passez aux versions 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 ou appliquez les correctifs équivalents fournis par les distributions, fournisseurs cloud ou prestataires de services gérés. Pour les versions 8.1 et antérieures, demandez un correctif rétroporté à votre éditeur ou migrez dès que possible. Ni « l’environnement hérité est stable » ni « l’application est rarement mise à jour » ne réduisent le risque lié à cette vulnérabilité.

Après la mise à jour, reconstruisez les images conteneur, effectuez des redémarrages progressifs ou remplacez tous les processus workers PHP, puis vérifiez la version en cours d’exécution dans la production — pas seulement celle présente sur la machine de build ou en ligne de commande.

Étape 2 : Que faire si vous ne pouvez pas mettre à jour immédiatement

Réduisez d’abord la surface d’exposition pour gagner du temps, mais cela ne remplace pas la correction :

Isolez les applications PHP exposées à Internet ou ajoutez une authentification réseau et un contrôle d’accès au niveau de l’ingress.

Désactivez les téléchargements de fichiers inutiles et rejetez les requêtes multipart/form-data non nécessaires au niveau du WAF ou du serveur web.

Certaines recommandations de sécurité préconisent aussi : définir memory_limit=-1, désactiver session.upload_progress.enabled, et, sous PHP 8.5, désactiver également fatal_error_backtraces. Ces paramètres ont des incidences sur les fonctionnalités métier et la disponibilité ; testez-les d’abord, puis redémarrez tous les workers PHP après chaque modification.

Étape 3 : Vérifier une éventuelle compromission et renouveler les identifiants

Pour les services affectés ayant été exposés à Internet, menez une enquête à partir des journaux, de la surveillance des points de terminaison et des connexions réseau anormales — par exemple, des processus PHP lançant soudainement des commandes système. En cas de compromission suspectée, préservez d’abord les preuves, puis agissez selon la procédure de réponse aux incidents.

Partez du pire scénario : pour les serveurs non corrigés à temps, renouvelez les clés API, les clés de session, les certificats TLS, les mots de passe base de données, les jetons d’accès cloud, les identifiants CI/CD, les clés RPC/API, les secrets de webhooks et les jetons tiers, et vérifiez tout usage anormal.

Si une version logicielle compromise a été installée ou exécutée dans l’environnement, la simple mise à jour ou réinstallation ne garantit pas l’élimination du risque : vous devez aussi enquêter sur d’éventuelles fuites d’identifiants et portes dérobées persistantes, et, si nécessaire, recréer un environnement propre.

Étape 4 : Sécuriser le plan de contrôle des actifs

La correction de PHP ne doit pas être la seule mesure prise. Plus important encore, assurez-vous qu’« une machine web compromise ne compromette pas le système financier » :

Isolez totalement les clés privées des portefeuilles chauds, des portefeuilles de collecte et des services critiques de signature par rapport aux nœuds web. Utilisez des modules de sécurité matériels (HSM), des protocoles MPC, des réseaux de signature dédiés ou des politiques KMS à privilèges minimaux.

Placez les services web, les services de signature, les nœuds blockchain, les bases de données et les systèmes de build dans des segments réseau et des périmètres d’identité distincts.

Pendant les incidents, resserrer temporairement les opérations à haut risque (retraits, modification des listes blanches d’adresses, élévation des privilèges administrateurs, création de clés API, modifications des règles de contrôle des risques), en activant l’examen manuel ou une activation différée si nécessaire.

Pour les services s’exécutant automatiquement sur chaîne, adopter des mécanismes indépendants de signature, d’approbation multipartenaires, de limites de montant par transaction et d’arrêt d’urgence, selon les besoins métier.

Vérifier les ressources statiques du site, les packages JavaScript, les configurations de proxy inversé, les règles DNS/CDN et les services de construction de transactions afin de s’assurer qu’aucun script malveillant n’a été inséré ou remplacé.

2. Utilisateurs ordinaires :

Utiliser les points d’entrée officiels : récemment, accéder aux plateformes via les favoris ou les canaux officiels, et se méfier de tout lien envoyé sous prétexte d’un « incident de sécurité ».

Ne pas se fier uniquement au domaine et à l’interface : même pour des domaines de dApp familiers, les scripts de page, les paramètres de transaction et les configurations RPC peuvent avoir été remplacés côté serveur par des intrus.

Vérifier chaque élément avant de signer : adresse de réception, chaîne concernée, montant approuvé, contrat appelé et résultats de la simulation de transaction. Être particulièrement vigilant avec les fonctions approve et setApprovalForAll, et encore plus avec les approbations illimitées.

Se méfier des termes « indemnisation », « migration » et « re-vérification » : pendant un incident, des messages tels que « reconnectez-vous », « re-vérifiez votre portefeuille », « migrez vos actifs » ou « réclamez une indemnisation » peuvent apparaître. Ne pas agir uniquement sur la base de pop-ups internes ; croiser les informations via plusieurs canaux officiels du projet.

Stratifier ses actifs : utiliser des portefeuilles matériels pour les gros montants, des portefeuilles à capacité limitée pour les interactions quotidiennes et nettoyer régulièrement les approbations. Ainsi, même en cas de compromission d’un frontend ou d’une plateforme, toute perte reste circonscrite.

S’arrêter immédiatement en cas d’anomalie : face à des demandes inhabituelles de signature, à des invites d’approbation inattendues ou à un comportement suspect du site, faire une pause puis vérifier via les canaux officiels.

Réflexions finales

Les vulnérabilités d’exécution de code à distance sans authentification, comme PHP2Shell, une fois qu’elles franchissent la couche web, peuvent transformer des intrusions serveur classiques en empoisonnement de frontend, usurpation d’identité, détournement des autorisations de signature, risques sur les portefeuilles chauds, voire propagation latérale au niveau de la chaîne d’approvisionnement.

Pour les plateformes, trois priorités : mettre à jour vers les versions corrigées, isoler temporairement les environnements anciens non corrigeables, et auditer les clés ainsi que les plans de contrôle des actifs. Après la mise à jour, rechercher activement les traces d’intrusion doit faire partie intégrante de la réponse à incident. Pour les utilisateurs, durant cette période, faire preuve d’une vigilance accrue vis-à-vis de l’interface web et examiner soigneusement chaque transaction avant de signer. Mais sans céder à la panique : l’existence d’une vulnérabilité ne signifie pas nécessairement une menace directe pour les actifs ; une compromission serveur n’entraîne pas forcément une perte de fonds sur chaîne. Ce qui détermine réellement l’ampleur du risque, c’est quelles identifiants les attaquants ont pu obtenir, quel niveau de privilège ils confèrent et à quelle vitesse le projet peut les isoler et les révoquer. Pour les projets Web3, la sécurité ne consiste pas seulement à empêcher les attaques, mais aussi à anticiper : lorsqu’un composant est effectivement compromis, l’impact peut-il être confiné localement afin que le risque ne se propage pas aux opérations métier et aux actifs centraux ?

Lien original