PHP2Shell : la course contre la montre – ce que les failles PHP signifient pour les sites web, les appareils et vos données

Deux failles critiques dans PHP, un embargo rompu prématurément et des tentatives d’attaque avant même la publication officielle : PHP2Shell ne concerne pas seulement les sites web classiques. Le moteur d’exécution vulnérable peut aussi être intégré à des pare-feu, des panneaux de contrôle d’hébergement et d’autres appareils. Nous expliquons clairement ce qui s’est passé, qui doit agir et ce que vous devez réellement faire en tant que particulier.

Le 20 octobre, deux numéros a priori anodins sont apparus en ligne : CVE-2026-109618 et CVE-2026-109619. Ils désignaient deux vulnérabilités de PHP qui n’avaient pas encore été entièrement divulguées. PHP est la technologie qui traite les formulaires, interroge les bases de données et génère les pages sur d’innombrables serveurs web.

La divulgation devait normalement suivre un déroulement ordonné : d’abord les mises à jour et les règles de protection préparées, puis les détails techniques. Mais les identifiants ont été rendus publics trop tôt, une note maximale erronée de 10,0 a commencé à circuler et, le soir même, une vidéo montrant une attaque fonctionnelle a été publiée par inadvertance. PHP a avancé la sortie d’un jour.

Trop tard pour un démarrage sans heurts : Amazon a ensuite découvert une tentative d’exploitation datée du 17 octobre, soit quatre jours avant le correctif. Après la publication, les fournisseurs ont enregistré une vague d’attaques en forte progression ; Reuters, citant Cloudflare, a fait état de millions de tentatives en quelques heures. Il ne s’agissait pas de millions d’intrusions réussies, mais ces chiffres montrent à quelle vitesse les vulnérabilités critiques sont aujourd’hui testées de manière automatisée.

La faille elle-même ne se trouve pas sur votre smartphone. Elle peut pourtant vous affecter par l’intermédiaire de données stockées chez un fournisseur, de sites web manipulés, d’un phishing plus crédible ou de services désactivés par précaution. Votre appareil peut être sain alors que vos données sont menacées sur le serveur d’un tiers.

L’essentiel à retenir

PHP2Shell désigne deux erreurs de sécurité mémoire dans le cœur de PHP. Dans certaines conditions, des attaquants peuvent exécuter du code sur un serveur sans s’authentifier ; l’une des failles peut également exposer des contenus en mémoire comprenant des jetons de session, des mots de passe, des clés API ou des identifiants de base de données. Les deux CVE sont notées 9,2 selon CVSS 4.0.

Les branches upstream sont corrigées à partir de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les branches plus anciennes peuvent recevoir des correctifs rétroportés par les distributions, les hébergeurs ou les fournisseurs LTS. La seule mise à jour d’un CMS ou d’un plugin ne suffit pas : c’est le moteur d’exécution PHP qui traite réellement les requêtes web qui compte.

Les particuliers n’ont rien à installer sur leur téléphone. Les exploitants doivent inventorier et corriger les sites web, conteneurs, interfaces d’administration et appareils utilisant PHP, puis rechercher d’éventuelles attaques antérieures.

1. Comment un ancien problème de mémoire est devenu une course mondiale contre la montre

2024 : un signal d’alerte sans attaque démontrée

L’histoire commence dès 2024. Lors d’un audit de sécurité externe de PHP, les premiers signes de ce qui allait devenir le problème d’épuisement de mémoire ont été relevés. Il n’existait toutefois aucun chemin fiable permettant de passer d’une requête web à l’exécution de code, et les correctifs envisagés risquaient de nuire à la compatibilité ou à la stabilité. La petite équipe de sécurité n’est pas parvenue rapidement à un consensus. La PHP Foundation a ensuite qualifié ouvertement ce retard d’échec structurel : les processus décisionnels étaient trop lourds et les ressources trop limitées.

Été 2026 : la recherche assistée par l’IA transforme la théorie en pratique

En juillet et août 2026, Calif, OpenAI et Wiz ont examiné le cœur de PHP à l’aide de méthodes classiques et de puissants modèles d’IA. Le 11 août, un chemin concret vers une exécution de code à distance a été signalé ; Wiz a découvert indépendamment d’autres variantes et démontré des chaînes d’attaque contre des applications PHP réelles. Des humains devaient toujours reproduire les résultats, éliminer les faux positifs et examiner les correctifs. L’IA a néanmoins raccourci la recherche – et, avec elle, le délai dont disposent les défenseurs après la publication d’une faille.

17 octobre : la première tentative connue

