Faille de sécurité PHP CVE-2026-109618 : comment la corriger

Le 21 octobre 2026, le projet PHP a corrigé deux failles de sécurité critiques : CVE-2026-109618 et CVE-2026-109619. Toutes deux permettent à des attaquants non authentifiés d'exécuter du code sur le serveur web via le réseau (CVSS 9,2). Le seul remède complet est la mise à jour vers PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, suivie d'un redémarrage de tous les processus PHP.

Vous trouverez ici comment vérifier en quelques minutes si votre site est concerné, installer la mise à jour et prouver qu'aucun ancien processus PHP ne tourne plus. Nous avons installé les mises à jour sur nos propres serveurs le soir même ; les étapes de vérification ci-dessous proviennent de ce travail.

Que dois-je faire maintenant ?

Vous exploitez votre propre serveur ou un serveur virtuel :

1. Vérifier la version de PHP (section ci-dessous).
2. Installer la mise à jour pour chaque version de PHP installée.
3. Redémarrer PHP-FPM ou Apache.
4. Prouver qu'aucun ancien processus PHP ne tourne plus.
5. Rechercher des traces d'attaque si le serveur est resté exposé longtemps.

Votre site est chez un hébergeur (hébergement mutualisé, hébergement WordPress) :

1. Consulter la version de PHP de votre site dans le panneau d'hébergement ou dans WordPress.
2. Demander à l'hébergeur si la mise à jour a été installée et si PHP a été redémarré.
3. Si votre site tourne encore sous PHP 8.1 ou une version plus ancienne : passer à PHP 8.3 ou plus récent dans le panneau.

Que s'est-il passé ?

Le projet PHP a publié le 21 octobre 2026 à 14h00 UTC les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. L'annonce sur php.net s'intitule « Critical remote code execution vulnerabilities, update now ». Pour vous, cela signifie que depuis cet après-midi, les failles sont documentées publiquement et que tout serveur non mis à jour est une cible connue.

Quelles versions de PHP sont concernées ?

Toutes les versions antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12 sont concernées. Seules ces quatre versions et toute version ultérieure sont sûres.

Pour PHP 8.1 et les versions plus anciennes, php.net renvoie au fournisseur concerné. C'est à lui de prouver qu'il a rétroporté le correctif. La voie sûre est de passer à PHP 8.3 ou plus récent, car selon php.net, PHP 8.2 ne reçoit plus de mises à jour de sécurité que jusqu'au 31 décembre 2026.

Comment vérifier ma version de PHP ?

Ce qui compte, c'est la version avec laquelle tourne votre site web, pas celle de la ligne de commande. Les deux peuvent différer, car plusieurs versions de PHP sont souvent installées en parallèle.

• Panneau d'hébergement (Plesk, cPanel) : la version de PHP figure généralement dans les paramètres du domaine concerné.
• WordPress : « Outils → Santé du site → Info → Serveur » affiche la version avec laquelle le site tourne réellement.
• Serveur dédié (Debian, Ubuntu) : php-fpm8.4 -v affiche la version du service FPM, dpkg -l 'php8.4*' les paquets installés. Avec Plesk, chaque version se trouve sous /opt/plesk/php/<Version>/bin/php.

Les distributions intègrent parfois le correctif dans leur propre numéro de version, par exemple avec un suffixe comme ~deb12u1. Dans ce cas, c'est l'avis de sécurité de la distribution qui fait foi, pas le seul numéro amont.

Quel est le danger de cette faille pour mon site ?

La faille est sérieuse, car une attaque ne nécessite ni compte ni clic de la victime. Toutes les indications de cette section proviennent des deux avis de sécurité et de l'annonce sur php.net (sources ci-dessous).

• Apache avec mod_php : l'attaque est ici entièrement démontrée. Une requête sans authentification peut la déclencher avant même que le code de votre application ne s'exécute. Un plugin de sécurité dans WordPress n'y change donc rien.
• PHP-FPM (typique avec nginx et chez de nombreux hébergeurs) et php-cgi : également exposés. Pour FPM, la faille est établie dans le code source, mais aucune attaque complète n'a été démontrée.
• FrankenPHP et LiteSpeed : figurent également sur la liste des installations exposées.

CVE-2026-109618 est déclenchée par exemple par un formulaire préparé avec envoi de fichier (multipart) qui épuise la mémoire de PHP. Un attaquant qui réussit s'exécute avec les droits du compte du serveur web. Il peut ainsi, en règle générale, modifier les fichiers du site et lire les accès à la base de données dans la configuration.

Est-ce un zero day ?

D'après les informations publiées, pas au sens strict. Ni les avis de sécurité ni php.net ne signalent que les failles aient été exploitées avant le correctif. Le projet PHP s'était toutefois réservé le 20 octobre le droit de publier plus tôt si des attaques apparaissaient. Depuis le 21 octobre, les détails techniques sont publics, et le délai avant les premières attaques est, d'expérience, court.

Comment corriger la faille de sécurité PHP ?

Vous corrigez la faille en trois étapes : installer la mise à jour, redémarrer les processus PHP, mesurer le résultat. La deuxième étape est la plus souvent oubliée.

1. Installer la mise à jour de PHP

Sous Debian et Ubuntu, la mise à jour passe par le gestionnaire de paquets ; avec un panneau d'hébergement (Plesk, cPanel), par sa fonction de mise à jour :

sudo apt update
sudo apt install --only-upgrade 'php8.4*'

Remplacez 8.4 par votre version, et répétez l'étape pour chaque version de PHP installée. Même une version qu'aucun site n'utilise actuellement peut encore tourner comme service.

2. Redémarrer PHP-FPM

