Cybersecurite 26 Oct 2026 · 1 min de lecture

PHP2Shell : pourquoi vos serveurs PHP sont en première ligne

Equipe Redaction

Expert INNOSYS

Le 21 octobre 2026, l'équipe PHP a publié en urgence des correctifs pour deux failles critiques baptisées « PHP2Shell ». Elles touchent le moteur PHP lui-même, et pas une application en particulier : un site correctement développé reste exposé si l'interpréteur qui le fait tourner n'est pas à jour. Pour toute organisation qui exploite un site vitrine, un extranet, une boutique en ligne ou une application métier en PHP, c'est le dossier prioritaire de la semaine.

Ce qui s'est passé

Deux failles dans le cœur du langage

Les deux vulnérabilités portent les identifiants CVE-2026-109618 et CVE-2026-109619. Elles sont notées 9,2 sur l'échelle CVSS v4.0 ; un score erroné de 10,0 a circulé au moment de la fuite, mais la PHP Foundation a confirmé la note de 9,2.

Selon la PHP Foundation :

CVE-2026-109618 : une requête qui atteint la limite mémoire « au mauvais moment » peut corrompre la mémoire et ouvrir la voie à une exécution de code à distance. Sur Apache avec mod_php, une requête non authentifiée suffit à la déclencher, et l'exécution de code a été démontrée avec les paramètres par défaut. Elle a également été confirmée sur PHP-FPM via certains chemins applicatifs.
CVE-2026-109619 : une erreur fatale peut laisser un pointeur vers une zone mémoire libérée (use-after-free), ce qui a permis une exécution de code démontrée sur une application réelle sous Apache mod_php.

Une divulgation chaotique

Le calendrier a été bousculé. Le 20 octobre, les identifiants CVE ont fuité accompagnés d'informations erronées, et une vidéo de preuve de concept a été publiée par erreur par l'équipe de chercheurs Calif, ce qui, selon la PHP Foundation, a accéléré le développement d'exploits. Le 21 octobre, l'éditeur d'images de conteneurs Chainguard a publié des images corrigées plus de six heures avant l'horaire coordonné, ce que la fondation qualifie de rupture d'embargo.

La PHP Foundation reconnaît elle-même que le délai de traitement relève d'un « structural failure », lié à son processus de décision et à un manque de ressources, et annonce un renforcement de son organisation sécurité (équipe dédiée, nouveaux profils, audits en cours).

Autre fait marquant rapporté par la synthèse technique publiée par SFEIR : les failles ont été identifiées par plusieurs équipes, dont Calif et Wiz Research, en s'appuyant notamment sur des modèles d'IA. La recherche de vulnérabilités assistée par IA n'est plus un sujet prospectif ; elle raccourcit le temps entre la présence d'un défaut et sa découverte, par les défenseurs comme par les attaquants.

La réponse des autorités

Le CERT-FR a publié l'alerte CERTFR-2026-ALE-014 le 21 octobre, mise à jour le 22. Il indique avoir connaissance de preuves de concept pour certains déploiements de PHP et recommande d'isoler les équipements affectés, puis de migrer vers une version maintenue intégrant les derniers correctifs.

Selon le site donneespersonnelles.fr, le CERT-EU a conseillé de déconnecter rapidement les sites impossibles à corriger, et plusieurs administrations européennes, dont des préfectures françaises, ont débranché leurs sites le 21 octobre. Le Journal du Geek rapporte de son côté que des tentatives d'attaque ont été observées dès la publication et que l'agence américaine CISA a appelé à une mise à jour immédiate.

Qui est concerné ?

Les versions touchées

D'après le CERT-FR, sont affectées :

toutes les versions 5.x, 7.x, 8.0.x et 8.1.x, qui ne sont plus supportées ;
les versions 8.2.x antérieures à 8.2.35, 8.3.x antérieures à 8.3.36, 8.4.x antérieures à 8.4.27 et 8.5.x antérieures à 8.5.12.

Les versions corrigées sont donc 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les branches 8.1 et antérieures ne reçoivent pas de correctif officiel ; l'équipe PHP a seulement publié des rétroportages minimaux en sources pour les branches 7.4 à 8.1, selon OCI et SFEIR.

Les configurations les plus exposées

La synthèse de SFEIR, qui compile les avis de la PHP Foundation, de Calif, de Wiz et de Sansec, dresse un tableau nuancé :