Amazon Threat Intelligence a ensuite identifié rétrospectivement, dans la télémétrie MadPot, une tentative d’exploitation datée du 17 octobre. Une détection sur un honeypot ne prouve pas que des systèmes réels ont été compromis avec succès, mais elle repousse le point de départ de la recherche forensique. On ignore comment l’acteur a obtenu si tôt suffisamment d’informations ; aucune attribution fiable n’est disponible.

20 et 21 octobre : l’embargo est rompu, le correctif paraît

Le 20 octobre, les identifiants CVE ont commencé à circuler publiquement, avec la note CVSS erronée de 10,0 et une vidéo d’attaque publiée par inadvertance. PHP a avancé la sortie au 21 octobre à 14 h 00 UTC. Les hébergeurs, distributions et fournisseurs de sécurité ont préparé en parallèle des paquets et des filtres. Cloudflare a activé des règles de protection avant même la sortie en combinant des signaux issus des requêtes et des réponses. Un WAF ne reste toutefois qu’une barrière supplémentaire : il ne corrige pas le code PHP vulnérable.

Les versions corrigées ont été publiées le 21 octobre ; des outils d’exploitation publics et des scans massifs ont suivi peu après. Des administrations, des hôpitaux, des universités et des entreprises ont retiré préventivement certains services du réseau, notamment, pendant un temps, des services de police à Berlin et dans le Brandebourg. Cela ne prouve pas une intrusion ; cela peut au contraire témoigner d’un processus d’urgence efficace : mieux vaut une mise hors ligne contrôlée qu’un système compromis sans contrôle. PHP2Shell montre aussi que les systèmes exposés à Internet doivent réagir aux failles RCE critiques en quelques heures, et non en quelques jours.

Deux vulnérabilités PHP critiques, des tentatives d’exploitation actives et une surface d’attaque potentielle considérable sont confirmées. On ignore toujours combien de systèmes ont réellement été compromis ou combien de données ont été perdues.

2. Ce qui se passe techniquement – sans jargon inutile

PHP travaille dans la salle des machines d’un site web : il exécute le code de WordPress, des boutiques en ligne ou des portails, traite les entrées et communique avec les bases de données. Les erreurs se situent sous la couche du CMS. Une application entièrement à jour peut donc malgré tout fonctionner sur un moteur PHP vulnérable.

CVE-2026-109618 : nettoyage de données incomplètes

Si PHP atteint son memory_limit au mauvais moment, le traitement peut s’interrompre alors que des structures de données internes ne sont que partiellement initialisées. Lors du nettoyage, PHP peut alors traiter ces zones comme des données valides. Un attaquant cherche à provoquer délibérément cet état et à influencer l’organisation de la mémoire afin d’aboutir à une exécution de code.

Une attaque non authentifiée a été démontrée sur Apache avec mod_php ; elle peut agir avant même l’exécution du code de l’application. Une connexion, une authentification à deux facteurs ou un plugin de sécurité WordPress ne protègent alors pas. D’autres modes d’exploitation de PHP peuvent également être concernés ; les conditions préalables et la fiabilité varient selon la SAPI, l’application et la configuration.

CVE-2026-109619 : une ancienne référence survit à la requête suivante

Dans la seconde faille, une référence vers une zone mémoire déjà libérée subsiste après une erreur grave. Lorsque le même worker PHP traite une requête ultérieure, il réutilise cet état obsolète – un use-after-free, autrement dit un état global périmé.

Les conséquences possibles sont l’exécution de code, des plantages ou la divulgation de contenu mémoire. Cette dernière est particulièrement insidieuse : un attaquant n’a pas besoin de laisser une webshell visible pour obtenir des jetons de session, des mots de passe de base de données, des clés API ou des certificats. Après l’application du correctif, il ne suffit donc pas de rechercher uniquement des fichiers modifiés.

Remote Code Execution signifie d’abord que du code est exécuté avec les droits du compte PHP ou du serveur web, et non automatiquement avec un accès root. Ce compte peut néanmoins lire des configurations, atteindre des bases de données ou accéder à des services internes. Les droits sur les fichiers, la segmentation du réseau et le principe du moindre privilège déterminent donc jusqu’où une compromission peut se propager.

3. Près de 70 % d’Internet sont-ils réellement concernés ?

Au 23 octobre 2026, W3Techs indique que PHP est utilisé par 69,3 % des sites web dont le service peut identifier le langage de programmation côté serveur. Parmi ces sites PHP, 65,3 % utilisent PHP 8, 26,9 % PHP 7 et 7,7 % PHP 5.

