Faille PHP php2shell : ce qu'un CTO doit faire maintenant

Mis à jour le 21 octobre 2026 : ajout du billet de la PHP Foundation, qui corrige ce qui avait fuité avant la publication, précise les configurations où l'exécution de code a été démontrée et annonce les mesures de sécurité pour la suite. Complété le même jour avec le billet d'OpenAI sur la découverte de la faille par l'IA et sur sa proposition de cadre de divulgation coordonnée, puis avec les rétroportages du dépôt d'Ondřej Surý pour les vieilles versions de PHP.

Mercredi 21 octobre, 16 h, heure de Paris. L'équipe de PHP publie PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux failles d'exécution de code à distance sans authentification, baptisées php2shell. Quelques heures plus tôt, des sites gouvernementaux néerlandais, finlandais et français s'étaient mis hors ligne par précaution, et Cloudflare voyait déjà passer des tentatives d'exploitation. C'est l'une des alertes web les plus larges depuis des années, parce qu'elle ne touche pas une application mais le moteur sur lequel tournent une grande partie des sites.

Je fais ici le point sur ce qui est établi ce soir, ce qui ne l'est pas, et sur ce qu'un CTO ou un dirigeant de PME doit faire dans les jours qui viennent. Les correctifs sont sortis ; la difficulté maintenant, c'est de trouver tout le PHP qu'on fait tourner, y compris celui qu'on a oublié.

Ce qui a été corrigé

Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619, notées toutes deux 9,2 sur 10 (CVSS v4) par l'équipe de PHP. Elles ont la même racine : PHP peut laisser sa mémoire dans un état incohérent quand une requête se termine anormalement.

• CVE-2026-109618 : quand PHP manque de mémoire en cours de requête, il peut être interrompu alors que des données internes ne sont que partiellement initialisées. Le nettoyage de fin de requête les traite ensuite comme valides, ce qui corrompt la mémoire.
• CVE-2026-109619 : un état interne lié à une requête peut survivre après la libération de sa mémoire. La requête suivante traitée par le même processus peut le réutiliser avant qu'il soit réinitialisé.

Le bulletin de PHP est sans ambiguïté sur le périmètre : toutes les installations qui servent des requêtes web sont concernées, que ce soit PHP-FPM, Apache avec modphp, php-cgi, FrankenPHP ou LiteSpeed. Le risque est jugé maximal pour modphp, avec un exploit démontré où une requête non authentifiée déclenche l'attaque avant même que le code de l'application s'exécute. Le billet de la PHP Foundation publié le soir même précise les conditions. Pour CVE-2026-109618, l'exécution de code a été démontrée sur Apache avec modphp avec les réglages par défaut, et confirmée sur PHP-FPM en passant par du code applicatif. Pour CVE-2026-109619, un use-after-free et des plantages de workers sont confirmés, et l'exécution de code a été démontrée contre une application réelle sous Apache avec modphp. Autrement dit, sous mod_php, la qualité de votre code WordPress, Symfony ou Laravel n'y change rien ; sous PHP-FPM, le risque dépend davantage de ce que fait l'application, mais il est réel.

Pour les versions plus anciennes, la situation est moins confortable. PHP 8.1 et antérieurs ne sont plus maintenus par le projet. Vu la gravité, l'équipe a tout de même publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, à compiler soi-même. Rien n'est prévu pour PHP 5. Le CERT-FR liste comme affectées toutes les versions 5.x à 8.x et recommande, pour les branches non maintenues, d'isoler les équipements puis de migrer.

Côté exploitation, il faut être précis. Selon la PHP Foundation, ce sont les identifiants CVE qui ont circulé à partir du 20 octobre vers 17 h (heure de Paris), avec une heure de publication et une note de 10,0 erronées, mais sans détail technique. La publication, prévue le 22 octobre, a alors été avancée d'un jour. Ensuite, Calif, l'une des sociétés à l'origine des signalements, a publié par erreur une vidéo de sa preuve de concept, vite supprimée mais recopiée, qui a accéléré le développement d'exploits. Et le 21 octobre à 9 h 41, plus de six heures avant la publication coordonnée, Chainguard a rompu l'embargo en diffusant des images contenant le correctif, que n'importe quel attaquant pouvait comparer à la version précédente. L'équipe de sécurité de PHP dit n'avoir identifié aucun exploit fonctionnel au moment de la publication. Cloudflare, de son côté, dit avoir observé des attaques sur ses clients avant la sortie des correctifs : des tentatives, qui ne prouvent pas des compromissions réussies. Enfin, ce soir, les failles ne figurent pas au catalogue des vulnérabilités exploitées de la CISA (KEV), et le bulletin de PHP ne mentionne pas d'exploitation active. La prudence impose de considérer que l'exploitation de masse est une question d'heures ou de jours, maintenant que les correctifs peuvent être comparés aux versions précédentes.