Une mise à jour ne remplace que les fichiers sur le disque. Les processus PHP en cours continuent de travailler avec l'ancienne version vulnérable en mémoire. C'est pourquoi un redémarrage est nécessaire après chaque mise à jour :

sudo systemctl restart php8.4-fpm   # PHP-FPM
sudo systemctl restart apache2      # nur bei mod_php

3. Vérifier que la nouvelle version tourne réellement

La méthode la plus fiable consiste à chercher les processus qui ont encore chargé un fichier PHP supprimé, donc ancien :

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*(deleted)'
sudo grep -l 'libphp.*(deleted)' /proc/*/maps 2>/dev/null

Si les deux sorties restent vides, plus aucun processus PHP ne tourne avec l'ancienne version. Sous Debian et Ubuntu, sudo needrestart -r l indique en plus quels services utilisent encore d'anciennes bibliothèques. Par cette méthode, nous avons trouvé sur nos serveurs des processus qui, sans redémarrage, auraient continué d'exécuter l'ancien code.

4. Rechercher des traces

Si votre serveur est resté longtemps accessible sans mise à jour, il vaut la peine de jeter un œil à ces trois endroits :

• Journaux : l'avis de sécurité sur CVE-2026-109619 mentionne les journaux d'Apache, de PHP-FPM et du reverse proxy, par exemple des avertissements PHP avant le script proprement dit ou « Maximum execution time exceeded ». Selon l'avis, l'absence d'une entrée ne prouve cependant pas qu'il n'y a pas eu d'attaque.
• Fichiers modifiés : find /var/www -name '*.php' -newermt '2026-10-21' liste les fichiers PHP modifiés depuis le 21 octobre. Vos propres déploiements y apparaissent aussi ; tout ce que vous ne pouvez pas attribuer est suspect.
• Dossier d'envoi : des fichiers PHP dans des dossiers qui ne devraient contenir que des images et des documents (avec WordPress wp-content/uploads) sont un signal d'alarme.

Que faire si je ne peux pas mettre à jour immédiatement ?

Vous pouvez alors réduire la surface d'attaque, mais pas la fermer. Selon php.net, ces atténuations laissent une installation « non sûre ». Elles sont un pont jusqu'à la mise à jour. Tous les points proviennent des deux avis de sécurité, et chaque réglage ne prend effet qu'après un redémarrage des processus PHP.

• Limiter les saisies de formulaire :
  • Garder post_max_size petit et limiter la taille des requêtes dès le serveur web ou le proxy.
  • Abaisser max_input_vars et max_input_nesting_level.
  • Limiter le nombre d'envois de fichiers et de parties de formulaire.
• Bloquer les envois de fichiers là où ils ne sont pas nécessaires : si l'application n'utilise pas de formulaires multipart, le serveur web peut les rejeter.
• Désactiver la progression d'envoi : session.upload_progress.enabled=0. C'est aussi judicieux après le correctif si vous n'utilisez pas cette fonction.
• Faire vivre les workers peu de temps : pm.max_requests=1 dans PHP-FPM limite la durée de survie d'un ancien état dans un processus. Cela coûte en performances.
• Lever la limite de mémoire (cela semble faux, mais c'est ainsi) : memory_limit=-1 est le réglage le plus important contre CVE-2026-109618, mais expressément incomplet. Il retire à l'attaquant la limite prévisible à laquelle il déclenche le manque de mémoire. Le prix : une seule requête peut alors occuper autant de mémoire que le serveur en possède.
• Pas de RLIMIT_AS ni de RLIMIT_DATA : ces limites font échouer l'allocation de mémoire et conduisent précisément dans le chemin vulnérable.

Questions fréquentes sur la faille de sécurité PHP

WordPress est-il concerné par la faille PHP ?

Oui, si le site tourne sur une version de PHP non corrigée. La faille se trouve dans PHP lui-même, pas dans WordPress, un plugin ou un thème. Une mise à jour de WordPress ne la corrige pas.

Dois-je mettre à jour chaque version de PHP installée séparément ?

Oui. Chaque branche (8.2, 8.3, 8.4, 8.5) est un paquet à part avec son propre service. Sur les serveurs avec panneau d'hébergement, plusieurs versions coexistent souvent, et chacune a besoin de sa mise à jour et de son redémarrage.

Un redémarrage du serveur web suffit-il ?

Pas avec PHP-FPM : redémarrer nginx ou Apache ne recharge pas PHP. Vous devez redémarrer le service FPM de chaque version, par exemple php8.3-fpm et php8.4-fpm.

Comment savoir que mon hébergeur a redémarré PHP ?

De l'extérieur, on ne peut pas en être sûr. Demandez expressément la mise à jour et le redémarrage. Dans WordPress, la Santé du site affiche le nouveau numéro de version après le redémarrage.

Existe-t-il une configuration qui ferme complètement la faille ?

Non. Les deux avis de sécurité désignent la mise à jour comme seul remède complet.

Aide pour l'application des correctifs

Vous exploitez plusieurs serveurs ou un projet PHP sur mesure et voulez être certain que plus rien ne tourne avec l'ancienne version ? Lors d'un audit de code et de sécurité, nous examinons votre application et son environnement d'exécution. Pour une évaluation rapide, vous pouvez nous joindre via le formulaire de contact.

Sources

• GitHub Security Advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• php.net : Security advisory: Critical remote code execution vulnerabilities, update now (21.10.2026)
• php.net : Upcoming Critical PHP Security Release (20.10.2026)
• php.net : PHP 8.2.35 Released (avec mention de la fin du support le 31.12.2026)

Situation au 22 octobre 2026. Information technique générale, sans garantie ; vérifiez les étapes sur votre système avant de les appliquer.