Faille PHP CVE-2026-109618 et CVE-2026-109619 : exécution de code à distance, que faire ?

Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques, notées 9.2 sur 10 (CVSS v4.0). Elles permettent à un attaquant non authentifié d'exécuter du code sur le serveur avec une simple requête HTTP, avant même que votre application ne démarre. Si votre serveur fait tourner un site PHP (WordPress, Laravel, Symfony, PrestaShop, un CMS maison…), il est concerné.

En résumé : mettez PHP à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou plus récent), puis redémarrez tous les processus PHP.

Ce que font ces deux failles

CVE-2026-109618 : corruption lors d'un manque de mémoire

Quand PHP atteint sa limite de mémoire au moment où il prépare une requête, il peut s'arrêter alors que certaines données internes ne sont qu'à moitié initialisées. Le nettoyage de fin de requête traite ensuite ces données comme valides. Un attaquant qui provoque volontairement ce manque de mémoire, par exemple avec une requête POST volumineuse, peut détourner ce mécanisme pour exécuter du code.

CVE-2026-109619 : un état interne qui survit d'une requête à l'autre

Un processus PHP traite de nombreuses requêtes à la suite. Certaines données liées à une requête peuvent rester en mémoire après avoir été libérées, et être réutilisées par la requête suivante sur le même processus avant d'être réinitialisées. Là encore, un attaquant peut en tirer une exécution de code.

Qui est exposé ?

D'après l'avis officiel de PHP, toutes les installations qui servent des requêtes web sont concernées :

• PHP-FPM derrière Nginx ou Apache ;
• Apache avec mod_php, le cas le plus exposé (une attaque sans authentification a été démontrée) ;
• php-cgi, FrankenPHP, LiteSpeed.

Aucun compte, aucun plugin vulnérable, aucune erreur dans votre code n'est nécessaire : il suffit que le serveur soit joignable.

Versions corrigées

Si vous êtes encore en PHP 8.1 ou plus ancien, c'est le moment de migrer : ces branches ne reçoivent plus de versions officielles.

Vérifier votre serveur

Version de PHP utilisée en ligne de commande :

php -v

Attention : le site web peut utiliser une autre version que la ligne de commande. Listez les versions installées et les services PHP-FPM actifs :

ls /etc/php/ 2>/dev/null
systemctl list-units --type=service | grep -i php

Sur Debian ou Ubuntu, regardez si une mise à jour est disponible :

sudo apt-get update && apt list --upgradable 2>/dev/null | grep -i php

Les distributions corrigent souvent sans changer le numéro de version principal (rétroportage). Dans ce cas, vérifiez le journal des modifications du paquet :

apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"

Sur Red Hat, AlmaLinux ou Rocky Linux :

rpm -q --changelog php-cli | grep -E "CVE-2026-10961[89]"

Corriger

1. Mettez à jour les paquets PHP (sudo apt-get upgrade ou sudo dnf upgrade), ou recompilez avec la version corrigée.
2. Redémarrez tous les processus PHP : sudo systemctl restart php8.3-fpm (adaptez la version) et, avec mod_php, sudo systemctl restart apache2. Sans redémarrage, l'ancien code reste en mémoire.
3. Vérifiez de nouveau la version servie, par exemple avec une page phpinfo() temporaire que vous supprimez aussitôt.

Si vous ne pouvez pas mettre à jour tout de suite

L'équipe PHP propose des réglages qui réduisent le risque sans le supprimer. La mise à jour reste la seule solution complète.

• Contre CVE-2026-109619 : désactivez la progression d'envoi de fichiers dans php.ini ou dans la configuration du pool FPM (pas avec ini_set() ni .user.ini), puis redémarrez :

session.upload_progress.enabled = 0

• Sur PHP 8.5 uniquement : ajoutez aussi fatal_error_backtraces = 0.
• Contre CVE-2026-109618 : réduisez la taille maximale des requêtes, par exemple post_max_size = 8M si vous n'avez pas d'envoi de fichiers (32M sinon), avec upload_max_filesize en dessous, et limitez la taille des requêtes au niveau de Nginx (client_max_body_size).

Le 23 octobre, PHP a aussi recommandé de garder session.upload_progress.enabled = 0 jusqu'à la prochaine version, même après la mise à jour, pour fermer une variante rare (CVE-2026-115560).

Pourquoi agir vite

Une faille d'exécution de code sans authentification, présente sur des millions de serveurs, est rapidement recherchée par des robots qui scannent Internet. Les serveurs non corrigés risquent l'installation d'une porte dérobée (webshell), d'un mineur de cryptomonnaie ou le vol de la base de données. Si votre serveur est resté exposé plusieurs jours, vérifiez aussi les signes d'intrusion : voir notre guide Serveur Linux piraté : les signes.

Comment FounderMode vous aide

L'agent FounderMode inventorie les logiciels installés sur vos serveurs et les compare chaque jour aux bases publiques de vulnérabilités. Vous recevez dans votre rapport quotidien la liste des versions vulnérables à corriger en priorité, et l'antivirus recherche les webshells et mineurs déposés après une attaque.

Questions fréquentes

Mon hébergement mutualisé est-il concerné ?

Oui si vos sites tournent en PHP. C'est à l'hébergeur d'appliquer le correctif : vérifiez son statut ou ouvrez un ticket.

Faut-il mettre à jour WordPress ou Laravel ?

Non, la faille est dans PHP lui-même, pas dans l'application. Il faut mettre à jour PHP et redémarrer ses processus.

Les réglages temporaires suffisent-ils ?

Non. Ils réduisent les chemins d'attaque connus. Seule la version corrigée protège complètement.

Sources : annonce de sécurité PHP du 21 octobre 2026, avis complémentaire du 23 octobre 2026, avis de CloudLinux.