Ces chiffres décrivent la diffusion de PHP, et non l’état des correctifs ni le nombre d’attaques réussies. De nombreux systèmes ont été mis à jour en quelques heures, les distributions fournissent des rétroportages sous des numéros de version plus anciens et, sur certains appareils, le chemin vulnérable peut ne pas être accessible publiquement. La formulation raisonnable est donc la suivante : environ sept sites sur dix dont le langage côté serveur est identifiable utilisent PHP et ont dû vérifier leurs protections. Il est impossible de chiffrer sérieusement combien restent aujourd’hui vulnérables ou compromis.

4. Ce que PHP2Shell signifie pour vous en tant que particulier

PHP n’infecte pas directement votre appareil

PHP2Shell s’exécute sur des serveurs. Vous n’avez pas besoin de réinitialiser votre smartphone ni d’installer une application spéciale. Votre appareil n’est menacé que si un site manipulé vous incite à télécharger un contenu malveillant. Maintenez votre système, votre navigateur et vos applications à jour et utilisez uniquement des sources fiables. Une prétendue « mise à jour PHP2Shell » destinée à votre appareil est très probablement un leurre.

Vos données peuvent tout de même être concernées

Lorsque vous commandez dans une boutique en ligne, votre nom, votre adresse et l’historique de vos commandes peuvent y rester enregistrés longtemps. Si le serveur est compromis, ces données peuvent être touchées même si vous n’avez pas consulté le site depuis des mois. La divulgation de mémoire peut en outre révéler des jetons et des clés d’accès qui ne sont pas stockés sous forme de fichiers sur le serveur.

Même un site connu peut être manipulé : le domaine et l’icône de cadenas restent identiques tandis qu’un script injecté dérobe des données de connexion ou de paiement. HTTPS protège le trajet jusqu’au serveur, pas l’intégrité de celui-ci. Interrompez l’opération en cas de fenêtre de paiement inhabituelle, de redirection ou de téléchargement inattendu, puis contactez le fournisseur par un canal connu.

Après l’attaque technique vient souvent la fraude

Les informations volées rendent le phishing plus crédible. Même un message contenant votre vrai nom et le bon numéro de commande peut être falsifié. Ouvrez les services importants via l’application officielle, un favori ou une adresse saisie manuellement. Les signes d’une prise de contrôle de compte comprennent des alertes de connexion ou de réinitialisation de mot de passe inattendues, des sessions inconnues, des données de récupération modifiées, ainsi que des demandes push, TAN ou d’authentification à deux facteurs que vous n’avez pas déclenchées. Ne confirmez rien « par précaution » : vérifiez directement le compte et supprimez les appareils inconnus.

Pour les services bancaires en ligne, un mot de passe ou un code PIN ne suffit généralement pas à lui seul grâce à l’authentification forte du client. Le phishing peut toutefois vous amener à valider une autorisation réelle pour la connexion ou le paiement d’un tiers. Vérifiez le bénéficiaire, l’IBAN et le montant ; en cas d’opération inconnue, contactez la banque via son application officielle ou un numéro connu.

Ce que vous pouvez utilement faire maintenant

Si un service signale uniquement une maintenance ou une interruption préventive, il n’est pas nécessaire de modifier tous vos mots de passe au hasard ni de bloquer vos cartes. Utilisez un canal de remplacement officiel et suivez les communications du fournisseur.

Si un fournisseur signale une possible fuite d’identifiants, modifiez ce mot de passe sur le service concerné et partout où vous l’avez réutilisé. Fermez les sessions actives, activez l’authentification à deux facteurs ou les passkeys et sécurisez en priorité votre compte de messagerie.

Si vous avez saisi des données sur un site suspect ou installé une prétendue application de sécurité, sécurisez vos comptes depuis un autre appareil, contactez votre banque si des données de paiement sont concernées et faites contrôler l’appareil touché.

Aucune application de sécurité et aucun VPN ne peuvent réparer le moteur PHP de la boutique en ligne d’un tiers. Un logiciel de protection peut aider face à la seconde vague d’attaques impliquant des téléchargements malveillants, de fausses applications et des sites malveillants connus – mais il ne garantit pas la sécurité de vos données sur un serveur externe.

5. PHP se trouve aussi dans les pare-feu, les systèmes NAS et d’autres appareils

PHP n’est pas présent uniquement sur les sites web, mais aussi dans les interfaces d’administration et les services complémentaires de pare-feu, routeurs, systèmes NAS, panneaux de contrôle d’hébergement, installations VoIP, enregistreurs de caméras ou appliances industrielles. Un produit n’est toutefois concerné que s’il utilise une version vulnérable de PHP pour traiter des requêtes web accessibles. Le niveau d’exposition et la disponibilité d’un correctif du fabricant comptent également.