« 70 % du web » : ce que dit vraiment le chiffre

Le chiffre circule partout, et il est à peu près juste. Selon W3Techs, PHP est utilisé par 69,3 % des sites dont on connaît le langage côté serveur. Cloudflare reprend un ordre de grandeur similaire dans son billet : « presque 70 % des sites web ».

Deux nuances, pourtant. D'abord, ce sont des sites dont le langage est identifiable, pas 70 % de l'Internet. Ensuite, la population est vieille : toujours selon W3Techs, 27 % des sites PHP tournent encore en version 7 et 7,7 % en version 5. Ce sont précisément les branches qui ne recevront pas de mise à jour officielle simple. Le vrai sujet n'est donc pas « 70 % du web est vulnérable », mais « une part importante du web PHP tourne sur des versions que personne ne mettra à jour rapidement ».

À l'inverse, une partie du web PHP sera corrigée sans que ses propriétaires lèvent le petit doigt : celle qui tourne sur les paquets d'une distribution Linux ou d'un éditeur LTS, qui ont reçu les correctifs en avance selon PHP, et chez les hébergeurs mutualisés qui appliquent ces paquets. Attention au piège relevé par Wordfence : la mise à jour automatique de WordPress ne met pas à jour PHP. Il faut savoir qui, de vous, de votre hébergeur ou de votre infogérant, est responsable du moteur.

Ce qu'a dit le CTO de Cloudflare

Dane Knecht, CTO de Cloudflare, a été l'une des voix les plus suivies de la journée. À 9 h 43, heure de Paris, il a écrit sur X :

« PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show up. This is a STOPGAP only. Patch as soon as @ThePHPF releases the update at 14:00 UTC today. »

En français : les sites PHP derrière Cloudflare ont déjà des règles de pare-feu applicatif contre les vecteurs connus, y compris en offre gratuite ; des attaques émergent ; mais ce n'est qu'une solution d'attente, il faut appliquer le correctif. Plus tôt dans la nuit, en réponse à un utilisateur, il insistait : « There is no bulletproof solution otherwise. »

Le billet technique de Cloudflare détaille la suite : règles actives depuis 3 h 02 UTC, environ neuf heures avant la publication, et attaquants observés en train de modifier leurs charges pour contourner les règles. Cloudflare a dû inspecter aussi la réponse du serveur, pas seulement la requête, pour distinguer une attaque d'un trafic légitime. C'est un bon indicateur de la difficulté : un WAF achète du temps, il ne ferme pas la faille.

Les sites mis hors ligne ou en lecture seule

Le fait le plus marquant de la journée, c'est le nombre d'organisations qui ont choisi de couper plutôt que d'attendre. Le CERT-EU avait recommandé d'isoler les applications exposées si la mise à jour immédiate n'était pas possible, et le NCSC britannique de mettre hors ligne ce qui ne pouvait pas être corrigé tout de suite. Plusieurs l'ont fait, et de façon documentée :

• Pays-Bas : selon DutchNews, MijnOverheid, DigiD, le site du Parlement, celui du NCSC néerlandais et celui de l'autorité de protection des données ont été coupés.
• Finlande : Valtori, le centre informatique de l'État, a mis hors ligne des services web publics, dont le site du cadastre national, rapporte Yle.
• France : le ministère de l'Intérieur a indiqué avoir temporairement retiré les sites des préfectures en attendant le correctif. Next a constaté la CNIL en maintenance vers 12 h 30, et s'est mis lui-même en maintenance.
• Australie : GovCMS, la plateforme qui héberge les sites du gouvernement, a coupé l'accès direct à ses serveurs d'origine et ne sert plus que les pages en cache via son CDN. Les sites restent lisibles, mais plus personne ne peut s'y connecter ni publier.
• Lecture seule : 4chan a affiché être « temporairement en lecture seule en attendant une mise à jour de sécurité urgente de PHP », selon Next, et DeviantArt est passé en maintenance.

