Faille PHP CVE-2026-109618 et CVE-2026-109619 : vérifier sa version et mettre à jour sans casse

Le 21 octobre 2026, le projet PHP a publié quatre versions de sécurité qui corrigent deux failles critiques. Elles peuvent permettre à une requête non authentifiée d'exécuter du code sur le serveur. Ce guide rassemble ce que disent les avis officiels, comment savoir si vos serveurs sont concernés sans vous fier à un en-tête, et l'ordre dans lequel je fais la mise à jour.

Ce qui a été corrigé

Le projet PHP avait prévenu la veille, le 20 octobre, d'une publication de sécurité pour deux failles notées 9,2 en CVSS v4.0. Les versions sont sorties le 21 octobre, avec deux avis détaillés :

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) : quand la mémoire vient à manquer, PHP peut être interrompu 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 traiter ces données invalides comme valides.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) : 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 avant qu'il soit réinitialisé.

Dans les deux cas, l'issue possible est une exécution de code à distance, sans compte ni mot de passe. Les notes de version sont nettes : il n'existe pas de mesure de contournement complète, la mise à jour est la seule option sûre.

Versions corrigées, branche par branche

Toutes les versions antérieures de chaque branche sont touchées : 8.3.35 et avant pour la 8.3, par exemple. Les distributions Linux et les éditeurs de support étendu ont reçu les correctifs à l'avance : vérifiez auprès de votre fournisseur avant de compiler quoi que ce soit.

Qui est exposé

D'après l'avis de php.net, toutes les installations de PHP qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé pour mod_php, sur lequel une attaque a été démontrée avant même l'exécution du code de l'application.

Les avis GitHub nuancent selon le mode d'exécution. Pour CVE-2026-109618, l'exécution de code complète a été validée contre mod_php avec les limites par défaut ; pour PHP-FPM, l'analyse du code indique une exposition, sans attaque complète démontrée. Pour CVE-2026-109619, le cas confirmé vise aussi mod_php, et un chemin passant par la progression d'envoi de session a été validé contre PHP-FPM. Une attaque non démontrée n'est pas une attaque impossible : PHP-FPM se met à jour comme le reste.

La ligne de commande seule (scripts, tâches planifiées, outils de build) n'est pas citée par l'avis. Le CLI est pourtant presque toujours installé à côté de FPM : je mets à jour l'ensemble.

Vérifier sa version

Sur le serveur

# Version du PHP en ligne de commande
php -v

# Version de PHP-FPM : le binaire porte souvent le numéro de branche
php-fpm8.3 -v

# Dans un conteneur Docker
docker compose exec app php -v

Le PHP de la ligne de commande n'est pas toujours celui qui sert le site : plusieurs branches cohabitent souvent sur un même serveur. Vérifiez celle qu'utilise réellement la configuration du serveur web ou du pool FPM.

Avec les paquets de la distribution

Debian, Ubuntu ou Red Hat appliquent souvent un correctif de sécurité à leur propre paquet sans changer le numéro de PHP : seule la révision du paquet change. Un php -v qui affiche une version antérieure à celles du tableau ne veut donc pas dire que le serveur est vulnérable.

# Debian, Ubuntu
dpkg -l | grep php

# Red Hat, Rocky, Alma
rpm -qa | grep php

Comparez la révision installée à celle du bulletin de sécurité de votre distribution pour ces deux CVE.

Sous WordPress

Dans l'administration : Outils, Santé du site, onglet Infos, rubrique Serveur. C'est la version de PHP qui exécute réellement le site, ce qui évite la confusion avec le CLI. La même remarque vaut pour les paquets de distribution : le numéro affiché ne dit pas si un correctif a été rétroporté.

Sur un hébergement mutualisé

Le panneau de l'hébergeur indique la branche choisie pour le site. Seul l'hébergeur peut dire si le correctif est appliqué : posez-lui la question et gardez la réponse par écrit. Si le site est encore en 8.1 ou en 7.x, la seule sortie est de choisir une branche maintenue, après un essai sur une copie.

Et phpinfo() ?

En production, phpinfo() est souvent désactivée, et elle doit l'être : la page expose toute la configuration du serveur. Si vous en avez besoin pour vérifier, créez-la sous un nom imprévisible, lisez-la, et supprimez-la dans la minute.

Ce qu'un en-tête X-Powered-By ne dit pas

Beaucoup de serveurs renvoient un en-tête du type X-Powered-By: PHP/8.3.20. Il est tentant d'en tirer une conclusion, sur son site ou sur celui d'un autre. C'est une erreur dans les deux sens :

• le numéro peut être celui d'un paquet de distribution déjà corrigé, qui garde l'ancien numéro ;
• l'en-tête disparaît avec expose_php = Off, ou peut être retiré ou réécrit par un proxy ;
• derrière un proxy inverse ou un CDN, il décrit au mieux le serveur qui a répondu, pas les autres ;
• son absence ne prouve pas davantage qu'un site est à jour.

