En bref : CVE-2026-109619 est la seconde faille derrière PHP2Shell. L'état interne lié à une requête peut subsister après la libération de la mémoire ; une requête ultérieure dans le même worker peut l'exploiter avant qu'il ne soit réinitialisé. La conséquence est l'exécution de code sans authentification. Remède : mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 et redémarrage de tous les workers.
Qu'est-ce que CVE-2026-109619 ?
CVE-2026-109619 (identifiant GitHub GHSA-6wmf-4rv5-p3rp) est évaluée à 9.2 selon CVSS v4.0. Avec CVE-2026-109618, elle forme PHP2Shell. Les deux failles se trouvent dans PHP lui-même et non dans une application.
L'effet est le même que pour la faille sœur : un attaquant peut exécuter du code sur le serveur depuis l'extérieur, sans mot de passe ni compte utilisateur. La cause est toutefois différente.
Pourquoi un état périmé dans le worker est dangereux
Un serveur web PHP ne démarre pas un nouveau processus pour chaque requête. Avec PHP-FPM, Apache avec mod_php, LiteSpeed ou FrankenPHP, un worker traite successivement de nombreuses requêtes. Entre deux requêtes, PHP réinitialise son état interne, afin que rien de la requête A ne passe dans la requête B.
Avec CVE-2026-109619, cette réinitialisation ne fonctionne pas complètement. Selon php.net, l'état interne lié à la requête peut subsister après la libération de la mémoire. Une requête ultérieure dans le même worker peut exploiter cet état périmé avant qu'il ne soit réinitialisé. En simplifiant : quelque chose continue d'être utilisé alors qu'il n'est en réalité plus valide.
Du point de vue de l'exploitation, c'est remarquable. La réutilisation des workers est voulue, car elle rend les serveurs web rapides : un worker n'a pas à redémarrer pour chaque requête, charger des extensions et allouer de la mémoire. La faille touche donc une propriété que possède pratiquement toute installation PHP en production. php.net ne cite aucune configuration qui évite complètement le problème ; c'est pourquoi la voie passe par la mise à jour.
Nous ne publions pas de détails sur l'exploitation. Pour les exploitants, ce qui compte : tout mode d'exécution dans lequel des workers servent plusieurs requêtes doit être surveillé, et ce sont précisément les modes habituels.
Les deux failles PHP2Shell en comparaison
| Caractéristique | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Identifiant GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Évaluation | CVSS v4.0 9.2 | CVSS v4.0 9.2 |
| Déclencheur | Mémoire insuffisante pendant l'initialisation des données de la requête | L'état interne subsiste après la libération |
| Effet | Exécution de code sans authentification | Exécution de code sans authentification |
| Corrigée dans | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed sont concernés. L'équipe PHP voit le risque le plus élevé avec mod_php ; pourquoi, nous l'expliquons sous Pourquoi mod_php porte le risque le plus élevé.
Refermer CVE-2026-109619 : mise à jour, puis redémarrage de tous les workers
Pour cette faille en particulier, le redémarrage est décisif. Tant que d'anciens workers tournent en mémoire, le serveur continue de fonctionner avec le code défectueux, même si les nouveaux fichiers sont depuis longtemps sur le disque.
Vérifiez la version et l'état des paquets. Les noms de paquets varient selon la distribution et l'interface de l'hébergeur :
php -v
php-fpm8.3 -v # le binaire FPM peut avoir une autre version que la CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # famille RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Redémarrez ensuite tous les services concernés :
sudo systemctl restart php8.3-fpm # selon la version de PHP installée
sudo systemctl restart apache2 # avec mod_php ; sous RHEL, le service s'appelle httpd
Si votre distribution ou votre hébergeur applique un backport, le numéro de version affiché peut rester identique. Ce sont alors le journal des modifications du paquet et la confirmation écrite du fournisseur qui comptent. Vous trouverez une vérification pas à pas sous Redémarrer PHP-FPM et tous les workers.
Notez la date et l'heure du redémarrage. Pour évaluer ensuite si une attaque a eu lieu avant ou après le correctif, cet instant est le repère le plus important.
Ce qu'il reste à faire après le correctif
Un correctif ne prouve pas que rien ne s'est produit auparavant. Selon des reportages de médias, une première tentative d'attaque a été observée le 17 octobre, quatre jours avant les correctifs. Conservez les journaux du serveur à partir du 20 octobre, comme le recommande la presse spécialisée, et examinez le serveur à la recherche d'anomalies. La page Suis-je déjà compromis ? donne des indications à ce sujet.
Pensez à la portée : en cas d'exécution de code réussie, l'attaquant dispose des droits du processus PHP. Il peut lire ce que l'application a le droit de lire, par exemple des fichiers de configuration avec des accès à la base de données ou des clés d'API. Si un incident se confirme, ces identifiants doivent être renouvelés après le nettoyage.
Comment PHP SOS aide-t-il concrètement ?
Avec le service de correctifs PHP, nous mettons en œuvre la correction de façon traçable :
- Recenser : quelles versions et quels modes d'exécution de PHP tournent sur quel serveur, et quelle source de paquets les fournit ?
- Corriger : mise à jour depuis la bonne source ou mesures transitoires selon php.net, là où la mise à jour est encore bloquée.
- Contrôler le redémarrage : nous vérifions processus par processus que seule la version corrigée tourne encore.
- Documenter : versions, états des paquets et heures de redémarrage, afin que vous puissiez prouver l'état.
Questions fréquentes
Qu'est-ce qui distingue CVE-2026-109619 de CVE-2026-109618 ?
CVE-2026-109618 naît lorsqu'un état de mémoire insuffisante interrompt la requête en pleine initialisation. CVE-2026-109619 concerne un état qui subsiste dans le worker après la fin d'une requête. Les deux mènent à l'exécution de code sans authentification et sont corrigées dans les mêmes versions de PHP.
Redémarrer plus souvent les workers PHP-FPM aide-t-il ?
Ce n'est pas adapté comme substitut à la mise à jour. php.net ne cite pas des redémarrages de workers plus fréquents comme mesure transitoire. Vous devez toutefois redémarrer les workers après la mise à jour, afin que la version corrigée tourne effectivement.
Une mise à jour du CMS me protège-t-elle contre CVE-2026-109619 ?
Non. La faille se trouve dans PHP et non dans WordPress, Shopware, TYPO3 ou un autre système. Seule une mise à jour de PHP ou un backport confirmé par le fournisseur la referme.
Existe-t-il des traces connues d'une attaque via CVE-2026-109619 ?
Aucun indicateur de compromission (IOC) confirmé n'a été publié jusqu'ici. La détection repose sur l'analyse comportementale, par exemple de nouveaux fichiers PHP, des connexions sortantes inhabituelles ou des tâches cron inconnues.