Le 21 octobre 2026, l’équipe PHP a publié des mises à jour de sécurité urgentes pour corriger deux vulnérabilités du moteur PHP : CVE-2026-109618 et CVE-2026-109619, parfois désignées ensemble sous le nom PHP2Shell.

Selon le projet PHP, ces failles peuvent permettre une exécution de code à distance sans authentification. Elles touchent PHP lui-même : un site peut donc être exposé même si son CMS, ses extensions et son code applicatif sont à jour.

La mise à jour est la seule correction complète. Les réglages de configuration peuvent réduire certains risques, mais ne remplacent pas l’installation d’un correctif.

Deux vulnérabilités, deux mécanismes

Les deux failles concernent la gestion de la mémoire lorsque PHP interrompt anormalement le traitement d’une requête.

CVE-2026-109618 : corruption liée à un épuisement de mémoire (OOM)
Une erreur d’épuisement de mémoire peut interrompre le traitement alors que certaines données internes de la requête ne sont que partiellement initialisées. Le nettoyage de la requête peut ensuite traiter ces données comme si elles étaient valides.
CVE-2026-109619 : état global périmé (stale global state)
Des données internes associées à une requête peuvent subsister après la libération de la mémoire qui les contenait. Une requête ultérieure, traitée par le même processus, peut alors réutiliser cet état avant qu’il soit correctement réinitialisé.

Les deux failles sont jugées critiques et peuvent, selon les circonstances, mener à l’exécution de code à distance. La seconde peut également exposer des données présentes dans la mémoire du processus PHP. L’impact concret dépend notamment du mode de déploiement et de la configuration.

Qui est concerné ?

Il faut vérifier la version de PHP qui exécute réellement les requêtes, et pas seulement la version du CMS ou des applications. Pensez aussi aux environnements conteneurisés, aux images de base, aux machines virtuelles, aux runtimes gérés par un hébergeur et aux logiciels qui embarquent leur propre version de PHP.

Apache avec mod_php

D’après les informations disponibles, le chemin d’attaque lié à CVE-2026-109619 peut être atteint avec mod_php, y compris si l’application n’appelle pas session_start(). Il ne faut donc pas supposer qu’un site est protégé parce qu’il n’utilise pas explicitement les sessions.

PHP-FPM et autres déploiements

Avec PHP-FPM, l’exposition dépend notamment de la configuration du frontal CGI et des valeurs qu’il transmet. Certaines peuvent provoquer un diagnostic avant l’initialisation complète de la requête. Comme il peut être difficile de confirmer l’absence de ce chemin dans une configuration donnée, mieux vaut traiter les installations FPM comme potentiellement concernées jusqu’à vérification.

Le défaut se trouvant dans PHP, un CMS ou une extension à jour ne suffit pas à corriger le problème.

Versions corrigées

Le projet PHP a publié les versions suivantes le 21 octobre :

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs du projet PHP. Certains fournisseurs ou mainteneurs de distributions peuvent toutefois proposer des rétroportages (backports). Vérifiez le statut auprès de votre fournisseur et assurez-vous que le paquet installé contient bien le correctif : le numéro de version affiché peut différer de celui des versions officielles ci-dessus.

Pour les serveurs utilisant une distribution Linux, installez les paquets corrigés fournis par cette distribution. Pour les conteneurs, mettez à jour l’image qui contient PHP, puis reconstruisez et redéployez le conteneur : corriger l’hôte ne met pas automatiquement à jour PHP à l’intérieur de l’image. Si votre version de PHP n’est plus maintenue, envisagez une migration vers une branche prise en charge ou la coupure pure et simple du service.

Que faire maintenant ?

Inventoriez toutes les installations PHP, y compris celles des conteneurs, des images de base et des services hébergés.
Mettez d’abord à jour les services accessibles depuis Internet.
Redémarrez ou redéployez les processus concernés après la mise à jour, afin qu’ils utilisent bien les bibliothèques et exécutables corrigés.
Si vous ne pouvez pas corriger immédiatement, réduisez l’exposition : restreignez l’accès réseau ou mettez temporairement le service hors ligne. Si PHP est géré par votre hébergeur, demandez-lui confirmation du correctif appliqué.

Mesures temporaires : utiles, mais incomplètes

Le projet PHP mentionne notamment des réglages susceptibles de limiter certains scénarios :

1session.upload_progress.enabled=Off

Si PHP est exécuté en utilisant PHP-FPM :

1php_admin_flag[session.upload_progress.enabled] = off

Ce réglage vise le chemin associé à CVE-2026-109619. D’autres mesures citées dans les avis comprennent, selon les versions et les configurations :

1fatal_error_backtraces=0
2memory_limit=-1

Il est aussi possible de réduire post_max_size et max_input_nesting_level en fonction des besoins réels de l’application.

Ces paramètres ont des effets différents et doivent être évalués dans le contexte de chaque service. En particulier, modifier les limites d’envoi peut perturber les fonctionnalités qui acceptent des fichiers. Aucune de ces mesures ne constitue une correction complète : installez dès que possible la mise à jour de PHP.

Journaux et préparation à une analyse post-mortem

Les recommandations de surveillance ne permettent pas forcément d’identifier simplement toutes les tentatives. Il reste utile de conserver des journaux PHP suffisamment détaillés pour faciliter une analyse après incident :

1log_errors=On
2error_log=/chemin/adapté/php-error.log
3error_reporting=E_ALL

Vérifiez que le chemin choisi est bien accessible au processus PHP, que les journaux sont conservés et qu’ils ne sont pas exposés publiquement. La journalisation aide à l’investigation, mais n'empêche pas l’exploitation.

Une exploitation dans la nature déjà observée

Plusieurs exploits ont déjà été publiés et les références se multiplient.

En cas d'utilisation d'un tel exploit à la recherche de déploiements vulnérables dans votre système d'information, il convient généralement d'auditer le code afin de vérifier que celui-ci ne contient pas de code réellement malveillant.

Par ailleurs, des acteurs isolés exploitent ces vulnérabilités depuis le 17 octobre. Il convient donc de réaliser une analyse post-mortem sur les environnements sensibles.

Les vulnérabilités sont déjà exploitées, l'exploitation étant automatisable à large échelle.

Des indicateurs de compromission sont partagés par des acteurs tels que Amazon. Il ne faut toutefois pas s'y limiter pour la détection.

Le problème de l'obsolescence

L'un des facteurs rendant ce couple de vulnérabilités si impactant est le problème de l'obsolescence très spécifique à PHP.

En effet, les différentes versions majeures de PHP induisent des changements qui cassent la compatibilité du langage avec certaines fonctionnalités utilisées par de nombreuses applications.

Il est ainsi encore très courant de trouver en production des versions telles que PHP 5 ou PHP 7 qui ne sont plus maintenues depuis plusieurs années voire une dizaine d'années dans certains cas.

Ces branches étant elles aussi vulnérables, la barrière à la montée en version risque de transformer la correction en un chantier d'adaptation. En ce sens, on peut considérer PHP2Shell similaire à Log4Shell dans la mesure où il faut s'attendre à une installation dans la durée de ce risque.

Conclusion

Identifiez toutes vos installations PHP et appliquez au plus vite les paquets corrigés, en priorité sur les services exposés à Internet. PHP2Shell concerne le moteur d’exécution lui-même : la mise à jour d’un site ou d’un CMS, sans mise à jour de PHP, ne suffit pas.

PHP2Shell : deux failles (vraiment) critiques dans PHP