pfSense : Netgate a confirmé que l’interface graphique fondée sur PHP et le portail captif sont concernés. L’interface standard n’est généralement accessible que depuis le LAN ; un portail captif sert intentionnellement des clients non fiables. La même erreur présente donc un risque différent selon son exposition.

Palo Alto Networks : certaines versions de PAN-OS et de Panorama sont concernées. Selon le fabricant, le problème touche l’interface web d’administration, y compris l’API XML, mais pas de manière générale le plan de données ni GlobalProtect. Jusqu’à l’installation du correctif, l’administration ne devrait être accessible que depuis des réseaux de confiance ou via un jump host contrôlé.

Plesk : les sites des clients utilisent leurs propres gestionnaires PHP, tandis que l’interface Plesk repose sur un moteur distinct. Mettre à jour une seule couche peut laisser l’autre de côté. Plesk a donc publié des mises à jour pour les deux composants.

Cisco et Sophos montrent pourquoi il faut évaluer séparément les produits, les services cloud et les installations chez les clients. Cisco a confirmé que certaines familles de produits étaient concernées, en a classé d’autres comme non affectées et en examinait encore plusieurs. Sophos a déclaré ses produits non concernés, mais a temporairement mis hors ligne l’ancien portail MyUTM, hébergé séparément, parce qu’il utilisait une version vulnérable de PHP.

Le NCSC néerlandais tient à jour une liste de statut continuellement actualisée. Il s’agit d’un inventaire précieux, mais il ne remplace pas le dernier avis du fabricant : une dépendance à PHP ne prouve pas à elle seule l’exploitabilité, et l’absence de signalement ne constitue pas un feu vert.

Ce qu’il faut vérifier sur un appareil à domicile ou dans l’entreprise

Relevez le fabricant, le modèle, le firmware et les paquets complémentaires. Recherchez les deux CVE et « PHP2Shell » sur le site d’assistance officiel, puis installez les mises à jour uniquement au moyen de la fonction prévue pour le firmware ou les paquets. Ne remplacez jamais vous-même une version intégrée de PHP ; les appliances contiennent souvent des adaptations du fabricant et des composants signés.

Désactivez l’administration à distance depuis le WAN, les redirections de ports et ouvertures UPnP inutiles, puis vérifiez les accès distants via le cloud. Si vous avez besoin d’un accès externe, utilisez si possible un VPN et n’ouvrez l’interface locale qu’après vous être connecté.

Séparez les réseaux invités, IoT et d’administration afin que des appareils compromis ne puissent pas atteindre les services d’administration locaux. Lorsqu’un pare-feu, un NAS ou un enregistreur de caméras ne reçoit plus de mises à jour de sécurité, son remplacement est souvent la seule solution durable.

6. Ce que les exploitants doivent concrètement faire maintenant

Étape 1 : clarifier les responsabilités et établir l’inventaire

Avec un hébergement managé, le fournisseur effectue généralement la mise à jour ; avec des VPS, des serveurs dédiés, des conteneurs et des appliances, vous ou votre prestataire êtes responsables. Exigez une réponse vérifiable concernant les deux CVE, la version du paquet ou du firmware et le redémarrage de tous les processus PHP. Inventoriez en parallèle les domaines, sous-domaines, environnements de staging, anciens projets, services webmail, conteneurs et appareils intégrant PHP.

Étape 2 : vérifier le bon niveau de correctif

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35. Des rétroportages du code source sont disponibles pour PHP 7.4, 8.0 et 8.1 ; l’avis de la distribution ou du fournisseur LTS fait foi.

Les distributions peuvent rétroporter des correctifs vers des versions de paquets plus anciennes. Ubuntu 24.04 LTS indique par exemple que la version 8.3.6-0ubuntu0.24.04.13 est corrigée ; cPanel a également fourni des rétroportages. Comparez donc la version complète du paquet avec l’avis de la distribution ou du fournisseur de plateforme, et non uniquement avec le numéro upstream brut.

Étape 3 : vérifier le moteur d’exécution réellement actif

php -v n’affiche généralement que la version en ligne de commande. Le serveur web peut utiliser une autre installation via PHP-FPM, mod_php ou un conteneur. Vérifiez donc les pools FPM, les modules du serveur web, les hôtes virtuels et les images :

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

