Alerte critique · Moteur PHP

  • CVSS 9,2
  • RCE sans authentification
  • Corrigé le 21/10/2026

PHP2Shell : deux failles critiques dans le moteur PHP.

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 Voir les commandes

Mis à jour le 22 octobre 2026 à 10 h 30 · Sources : php.net, CERT-FR, CISA

Lire avec une IA Version .md

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.

BrancheVulnérableCorrigé dansSupport 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 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 le serveur 
$ php -v
$ ps aux | grep -E 'php-fpm|lsphp'
Sur WordPress 
Outils › Santé du site › Informations › Serveur

Les commandes « Sur vos serveurs » et « WordPress » s'affichent au clic sur l'étape 2 ou 3.

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 Ou testez un composer.lock sans compte →

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 →

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 →
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.