Faille critique PHP du 21 octobre 2026 : ce que nous avons fait pour protéger vos sites

Ce mercredi 21 octobre 2026, l'équipe PHP a publié un correctif de sécurité pour deux vulnérabilités critiques qui concernent la quasi-totalité des sites web écrits en PHP, WordPress compris. Dès ce matin, nous avons protégé nos serveurs, puis appliqué le correctif dès sa publication. Voici ce qui s'est passé, ce que nous avons fait pour les sites de nos clients, et ce que vous pouvez vérifier de votre côté si vous êtes hébergé ailleurs.

Le 20 octobre, php.net a annoncé qu'une mise à jour critique serait publiée le lendemain à 14:00 UTC, soit 16 h heure de Paris, pour corriger deux vulnérabilités notées 9,2 sur l'échelle CVSS v4.0, c'est-à-dire dans la catégorie « critique ».

Le 21 octobre, les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ont été publiées. Elles corrigent les failles CVE-2026-109618 et CVE-2026-109619, qui permettent toutes deux une exécution de code à distance sans authentification. En clair : un attaquant pourrait faire exécuter ses propres instructions sur le serveur, sans compte ni mot de passe, simplement en envoyant une requête construite pour cela.

Pour les curieux, voici en quelques mots de quoi il s'agit :

• CVE-2026-109618 (« RCE via OOM corruption ») : une gestion de mémoire insuffisante peut interrompre PHP alors que des données internes de la requête ne sont que partiellement initialisées. Le nettoyage de fin de requête peut ensuite les traiter comme valides.
• CVE-2026-109619 (« RCE via stale global state ») : un état interne propre à une requête peut survivre après la libération de sa mémoire, et une requête suivante traitée par le même processus peut l'utiliser.

Toutes les installations PHP qui servent des requêtes web sont concernées : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. Un exploit a été démontré sous mod_php, où une requête anonyme déclenche l'attaque avant même que le code du site ne s'exécute. Le chemin confirmé passe par la fonction de suivi de progression des envois de fichiers (session.upload_progress), active par défaut dans PHP et sollicitée lors de l'envoi de formulaires de type multipart, même si le site n'utilise pas les sessions. Autrement dit, un simple formulaire de contact suffit à solliciter la fonction en question.

Point important : PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles. Elles n'ont donc pas de correctif. PHP 8.2 sera quant à lui en fin de vie le 31 décembre 2026.

L'avis officiel est consultable ici : php.net

Les sites de nos clients sont hébergés sur des serveurs dédiés et des VPS sous Plesk, chez OVH. Voici, dans l'ordre, les actions menées.

Avant toute chose, nous avons dressé l'inventaire de tous les projets PHP que nous maintenons, avec pour chacun la version de PHP utilisée en production et la façon dont PHP y est exécuté. On ne protège bien que ce que l'on connaît précisément.

Le correctif n'étant attendu qu'à 16 h, nous n'avons pas attendu. php.net indique que la désactivation de session.upload_progress réduit l'exposition au chemin d'attaque confirmé. Nous l'avons donc désactivée au niveau serveur, pour toutes les versions de PHP installées (12 versions sur un même serveur), puis nous avons rechargé tous les processus PHP-FPM.

Nous ne nous sommes pas contentés de modifier la configuration : un petit script de test a interrogé chaque site pour lire la valeur réellement appliquée. Entre ce qui est écrit dans un fichier et ce que PHP applique vraiment, il peut y avoir un écart, et c'est précisément ce que nous voulions exclure.

php.net est clair sur ce point : ces mitigations réduisent l'exposition mais ne rendent pas un site sûr. Seule la mise à jour est une solution complète. C'était une mesure d'attente, pas une fin en soi.

Puisque PHP 8.1 et antérieures ne recevront jamais de correctif, nous avons fait en sorte que plus aucun site ne soit servi par une version en fin de vie. Les quelques sites concernés ont été migrés vers une version maintenue ou décommissionnés : une ancienne préproduction devenue inutile a par exemple été supprimée. Moins de sites exposés, c'est moins de surface d'attaque.