Apache avec mod_php : c'est le cas le plus solidement démontré pour les deux failles ;
PHP-FPM (typiquement derrière Nginx) : exploitation validée pour CVE-2026-109619, dépendante de l'application ; pour CVE-2026-109618, la PHP Foundation évoque une exécution confirmée par des chemins applicatifs ;
FrankenPHP, LiteSpeed : jugés probablement vulnérables, sans validation complète au moment de la synthèse.

Toujours selon cette synthèse, Sansec rapporte des exécutions de code non authentifiées sur plusieurs applications courantes (dont WordPress, Drupal, Joomla, Magento, Laravel ou Symfony). Autrement dit : la plupart des CMS et frameworks du marché sont concernés par ricochet.

Le vrai sujet : la dette de versions

Notre lecture d'ESN de terrain est simple : la faille est dans le moteur, mais le risque est dans l'inventaire. Les organisations qui savent en dix minutes où tourne PHP, dans quelle version et qui en est responsable, auront corrigé dans la journée. Celles qui découvrent un serveur 7.4 oublié derrière un extranet partenaire, ou une application métier figée sur PHP 8.0 parce que « personne n'ose y toucher », se retrouvent face à un choix inconfortable : migrer dans l'urgence ou isoler.

Ce n'est d'ailleurs pas un épisode isolé. Le même 21 octobre, Node.js a publié des correctifs pour dix failles sur ses branches maintenues (22.23.4, 24.22.1 et 26.12.1), dont une, CVE-2026-111497, dans le décodeur Brotli, pouvant selon le projet permettre l'exécution de code ; Node.js 20 et les versions antérieures ne sont plus corrigées. Et le 23 octobre, PHP a signalé une nouvelle faille, CVE-2026-115560, limitée à des configurations peu courantes et corrigée dans la prochaine version régulière, selon le Journal du Geek.

Les conséquences concrètes pour votre organisation

Pour un site web ou un extranet exposé sur Internet, le risque est une prise de contrôle du serveur : vol de données (clients, comptes, fichiers), dépôt de code malveillant, rebond vers le système d'information interne si le cloisonnement est faible.

Pour une application métier hébergée chez un prestataire ou un infogéreur, la question n'est pas « est-ce que je suis concerné ? » mais « mon prestataire a-t-il corrigé, et peut-il le prouver ? ». La responsabilité vis-à-vis de vos clients et de vos données reste la vôtre.

Pour les environnements conteneurisés, mettre à jour le paquet ne suffit pas : il faut reconstruire les images et redéployer. Et sur un serveur classique, la PHP Foundation et les synthèses techniques insistent sur un point souvent oublié : redémarrer tous les workers PHP après la mise à jour, faute de quoi les anciens processus continuent de servir les requêtes.

Ce qu'il faut faire maintenant

Inventorier en urgence. Listez chaque serveur, conteneur et hébergement mutualisé qui exécute PHP, avec sa version exacte et son mode d'exécution (mod_php, PHP-FPM, autre). N'oubliez pas les sites satellites : sites événementiels, anciens portails, outils internes exposés.
Mettre à jour et redémarrer. Passez en 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou la version corrigée fournie par votre distribution), puis redémarrez l'ensemble des workers. Pour les conteneurs, reconstruisez les images.
Isoler ce qui ne peut pas être corrigé. Pour les versions 8.1 et antérieures, suivez la recommandation du CERT-FR : isolement des équipements, puis plan de migration vers une version maintenue. Les contournements proposés (désactivation de session.upload_progress.enabled, blocage ou supervision des requêtes multipart sur un WAF) ne sont pas qualifiés par le CERT-FR et ne couvrent que partiellement le risque.
Exiger une preuve de vos prestataires. Demandez à votre hébergeur, infogéreur ou agence web une confirmation écrite de la version déployée et de la date de correction, pour chaque site et application.
Surveiller et préparer la suite. Vérifiez les journaux depuis le 20 octobre à la recherche d'activité anormale, et inscrivez la montée de version PHP (et Node.js) dans un processus récurrent plutôt que dans une gestion de crise.

En conclusion

PHP2Shell rappelle une évidence que les urgences du quotidien font oublier : la sécurité d'un site ne se joue pas seulement dans son code, mais dans le socle sur lequel il tourne et dans la capacité à le maintenir à jour. Les organisations qui disposent d'un inventaire fiable et d'un processus de correctifs rodé traversent ce type d'alerte en quelques heures ; les autres découvrent leur dette technique au pire moment.

Chez Innosys, nous accompagnons depuis 2005 des PME et ETI sur l'administration de leurs systèmes, le développement et la maintenance de leurs applications et leur cybersécurité. Si vous avez un doute sur l'exposition de vos environnements PHP, ou si une migration de version vous paraît hors de portée, parlons-en.