php2shell : ce que retient la PHP Foundation, et comment tester vos sites

Le 21 octobre 2026, la Fondation PHP a publié un article revenant sur les deux failles critiques corrigées le jour même, que nous vous présentions dans notre premier article.

Baptisées php2shell par Calif, l'équipe à l'origine du signalement, ces failles permettent sous certaines conditions d'exécuter du code à distance sans authentification sur un serveur.

L'article de la Fondation PHP ne traite pas directement de la mise à jour mais de la façon dont ces failles ont été trouvées et corrigées.

Nous vous en présentons les grandes lignes avant de voir comment vérifier vos sites avec le scanner publié par Assetnote.

Deux failles au coeur du moteur

La première, CVE-2026-109618, arrive quand une requête atteint le memory_limit au mauvais moment : PHP peut laisser des données internes à moitié initialisées puis les traiter comme valides dans un second temps.

La seconde, CVE-2026-109619, laisse un état interne pointer vers la mémoire d'une requête précédente, qu'une requête suivante du même worker peut réutiliser.

Le risque est maximal avec Apache et mod_php où l'attaque peut se déclencher avant même l'exécution du code applicatif. Calif indique avoir confirmé une exécution de code sans authentification sur une dizaine d'applications, dont Laravel 13.11.

La piste du session.upload_progress, que nous évoquions dans notre premier article, se confirme en partie : php.net recommande de désactiver cette directive contre la seconde faille, mais la mesure ne bloque que les chemins d'exploitation connus.

Un problème identifié en 2024

En 2024, Quarkslab mène le premier audit de sécurité externe de PHP depuis des années. En corrigeant l'une des failles remontées, un développeur du coeur de PHP rémunéré par la fondation repère les premiers signes du problème de mémoire derrière CVE-2026-109618.

Plusieurs correctifs sont envisagés chacun avec son coût : rupture de compatibilité, nouveau risque de DDOS, modifications à coordonner dans de nombreuses extensions tierces ...

Faute de consensus, sans exploitation connue et avec une poignée de développeurs capables d'intervenir sur le moteur, le travail s'arrete et redémarre pendant des mois.

La fondation parle elle même d'un échec structurel lié autant à son processus de décision qu'à un manque de moyens.

Le 11 août 2026, Calif et OpenAI signalent indépendamment une exécution de code à distance ayant la même cause racine.

La correction devient alors la priorité de toute l'équipe sécurité, qui a depuis commencé à revoir son fonctionnement pour pouvoir trancher à la majorité ces situations problématiques.

L’IA dans la recherche de failles

La Fondation PHP constate également un changement d'échelle de ces vulnérabilités lié à l'émergence des IA.

Plus tôt dans l’année, la fondation a pu faire analyser le code source de PHP par Claude Mythos grâce à Alpha-Omega, un projet de l’OpenSSF qui finance la sécurisation de projets open source critiques.

Anthropic réserve ce modèle à un nombre restreint d’organisations : ses capacités à trouver et exploiter des failles étant jugées trop dangereuses pour une diffusion publique.

La fondation a ensuite ajouté d’autres outils à ses analyses dont Daybreak Red d’OpenAI. Le programme est uniquement accessible sur candidature et donne accès à des modèles entraînés pour la recherche de vulnérabilités et la validation d'exploits, comme GPT-5.6-Cyber.

La fondation s'en sert pour vérifier qu'un rapport et l'exploit qui l'accompagne sont pertinents en complément de builds pour chaque plateforme supportée par PHP.

Ce tri est devenu indispensable : depuis le 1er juillet, l'équipe a publié quinze CVE et traité plus de cent rapports invalides, dupliqués ou non reproductibles.

L'IA aide également à valider les signalements et à regrouper ceux qui partagent une même cause racine, mais chaque décision et chaque correctif restent entre les mains d'un développeur.

Côté Calif, le chercheur explique avoir orienté son modèle à partir de failles de PHP vieilles de vingt ans qu'un LLM ne va pas chercher spontanément.

Le debut de l'emballement

La divulgation coordonnée a tenu jusqu'au 20 octobre vers 17h, heure de Paris, quand les deux identifiants de CVE ont fuité avec un score CVS erroné de 10 au lieu de 9,2.

Le projet PHP a avancé la sortie d'un jour, au 21 octobre à 16h, pour laisser aux distributions le temps de finaliser leurs paquets.

Dans la foulée, Calif a publié par erreur une vidéo de sa preuve de concept dont les copies ont accéléré l'apparition de POC.

Comme les autres distributeurs, Chainguard, qui fournit des images de conteneurs prêtes à l'emploi avait reçu le correctif en avance pour que ses utilisateurs puissent mettre à jour dès l'annonce.

Le lendemain à 9h41, l'entreprise a pourtant rompu l'embargo en publiant ses images corrigées : n'importe quel attaquant pouvait alors étudier le correctif plus de six heures avant sa sortie officielle.

Vérifier ses sites avec php2shell-scanner

Maintenant que nous en savons plus sur l'origine de la faille et son traitement par la Fondation PHP, intéressons-nous au package de Assetnote permettant de vérifier si l'un de vos sites est toujours vulnérable à ces deux CVE.

Le repository php2shell-scanner contient un script Python en ligne de commande permettant de détecter les failles sur une application web :

1git clone https://github.com/assetnote/php2shell-scanner.git
2cd php2shell-scanner
3pip install -r requirements.txt

Une fois installé, vous pouvez lancer le script sur un site donné :

1python3 scanner.py -u https://staging.mon-site.fr

Ou alors sur une liste de sites :

1python3 scanner.py -l sites.txt -o resultats.json

Le scanner envoie une requête de contrôle puis jusqu'à trois requêtes multipart de plus en plus lourdes par défaut vers /index.php.

Il considère un site comme vulnérable s'il obtient une erreur de mémoire, un crash de worker PHP-FPM ou une version de PHP annoncée non corrigée.

Chaque url testé peut recevoir près de 29 Mio de requêtes : ne le lancez que sur vos propres sites, de préférence sur des environnements de pre-production car il peut faire tomber des workers sur un serveur non corrigé

Conclusion

Pour conclure, aucune mesure temporaire ne remplace la mise à jour, pour rappel les versions corrigés de PHP sont : 8.2.35, 8.3.36, 8.4.27, 8.5.12.

PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles, certaines distributions Linux et certains fournisseurs de support étendu proposent des correctifs et l’équipe sécurité de PHP a exceptionnellement publié des correctifs minimaux pour PHP 7.4, 8.0 et 8.1, à compiler soi-même.

La seule solution durable reste cependant de migrer vers une version supportée.

Pour finir, l'article de la Fondation PHP rappelle que la sécurité de PHP repose sur une poignée de développeurs financés par les sponsors de la fondation.

Si votre activité dépend du langage, la soutenir reste selon elle le moyen le plus direct d'éviter que le prochain problème structurel ne tourne à l'urgence.

« Sponsoring the PHP Foundation is the most direct way to ensure structural issues like the OOM vulnerability are addressed sustainably, before they turn into emergencies »
— The PHP Foundation Pour soutenir la fondation : thephp.foundation/sponsor, ou contactez-la pour un engagement plus important.

Écrit par

Mathieu De Gracia

Lead & Software Architect • nublar.dev