Un en-tête est un indice pour savoir où regarder, jamais un diagnostic. Pour conclure, il faut la version du paquet installé, ou la réponse écrite de l'hébergeur.

Mesures temporaires, et leurs limites

Quand la version corrigée n'est pas encore disponible chez vous (image Docker pas encore publiée, paquet en attente), php.net propose des réglages qui réduisent l'exposition. L'avis le dit lui-même : ils ne remplacent pas la mise à jour.

; php.ini, en attendant la version corrigée
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 2M

; PHP 8.5 seulement
fatal_error_backtraces = 0

• session.upload_progress.enabled = 0 bloque les chemins confirmés de CVE-2026-109619 passant par les sessions, pas les autres variantes. Il doit être posé dans php.ini, le pool FPM ou la configuration du serveur, pris en compte avant la lecture de la requête : ni ini_set() ni .user.ini ne conviennent. Redémarrez tous les processus.
• fatal_error_backtraces = 0, en 8.5, ne bloque que le chemin confirmé qui passe par les traces des erreurs fatales.
• Un post_max_size bas : 8M si le site ne reçoit pas de fichiers, 32M s'il en reçoit, avec upload_max_filesize en dessous. Des limites posées au niveau du serveur web ou du proxy (taille de la requête, nombre de champs, de parties, d'en-têtes) complètent le réglage.
• memory_limit = -1, posé par php_admin_value pour qu'aucune application ne le rétablisse, est la mesure principale contre CVE-2026-109618, mais elle n'est pas complète non plus. Sans limite par requête, une seule requête peut consommer toute la mémoire : php.net conseille de s'appuyer alors sur une limite du conteneur ou du cgroup, et surtout pas sur RLIMIT_AS ou RLIMIT_DATA, qui déclenchent justement le chemin vulnérable.

Masquer les erreurs (error_reporting, display_errors, l'opérateur @) ne protège de rien. Ces réglages servent à tenir quelques jours, avec la date de la mise à jour déjà fixée.

Un plan de mise à jour sûr

1. Inventaire. Chaque environnement où tourne PHP : production, préproduction, conteneurs de tâches planifiées et de files d'attente, images utilisées en intégration continue. Pour chacun, la branche, la version exacte et le mode d'exécution.
2. Version exacte, même branche. 8.3.36 pour un site en 8.3, sans version de test. Dans un Dockerfile, une étiquette exacte (php:8.3.36-fpm) plutôt qu'une étiquette flottante (php:8.3-fpm), dont le contenu change sans que le dépôt ne le montre. Changer de branche, c'est un autre chantier, avec ses propres tests.
3. Mesures temporaires là où la version corrigée n'est pas encore disponible, avec la date à laquelle on les retire.
4. Essai sur une copie. Pages principales, formulaires, envois de fichiers, tâches planifiées, files d'attente : une version corrective change peu de choses, mais c'est sur une copie qu'on le vérifie.
5. Déploiement et redémarrage. PHP-FPM, Apache, et surtout les processus longs (workers de files d'attente, mode worker de FrankenPHP) : tant qu'ils ne sont pas relancés, l'ancien code tourne en mémoire.
6. Vérification depuis le site. La version vue par le serveur web, ou par la Santé du site sous WordPress, pas seulement php -v.

Contrôle d'intégrité après coup

Une mise à jour ferme la faille. Elle ne retire rien de ce qui aurait été déposé avant. L'avis de php.net ne donne pas de signature d'attaque à rechercher : le contrôle porte donc sur des traces génériques, en partant de la date de l'annonce.

# Le code déployé est-il identique au dépôt ?
git status --porcelain
git diff --stat

# Fichiers PHP présents mais absents du dépôt
git ls-files --others --exclude-standard | grep '\.php$'

# Du PHP là où il ne devrait jamais y en avoir
find wp-content/uploads public/uploads storage -name "*.php" 2>/dev/null

# Sous WordPress : cœur et extensions comparés aux originaux
wp core verify-checksums
wp plugin verify-checksums --all

• Si le code n'est pas déployé depuis git, comparez-le à l'archive de la dernière livraison.
• Ne vous fiez pas aux dates de modification : elles se falsifient facilement.
• Dans les journaux, depuis le 20 octobre : requêtes POST inhabituelles, erreurs de mémoire épuisée en série, processus PHP-FPM terminés anormalement. Rien de tout cela ne prouve une attaque, mais chaque anomalie mérite d'être expliquée.
• Comptes administrateurs, tâches planifiées (crontab -l, wp cron event list) et clés SSH autorisées : rien ne doit avoir été ajouté sans que vous le sachiez.

Si le contrôle trouve quelque chose, on change de sujet : c'est une intrusion à traiter, avec ses propres étapes. Le guide site WordPress piraté : que faire les détaille, et la méthode vaut aussi hors de WordPress.

Récapitulatif

Après l'annonce, j'ai appliqué ce plan à huit projets PHP, à titre préventif. Si vous préférez confier la vérification ou la mise à jour de vos sites, voir diagnostic et mise à jour de sécurité PHP.