GovCMS et 4chan illustrent une option intermédiaire qui mérite d'être préparée à froid : servir le contenu depuis un cache ou n'accepter que les requêtes de lecture, et couper tout le reste. Mattias Geniar a documenté la recette pour nginx : refuser toutes les méthodes sauf GET et HEAD bloque la plupart des chemins d'attaque confirmés, qui ont besoin d'un corps de requête, mais pas tous. Il signale aussi un piège : désactiver seulement le gestionnaire PHP peut amener Apache ou nginx à servir vos fichiers .php en texte brut, mots de passe compris. Pour couper, on arrête le serveur web ou on répond 503 partout.

Routeurs, box et objets connectés : la longue traîne

Ce matin, tout le monde parlait des Freebox. Infrawatch avait compté 1,97 million de Freebox parmi les hôtes PHP exposés, plaçant la France en tête mondiale. C'était une erreur de détection : selon Frandroid, repris par Numerama, Freebox OS n'embarque aucun serveur PHP. Ses fichiers d'interface portent l'extension .php, mais ils sont lus par un logiciel développé par Free. Les abonnés n'ont rien à faire. Free n'avait pas communiqué officiellement ce soir.

La leçon reste valable dans l'autre sens : un scanner qui devine la technologie à partir d'une extension se trompe, et vous aussi si vous inventoriez de la même façon. Et le vrai risque embarqué existe, même s'il est encore peu documenté pour cette faille précise. PHP sert d'interface d'administration à des NAS, des enregistreurs vidéo, des routeurs professionnels et des boîtiers industriels : on trouve des avis de sécurité de Netgear, NetModule ou Phoenix Contact visant des scripts PHP de leurs interfaces web, pour d'autres failles. Hal Pomeranz, expert en investigation numérique, résumait ainsi la situation, cité par Help Net Security : « So many embedded installations out there that will never be patched. Too many forgotten, unmaintained apps. There will be a long tail for this one. »

Je n'ai trouvé ce soir aucun avis de constructeur confirmant qu'un routeur ou un objet connecté précis est vulnérable à php2shell. Il faut donc poser la question à ses fournisseurs, pas attendre qu'ils la posent.

Ce que je ferais cette semaine

L'arbre de décision, du plus simple au plus radical. Toutes les branches sauf la première sont des solutions d'attente.

1. Inventorier tout le PHP, pas seulement les sites. Le site vitrine et la boutique, on les connaît. Les autres sont plus discrets : l'outil de ticketing auto-hébergé, le Nextcloud, le phpMyAdmin d'un ancien prestataire, le webmail, l'intranet RH, l'image Docker figée en PHP 7.4, la console d'un NAS. Croisez trois sources : vos hébergeurs et infogérants, un scan de votre propre surface exposée, et la liste des fournisseurs dont un équipement a une interface web. C'est la même logique que dans notre dossier sur les fuites par les prestataires : l'outil oublié est souvent la porte d'entrée.

2. Corriger, puis redémarrer vraiment. Mise à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le paquet de votre distribution. Les failles touchent l'état des processus : redémarrez tous les workers PHP-FPM et Apache, pas seulement le service principal. Si vous dépendez du dépôt bénévole rpms.remirepo.net, PHP recommande de passer aux paquets de la distribution, ce dépôt n'étant pas à jour le jour même.

Si vous ne pouvez pas migrer tout de suite, une option existe pour Debian et Ubuntu. Le dépôt communautaire d'Ondřej Surý, packages.sury.org, que beaucoup d'équipes utilisent déjà pour installer plusieurs versions de PHP, a publié le 21 octobre des paquets corrigés pour toutes les branches de 5.6 à 8.1, comme l'a relevé un développeur sur X. J'ai vérifié les journaux de modifications des paquets pour Debian 12 : les entrées de PHP 5.6.40-104, 7.0.33-92, 7.1.33-80, 7.2.34-66, 7.3.33-35, 7.4.33-31, 8.0.30-25 et 8.1.34-9 citent bien CVE-2026-109618 et CVE-2026-109619. Trois réserves. C'est un dépôt tiers, maintenu par une personne, pas une mise à jour de votre distribution. C'est une rustine sur des versions qui ne reçoivent plus d'autres correctifs officiels, pas un plan de migration. Et il faut vérifier sur chaque serveur, avec zcat /usr/share/doc/php7.4-cli/changelog.Debian.gz | head -40 par exemple, que les deux identifiants apparaissent dans l'entrée installée : le numéro affiché par php -v ne change pas avec un rétroportage. Si vous restez sur les paquets de Debian, la mise à jour de sécurité est sortie pour Debian 12 (php8.2 8.2.35-1~deb12u1, DLA-4848-1) et Debian 13 (php8.4 8.4.27-1~deb13u1, DSA-6574-1), selon le suivi de sécurité Debian. Pour un support long sur de vieilles branches avec un engagement contractuel, Freexian vend une offre PHP LTS, opérée avec Ondřej Surý.

