# PHP2Shell : deux failles critiques dans le moteur PHP. Source : https://libwatch.com/cve/php2shell Alerte critique · Moteur PHP - CVSS 9,2 - RCE sans authentification - Corrigé le 21/10/2026 CVE-2026-109618 et CVE-2026-109619 permettent d'exécuter du code à distance, sans authentification, sur tout serveur qui sert des pages en PHP. Voici comment savoir en deux minutes si vous êtes concerné, et comment corriger. [Vérifier mes projets](https://app.libwatch.com/users/sign_up?source=cve_php2shell) [Voir les commandes](#verifier) Mis à jour le 22 octobre 2026 à 10 h 30 · Sources : php.net, CERT-FR, CISA ## Fiche d'état Au 22/10/2026 · 10 h 30 CVE CVE-2026-109618 CVE-2026-109619 Gravité CVSS v4.0 9,2 · critique Impact Exécution de code à distance, sans authentification Concerne PHP-FPM, mod\_php, php-cgi, FrankenPHP, LiteSpeed Corrigé dans 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 Exploitation Tentative observée dès le 17/10 Alertes CERTFR-2026-ALE-014 · CISA ## L'essentiel en 60 secondes ### Le moteur est touché, pas votre code. Les deux failles sont dans l'interpréteur PHP lui-même. Tout serveur qui traite des requêtes web avec une version non corrigée est exposé. ### Mettre à jour votre CMS ne suffit pas. WordPress, Symfony, Laravel ou vos paquets Composer à jour ne changent rien : c'est le binaire PHP du serveur qu'il faut remplacer. ### Une seule action corrige vraiment. Passer à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, puis redémarrer les processus PHP. Les contournements ne bloquent qu'une partie des attaques. Ce qui se passe ## Deux failles mémoire au cœur de l'interpréteur Elles se déclenchent pendant le traitement d'une requête HTTP, avant même que votre application ne s'exécute. CVE-2026-109618 · CVSS 9,2 ### Corruption mémoire en cas de manque de mémoire Quand une allocation échoue pendant l'analyse d'une requête, PHP interrompt le traitement et laisse des structures à moitié initialisées. Le nettoyage de fin de requête les réutilise : un attaquant peut en prendre le contrôle avec une requête forgée. Apache avec mod\_php est la configuration la plus exposée. CVE-2026-109619 · CVSS 9,2 ### Mémoire libérée puis réutilisée entre deux requêtes Un même processus PHP traite plusieurs requêtes à la suite. Après une erreur fatale, un état interne pointe encore vers de la mémoire libérée, que la requête suivante relit. Le suivi de progression des envois de fichiers (session.upload\_progress, actif par défaut) en est le chemin d'attaque connu. Touche PHP-FPM, mod\_php, FrankenPHP et LiteSpeed. Qui est concerné ## Votre branche de PHP, et ce qu'il faut faire Le support de chaque branche vient du calendrier officiel de php.net. Une branche en fin de support ne reçoit plus de version corrigée. | Branche | Vulnérable | Corrigé dans | Support officiel | À faire | | --- | --- | --- | --- | --- | | 8.5 | 8.5.0 à 8.5.11 | 8.5.12 | Actif · sécurité → 2029 | Mettre à jour vers 8.5.12 | | 8.4 | 8.4.0 à 8.4.26 | 8.4.27 | Actif · sécurité → 2028 | Mettre à jour vers 8.4.27 | | 8.3 | 8.3.0 à 8.3.35 | 8.3.36 | Sécurité seule → 2027 | Mettre à jour vers 8.3.36 | | 8.2 | 8.2.0 à 8.2.34 | 8.2.35 | Fin le 31/12/2026 | Corriger aujourd'hui, migrer avant le 31/12 | | 8.1 et avant | Toutes | aucune | Fin depuis le 31/12/2025 | Paquet corrigé de votre distribution, ou migrer vers 8.3+ | PHP 8.2 sort du support dans dix semaines Corrigez en 8.2.35 aujourd'hui, puis planifiez la migration vers 8.3 ou 8.4. Après le 31 décembre 2026, une nouvelle faille du moteur laissera les serveurs 8.2 sans correctif, comme 8.1 aujourd'hui. Vérifier en 2 minutes ## Regardez à deux endroits : le dépôt et le serveur Le dépôt dit quelle version de PHP le projet attend. Le serveur dit laquelle tourne vraiment. Les deux comptent. ### Dans vos dépôts : composer.json et composer.lock Dans le dépôt · version déclarée ``` $ grep -E '"php"' composer.json "php": "^8.1" $ composer show --platform | grep -E "^php " php 8.1.29 The PHP interpreter ``` Ce que ça veut dire ``` "php": "^8.1" → le projet accepte 8.1 : branche en fin de support "php": "^8.2" → corriger en 8.2.35, migrer avant le 31/12/2026 "php": "^8.3" → corriger en 8.3.36 ou plus ``` ### Sur vos serveurs : php -v, PHP-FPM, Apache, Docker Sur le serveur ``` $ php -v $ ps aux | grep -E 'php-fpm|lsphp' ``` ### Sur un site WordPress : Outils › Santé du site Sur WordPress ``` Outils › Santé du site › Informations › Serveur ``` Ce que LibWatch fait pour vous ## Tous vos projets PHP vérifiés d'un coup, et surveillés chaque nuit. - Repère la version de PHP déclarée par chaque dépôt et par chaque site WordPress, et la croise avec les failles et la fin de support. - Intègre les alertes du CERT-FR sur PHP : une version exacte de PHP touchée (8.2.30, pas ^8.2) est signalée au plus tard la nuit suivante. - Revérifie tout chaque nuit, même les projets auxquels personne ne touche, et prévient l'équipe par e-mail, Slack, Zulip ou webhook. Sa limite : LibWatch voit la version déclarée dans le dépôt, pas forcément celle installée sur vos serveurs. Vérifiez aussi php -v en production. [Vérifier mes projets](https://app.libwatch.com/users/sign_up?source=cve_php2shell) [Ou testez un composer.lock sans compte →](/outils/verifier-composer) Votre code reste chez vous : LibWatch lit vos fichiers de dépendances et ne garde que la liste de vos paquets et de leurs versions. [Comment ça marche →](/securite) Corriger ## Trois étapes, la deuxième est celle qu'on oublie Seule la mise à jour de PHP corrige les deux failles. Gardez vos journaux d'accès et d'erreurs : des tentatives d'exploitation ont été vues dès le 17 octobre. ### Mettre à jour PHP, ou reconstruire vos images Docker Mettre à jour l'hôte ne corrige pas le PHP qui tourne dans un conteneur : reconstruisez l'image depuis une base corrigée. Sur Debian / Ubuntu ``` $ sudo apt update && sudo apt install --only-upgrade 'php*' # Docker : repartir d'une image de base corrigée $ docker build --pull --no-cache -t mon-app:corrigee . ``` ### Redémarrer tous les processus PHP Sans redémarrage, l'ancienne version vulnérable reste chargée en mémoire, même si le paquet est à jour sur le disque. Redémarrer et contrôler ``` $ sudo systemctl restart php8.3-fpm $ sudo systemctl restart apache2 # la date de démarrage doit suivre la mise à jour $ ps -eo pid,lstart,cmd | grep -E 'php-fpm|apache2' ``` ### Contrôler la version servie Vérifiez la version vue par une vraie requête web, pas seulement par la ligne de commande : les deux peuvent différer. Contournements temporaires ## Si vous ne pouvez pas corriger dans l'heure Bloque ### Désactiver le suivi des envois - — Les chemins d'attaque connus de CVE-2026-109619. - — Les envois de fichiers continuent de fonctionner normalement. - — Effet seulement après redémarrage des processus PHP. php.ini ``` session.upload_progress.enabled = Off ``` Ne bloque pas ### Ce que ça laisse ouvert - — CVE-2026-109618, la corruption mémoire en cas de manque de mémoire. - — Les autres chemins possibles vers la seconde faille. - — Les règles WAF (Cloudflare, AWS, Azure…) réduisent le risque mais ne remplacent pas la mise à jour. Seule la mise à jour de PHP corrige Les éditeurs de PHP, le CERT-FR et la CISA le disent tous : un contournement achète du temps, rien de plus. Chronologie ## Cinq jours, de la première attaque à cette page 17/10/2026 ### Première tentative d'exploitation Observée par Amazon Threat Intelligence, quatre jours avant le correctif. 20/10/2026 ### Fuite et annonce anticipée Un message supprimé annonce un CVSS de 10, démenti ensuite : le score officiel est 9,2. 21/10/2026 ### Correctifs et alertes PHP publie 8.5.12, 8.4.27, 8.3.36 et 8.2.35. CERT-FR (ALE-014) et CISA alertent. Cloudflare déploie des règles WAF. 22/10/2026 ### Cette page Mise à jour à chaque fait nouveau : ajout au catalogue KEV, score EPSS, paquets des distributions. Questions fréquentes ## Ce qu'on nous demande depuis le 21 octobre [Une autre question ? Écrivez-nous →](mailto:bonjour@isee-u.fr) ### Mettre à jour WordPress, Symfony ou Laravel suffit-il ? Non. La faille est dans le moteur PHP du serveur, pas dans votre CMS ni vos paquets Composer. Tant que PHP n'est pas en 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 et que ses processus n'ont pas redémarré, le site reste exposé. ### Je suis sur un hébergement mutualisé ou WordPress managé : que faire ? C'est votre hébergeur qui met PHP à jour. Vérifiez la version servie dans Outils › Santé du site › Informations › Serveur : si elle est antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, demandez la mise à jour à votre hébergeur, ou choisissez une version corrigée dans votre espace client s'il le permet. ### Pourquoi un score de 9,2 et pas 10 comme annoncé au début ? Le 20/10/2026, un message supprimé depuis annonçait un CVSS de 10. Il a été démenti ensuite : le score officiel est 9,2 (CVSS v4.0), pour chacune des deux failles. ### Comment savoir si mon serveur a été attaqué avant la mise à jour ? Gardez vos journaux d'accès et d'erreurs : des tentatives d'exploitation ont été vues dès le 17 octobre, quatre jours avant le correctif. La mise à jour ferme les failles mais n'efface pas une intrusion antérieure : en cas de doute, faites analyser ces journaux. ### LibWatch a-t-il besoin d'accéder à mon code pour détecter la faille ? Non. LibWatch lit vos fichiers de dépendances et ne garde que la liste de vos paquets et de leurs versions. Sa limite : LibWatch voit la version déclarée dans le dépôt, pas forcément celle installée sur vos serveurs. Vérifiez aussi php -v en production. ## Sources Vérifiées le 22/10/2026. Nous corrigeons cette page dès qu'une source évolue. - [php.net · Annonce de sécurité](https://www.php.net/archive/2026.php#2026-10-20-1) - [CERT-FR · CERTFR-2026-ALE-014](https://www.cert.ssi.gouv.fr/alerte/CERTFR-2026-ALE-014/) - [CISA · Alerte du 21/10/2026](https://www.cisa.gov/news-events/cybersecurity-advisories) - [Rapid7 · Analyse technique](https://www.rapid7.com/blog/) - [Google Cloud · Réponse aux CVE](https://cloud.google.com/support/bulletins) - [Cisco · Avis de sécurité](https://sec.cloudapps.cisco.com/security/center/publicationListing.x)