À la sortie des versions corrigées, nous avons mis à jour les paquets PHP fournis par Plesk vers 8.2.35, 8.3.36 et 8.4.27. Nous avons ensuite contrôlé trois choses : les versions réellement installées, le redémarrage effectif des services, et la version réellement servie par chaque site.

Même après la mise à jour, nous avons conservé la désactivation de session.upload_progress. C'est une couche de protection supplémentaire, dans une logique de défense en profondeur.

Au moment de lancer la mise à jour, apt refusait les dépôts PHP de Plesk avec une erreur NO_PUBKEY. La raison : Plesk signe désormais ses dépôts avec une nouvelle clé (identifiant 5B6AB2160B50DB96, créée en août 2026), qui n'était pas présente sur les serveurs.

Sans cette correction, les serveurs n'auraient jamais vu le correctif. Pas d'alerte visible, pas de mise à jour, et des sites qui restent vulnérables alors qu'on les croit à jour. C'est le genre de problème qui ne se remarque que si l'on vérifie réellement ce qui se passe.

Nous avons réimporté la clé officielle depuis https://autoinstall.plesk.com/plesk.gpg dans le trousseau référencé par la directive signed-by (/etc/apt/keyrings/plesk.gpg), après avoir vérifié qu'elle contenait bien la nouvelle clé. Si vous administrez un serveur Plesk, c'est un point à contrôler sans attendre.

Si votre site est hébergé et maintenu par StartingUp, vous n'avez rien à faire. Il tourne sur une version de PHP maintenue et corrigée, la mitigation recommandée par php.net est appliquée, et nous avons vérifié site par site la version réellement servie.

Si votre site est hébergé ailleurs, la section qui suit vous donne les bons réflexes selon votre situation.

Sur un hébergement mutualisé, c'est l'hébergeur qui met PHP à jour. Vous n'avez pas la main sur les paquets, mais vous pouvez vérifier :

• la version de PHP réellement servie par votre site, via l'interface de votre hébergeur ou un fichier phpinfo temporaire (à supprimer aussitôt après) ;
• qu'il s'agit d'une version maintenue : 8.2 au minimum, idéalement 8.3 ou plus ;
• que cette version est bien corrigée (8.2.35, 8.3.36, 8.4.27 ou 8.5.12).

Attention : selon php.net, la mitigation session.upload_progress.enabled=0 n'est pas efficace via .user.ini ni ini_set(). Sur un mutualisé, vous ne pouvez donc pas l'appliquer vous-même de façon fiable ; seule la mise à jour par l'hébergeur compte.

Vous avez la main, et donc la responsabilité. Dans l'ordre :

1. Vérifier que les dépôts sont accessibles et correctement signés : apt-get update ne doit renvoyer aucune erreur GPG.
2. Mettre à jour les paquets PHP vers une version corrigée.
3. Recharger PHP-FPM (ou redémarrer Apache si vous utilisez mod_php) pour que tous les workers utilisent le nouveau binaire.
4. Appliquer la mitigation dans php.ini ou la configuration FPM, jamais via .user.ini ni ini_set(), puis recharger à nouveau.
5. Vérifier la valeur réellement servie, site par site.

Quelques commandes génériques et sans risque.

Vérifier les dépôts et l'absence d'erreur GPG :

Vérifier la version installée pour une version de PHP donnée (ici 8.3) :

Recharger PHP-FPM après une mise à jour ou une modification de configuration :

Pour contrôler la valeur réellement appliquée côté web, déposez temporairement un fichier PHP contenant ceci, consultez-le depuis un navigateur, puis supprimez-le :

Si la version affichée n'est pas corrigée, ou si upload_progress vaut 1, le site n'est pas protégé, quoi qu'en disent vos fichiers de configuration.

Enfin, si vous êtes encore en PHP 8.1 ou antérieur, aucune mise à jour ne viendra : la migration vers une version maintenue est la seule option. Et si vous êtes en 8.2, anticipez dès maintenant la fin de vie du 31 décembre 2026.

Si vous avez un doute sur la version de PHP de votre site, si votre hébergeur ne vous répond pas, ou si vous souhaitez simplement qu'un regard extérieur vérifie que tout est en ordre, contactez-nous. Nous pouvons faire le point avec vous et, si besoin, prendre en charge la mise à jour ou la migration.