3. Acheter du temps là où on ne peut pas corriger. Le WAF, chez Cloudflare ou ailleurs, filtre les vecteurs connus. Le CERT-FR et PHP listent des mesures temporaires : désactiver session.upload_progress.enabled dans php.ini ou dans la configuration du pool FPM, réduire post_max_size, limiter la taille des requêtes au niveau du proxy, surveiller ou bloquer les requêtes multipart. Aucune ne protège complètement, PHP le répète dans son bulletin.

4. Décider à froid de ce qui peut passer en lecture seule ou hors ligne. Les administrations qui ont coupé mercredi avaient une décision à prendre en quelques heures. Faites la liste maintenant : quels services peuvent tourner en lecture seule ou depuis un cache, lesquels peuvent s'arrêter une nuit, qui a le droit de décider. Le jour où la prochaine faille de cette ampleur tombe, c'est une ligne de runbook, pas une réunion de crise.

5. Mettre la pression sur les fournisseurs d'équipements. Pour chaque boîtier avec interface web : est-ce du PHP ? Quelle version ? Un correctif est-il prévu, et quand ? En attendant la réponse, l'interface d'administration n'a rien à faire sur Internet : VPN, liste d'adresses autorisées ou coupure.

6. Chercher les traces. Des tentatives d'attaque ont été observées avant les correctifs. Regardez les journaux depuis le 20 octobre : requêtes multipart anormalement volumineuses, plantages ou erreurs de mémoire des workers, fichiers PHP récemment créés dans les répertoires accessibles en écriture. AppArmor ou SELinux peuvent empêcher le worker PHP de lancer un shell, ce qui limite les dégâts sans corriger la faille.

Ce que ça dit de notre dépendance

Le billet de la PHP Foundation est d'une franchise rare. La cause de CVE-2026-109618 avait été repérée dès 2024, lors du premier audit externe de PHP depuis des années, mené par Quarkslab et financé par la Sovereign Tech Agency allemande. Faute de chemin d'exploitation connu, et parce que chaque correctif possible cassait la compatibilité, ouvrait un risque de déni de service ou imposait de modifier des extensions tierces, le travail a calé pendant des mois. La fondation parle d'un « échec structurel », dû au mode de décision de l'équipe de sécurité et au manque de moyens. Il a fallu les signalements de Calif et d'OpenAI le 11 août, puis de Wiz, pour que le correctif devienne la priorité.

Pour la suite, la fondation annonce plusieurs changements. Une équipe dédiée à la sécurité de l'écosystème existe depuis mai 2026, renforcée par des recrutements en juillet et septembre pour le tri des signalements et le durcissement du moteur. L'équipe de sécurité décidera désormais à la majorité plutôt qu'au consensus, et un problème bloqué sur un arbitrage difficile remontera plus tôt à la direction de la fondation. Les audits continuent, avec Calif et Trail of Bits, et des outils d'IA servent à valider les signalements, devenus beaucoup plus nombreux : 15 CVE publiées depuis le 1er juillet, plus de 100 signalements invalides ou en double. Mais la fondation rappelle que la sécurité du moteur repose sur une poignée de développeurs qu'elle finance, et demande aux entreprises, hébergeurs et administrations qui dépendent de PHP de contribuer.

Le billet publié par OpenAI le même jour éclaire l'autre moitié de l'histoire. Calif a trouvé une faille critique avec un modèle d'OpenAI, GPT-5.6 Sol, dans le cadre du programme Patch the Planet, et Wiz a découvert et signalé les deux failles de son côté. OpenAI dit avoir coordonné pendant deux mois une coalition de mainteneurs, de chercheurs et de fournisseurs comme Cloudflare, et sollicité la CISA, l'ONCD et d'autres agences pour que les consignes atteignent les opérateurs d'infrastructures critiques. Selon OpenAI, l'IA a trouvé ces failles avant les attaquants, ce qui a laissé aux défenseurs le temps de préparer correctifs et règles de WAF.