Après la mise à jour, les anciens workers doivent être remplacés : avec mod_php, généralement en redémarrant le serveur web ; avec PHP-FPM, en redémarrant les pools. Redémarrer un conteneur avec la même image ne suffit pas ; l’image doit être mise à jour puis redéployée.

Étape 4 : empêcher les requêtes d’atteindre PHP sur les systèmes non corrigeables

Si vous ne pouvez pas appliquer le correctif immédiatement, limitez l’accès aux réseaux de confiance ou à un VPN – ou retirez le service du réseau. Un plugin de maintenance WordPress ne protège pas si l’attaque intervient avant le code de l’application. Utilisez une page de maintenance statique ou bloquez l’accès au niveau du reverse proxy, de l’équilibreur de charge ou du serveur web.

Les règles WAF et CDN peuvent faire gagner du temps, mais ne constituent pas un correctif. Cloudflare a observé des schémas d’attaque changeants et a dû évaluer conjointement les requêtes et les réponses. Assurez-vous également que le serveur d’origine n’est pas directement accessible via une seconde adresse IP ou un autre nom d’hôte.

Les mesures de configuration PHP, telles que la désactivation de la progression des téléversements de session ou l’application de limites plus strictes pour la mémoire et les téléversements, ne réduisent que certains chemins d’attaque et peuvent avoir des effets secondaires.

Étape 5 : remonter au moins jusqu’au 17 octobre

Conservez les journaux des serveurs web, de PHP, des proxys, des WAF, des systèmes et des conteneurs avant leur rotation. Recherchez des requêtes de formulaire inhabituelles, PHP_SESSION_UPLOAD_PROGRESS, des erreurs mémoire, des processus shell inattendus, de nouveaux fichiers, comptes ou cron jobs, ainsi que des connexions sortantes. Une attaque réussie ne doit pas nécessairement faire planter le worker ; inversement, une erreur isolée ne prouve pas une intrusion. C’est l’ensemble des indices qui compte.

Étape 6 : renouveler les secrets accessibles à PHP

Puisque des contenus en mémoire peuvent être divulgués, vous devez renouveler, sur les systèmes exposés à Internet qui n’étaient pas corrigés, tous les secrets que le processus PHP pouvait lire – par exemple les mots de passe de base de données, les jetons API, cloud et de déploiement, les identifiants SMTP ou OAuth et les clés de session. Corrigez ou isolez d’abord le système affecté, puis générez de nouveaux identifiants depuis un environnement de confiance.

Étape 7 : en cas d’indices de compromission, ne pas se contenter de « nettoyer »

En présence d’indices de compromission, isolez le système de manière contrôlée, conservez les journaux et, si nécessaire, les données volatiles, puis reconstruisez les hôtes critiques à partir d’artefacts de confiance au lieu de supprimer uniquement les fichiers visibles. Examinez aussi les comptes administrateur et de base de données, les pipelines de déploiement et les systèmes connectés. Si des données personnelles peuvent être concernées, associez rapidement les responsables de la protection des données ; en vertu du RGPD, une violation soumise à notification doit en principe être déclarée dans les 72 heures.

7. La leçon générale : la découverte s’accélère, la correction doit suivre

PHP2Shell montre comment l’IA déplace la frontière entre ce qui est « théoriquement possible » et ce qui est « exploitable en pratique ». Les modèles peuvent analyser à grande échelle du code source, des traces de plantage et les différences entre correctifs ; le délai entre la divulgation et l’apparition d’un code d’exploitation fonctionnel se raccourcit donc lui aussi.

La réponse ne consiste pas simplement à utiliser davantage d’IA. Les mainteneurs ont besoin de ressources et de processus décisionnels clairs ; les exploitants, d’inventaires complets, de circuits de mise à jour courts, d’isolation et de procédures de restauration éprouvées. Chez Protectstar, nous utilisons l’IA en complément des revues de code et de la validation humaine. Elle accélère la recherche, mais ne remplace pas la responsabilité.

Conclusion

PHP2Shell touche les serveurs, mais peut vous atteindre sous la forme d’un risque pour vos données, d’une tentative de fraude ou d’une interruption de service. Restez vigilant sans céder à la panique : utilisez les canaux de contact officiels, ne validez aucune demande inattendue et réagissez de manière ciblée aux informations des fournisseurs concernés.

Pour les exploitants, les éléments décisifs sont le moteur PHP réellement actif, chaque instance oubliée, les composants intégrés, le redémarrage des anciens processus et l’analyse rétrospective remontant au moins au 17 octobre. En l’absence de correctif, l’isolation est plus responsable que la poursuite de l’exploitation. Un site accessible n’est pas une preuve de sécurité.