Deux phrases du billet comptent pour un CTO. D'abord, ces failles font partie de « plusieurs vulnérabilités importantes » déjà trouvées et en cours de correction, sans que les autres projets soient nommés, et OpenAI s'attend à ce que ce type de découvertes « augmente fortement dans les mois qui viennent ». Ensuite, les mêmes capacités peuvent aider les attaquants à écrire vite des exploits. OpenAI propose un cadre de réponse en cinq étapes, ouvert aux commentaires : valider et corriger en amont, en cherchant avec des modèles les contournements du correctif ; prévenir à l'avance les organisations qui ont un rôle de protection, distributeurs, hébergeurs, éditeurs de WAF ; associer les agences gouvernementales ; préparer les mises à jour en aval ; publier les consignes et accompagner le déploiement. Le calendrier serait revu en cas d'exploitation, de fuite ou de correctif trop révélateur, ce qui est exactement ce qui s'est passé cette semaine.

Mis bout à bout, les deux billets décrivent la même tendance : trouver des failles devient bon marché, les corriger et les déployer ne l'est pas. La fondation PHP traite déjà beaucoup plus de signalements qu'avant, curl traitera ses failles mineures en public à partir du 26 octobre face à l'avalanche de signalements, et le goulot se déplace vers la vérification et le déploiement. Pour une entreprise, la conséquence est simple : des alertes de l'ampleur de php2shell vont se répéter, et la seule réponse durable est de savoir en quelques heures ce qu'on fait tourner, qui le met à jour et ce qu'on peut couper.

Php2shell rappelle une évidence qu'on oublie entre deux crises : on hérite des failles de tout ce sur quoi on construit, et le moteur d'exécution en fait partie, au même titre que la bibliothèque ou le plugin. Dans notre article sur le harness engineering, je défendais l'idée que ce qui entoure un modèle compte autant que le modèle. C'est vrai aussi d'un site : le runtime, le serveur web, le pare-feu et le plan de repli comptent autant que le code. Les organisations qui ont passé mercredi sans paniquer sont celles qui savaient ce qu'elles faisaient tourner, et qui l'avaient déjà mis derrière quelque chose.

Sources

• PHP, Security advisory: Critical remote code execution vulnerabilities, update now, 21 octobre 2026, et annonce préalable, 20 octobre 2026.
• PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security, 21 octobre 2026.
• OpenAI, Patch the Planet: global response coordination as agents uncover critical vulnerabilities, 21 octobre 2026.
• Dépôt PHP d'Ondřej Surý, packages.sury.org/php, journaux de modifications des paquets php5.6 à php8.1 pour Debian 12, consultés le 21 octobre 2026.
• SchizoDuckie, publication sur X, 21 octobre 2026.
• Debian, suivi de sécurité de CVE-2026-109618, consulté le 21 octobre 2026.
• CERT-FR, Multiples vulnérabilités dans PHP (CERTFR-2026-ALE-014), 21 octobre 2026.
• CERT-EU, Critical Vulnerabilities in PHP, 20-21 octobre 2026.
• NCSC (Royaume-Uni), Critical security issue affecting PHP, 21 octobre 2026.
• Dane Knecht, publication sur X, 21 octobre 2026, 9 h 43 (heure de Paris), et réponse, 8 h 30.
• Cloudflare, Cloudflare deploys protections against php2shell vulnerability, 21 octobre 2026.
• W3Techs, Usage statistics of PHP for websites, consulté le 21 octobre 2026.
• BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws, 21 octobre 2026.
• Help Net Security, PHP2Shell: Critical PHP vulnerabilities patched, update now!, 21 octobre 2026.
• Next, Failles critiques PHP : les correctifs sont en ligne, 21 octobre 2026.
• DutchNews, Government websites taken offline over hacking vulnerabilities, 21 octobre 2026.
• Yle, Finland temporarily shuts down government websites, 21 octobre 2026.
• Reuters via Devdiscourse, French prefecture websites taken offline temporarily, 21 octobre 2026.
• CNA (Reuters), Government websites go dark, 21 octobre 2026.
• GovCMS, page de statut, 21 octobre 2026.
• Numerama, Faille PHP : fausse alerte pour les abonnés Freebox, 21 octobre 2026, mis à jour à 12 h 30.
• Mattias Geniar, PHP CVE-2026-109618 and CVE-2026-109619: early mitigation steps, 21 octobre 2026.