Vulnérabilités critiques dans PHP – mettez à jour maintenant (CVE-2026-109618 et CVE-2026-109619)

Le 20 octobre, le projet PHP a annoncé une version de sécurité pour deux vulnérabilités critiques. Le 21 octobre à 13 h 30 UTC, les correctifs ont été publiés. Les deux vulnérabilités permettent une exécution de code à distance non authentifiée avec un score CVSS de 9,2, et un code proof-of-concept public circule déjà.

Ce n'est pas une vulnérabilité que vous planifiez dans la prochaine fenêtre de maintenance. C'est une vulnérabilité que vous corrigez aujourd'hui.

L'essentiel

• Mettez à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
• Tout PHP qui traite des requêtes web est concerné – PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed.
• Une seule requête non authentifiée peut suffire, et elle peut frapper avant même l'exécution du code de votre application.
• Le code PoC est public. Attendez-vous à un balayage massif en quelques heures, pas en quelques semaines.
• Si vous ne pouvez pas corriger tout de suite : isolez les services exposés à Internet jusqu'à ce que le correctif soit en place et vérifié.

Ce qui s'est passé

Le 20 octobre, le projet PHP a annoncé qu'une version de sécurité était en préparation. Le lendemain, le 21 octobre à 13 h 30 UTC, les correctifs ont été publiés simultanément dans quatre versions : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le CERT-EU a émis un avis de sécurité le jour même et appelé les organisations à mettre à jour immédiatement.

Un correctif rapide, c'est une bonne chose. Que la description technique soit devenue publique en même temps signifie que le délai entre « le correctif existe » et « les attaquants essaient » se mesure en heures.

Ce que font réellement ces vulnérabilités

CVE-2026-109618 – corruption de mémoire à la limite mémoire

PHP interrompt une requête qui dépasse memory_limit en l'interrompant via longjmp(). L'interruption peut donc survenir au milieu d'une opération interne, alors que les données de la requête ne sont que partiellement initialisées – par exemple pendant l'analyse d'un envoi de fichier dans un formulaire.

Le nettoyage de la requête peut alors traiter des données invalides comme valides et libérer de la mémoire qui n'a jamais été initialisée. Cette mémoire peut encore contenir des données provenant d'allocations antérieures, contrôlées par l'attaquant. Le résultat est une corruption de mémoire susceptible de mener à une exécution de code.

CVE-2026-109619 – état global résiduel

Un état interne appartenant à une requête peut survivre après la libération de sa mémoire – par exemple après une erreur fatale. Une requête ultérieure traitée par le même processus de travail peut utiliser cet état résiduel avant que l'initialisation normale ait pu le réinitialiser.

Aucune des deux vulnérabilités n'exige donc un bug dans votre application. Elles se situent dans le traitement des requêtes de PHP lui-même.

Un exploit démontré montre qu'une seule requête non authentifiée peut déclencher l'attaque avant l'exécution de la moindre ligne de code applicatif.

Qui est concerné

Toutes les installations PHP qui servent du trafic web. L'équipe PHP considère mod_php comme la configuration la plus exposée.

• PHP 8.5 avant 8.5.12
• PHP 8.4 avant 8.4.27
• PHP 8.3 avant 8.3.36
• PHP 8.2 avant 8.2.35
• Les branches en fin de vie (PHP 8.1 et antérieures), qui ne reçoivent plus de mises à jour régulières

De plus : de nombreux produits commerciaux et open source utilisent PHP en arrière-plan. Ils peuvent être concernés même si vous n'exploitez pas vous-même une installation PHP. Le NCSC-NL a publié une liste de logiciels tiers intégrant PHP.

L'erreur la plus fréquente que nous observons : ne compter que les serveurs que vous avez installés vous-même. N'oubliez pas les conteneurs, les images CI, les appliances, les outils internes et les services gérés par des prestataires.

Vérifiez votre exposition – cinq minutes par environnement

1. Lancez php -v sur chaque hôte et dans chaque conteneur. Pas seulement sur un seul.
2. Inventoriez les environnements d'exécution : pools PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Reconstruisez les images de conteneurs – c'est l'image de base qui compte, pas l'instance en cours d'exécution.
4. Interrogez les prestataires qui exploitent pour vous des produits dépendant de PHP : quelle version faites-vous tourner, et quand serez-vous corrigés ?
5. Repérez les branches en fin de vie. PHP 8.1 et antérieures ne reçoivent plus de correctifs réguliers.

Corrigez

Paquets des distributions. Les distributions Linux et les fournisseurs LTS disposaient des correctifs à l'avance. Mettez à jour via le gestionnaire de paquets et redémarrez les processus de travail.

Conteneurs. Mettez à jour l'image de base et reconstruisez. Redémarrer une ancienne image ne résout rien.

Compilation maison. Mettez à niveau vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Versions en fin de vie. L'équipe PHP a publié des backports minimaux pour 7.4, 8.0 et 8.1 à destination de ceux qui compilent depuis les sources ou n'ont pas de fournisseur LTS. Si vous avez un fournisseur LTS : contactez-le d'abord.

rpms.remirepo.net : ce dépôt maintenu bénévolement ne reçoit pas de mises à jour le jour de la publication. L'équipe PHP invite les utilisateurs à passer aux paquets de leur distribution ou à compiler depuis les sources.

Redémarrez PHP-FPM et les autres processus de travail après la mise à jour. Un nouveau binaire sans redémarrage reste l'ancien processus.

Si vous ne pouvez pas corriger aujourd'hui

Les mesures ci-dessous réduisent l'exposition à certains chemins d'attaque. Elles ne rendent pas l'installation sûre. Seule une mise à jour ferme la vulnérabilité.

Contre CVE-2026-109618 :

• Réglez memory_limit=-1 d'une manière que l'application ne peut pas écraser, par exemple php_admin_value dans le pool FPM ou dans la configuration Apache. Vérifiez qu'aucun pool, répertoire ou réglage applicatif ne rétablit de limite.
• Fixez un post_max_size bas : 8M pour les applications sans envoi de fichiers, 32M là où l'envoi est nécessaire. Gardez upload_max_filesize inférieur à post_max_size.
• Fixez dans le serveur web ou le proxy des limites sur la taille de requête décodée, le nombre de champs, le nombre de parties multipart, le nombre d'en-têtes et la profondeur d'imbrication. Les limites doivent couvrir aussi les requêtes sans Content-Length exploitable.
• Utilisez une limite mémoire de conteneur ou de cgroup comme limite de disponibilité, de préférence avec une politique qui ne tue que le processus de travail touché. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA – ils peuvent déclencher le chemin d'allocation vulnérable.

Contre CVE-2026-109619 :

• Réglez session.upload_progress.enabled=0 et redémarrez chaque processus de travail. Placez-le dans php.ini, dans le pool FPM ou dans la configuration du serveur pour qu'il s'applique avant l'analyse de la requête. Ne comptez pas sur ini_set() ni sur le .user.ini de FPM.
• Sur PHP 8.5 : réglez fatal_error_backtraces=0 et redémarrez chaque processus de travail.
• Supprimez les réglages par requête invalides ou obsolètes qui émettent des diagnostics avant l'initialisation. Masquer les diagnostics avec error_reporting, display_errors ou @ n'aide pas.
• Corrigez les erreurs fatales et les limites d'exécution qu'un attaquant peut atteindre – dans les callbacks, les envois, les imports et le nettoyage.

Pourquoi il ne faut pas attendre

Trois éléments distinguent cet événement d'un correctif ordinaire :

1. Aucune authentification n'est requise. Il n'y a pas de connexion derrière laquelle se cacher.
2. L'attaque se produit avant votre code. La logique applicative, les règles WAF et le modèle de permissions ne sont pas une barrière ici.
3. Le PoC est déjà public. Ce qui prend habituellement des semaines a déjà été fait par quelqu'un d'autre.

Le coût d'un correctif et d'un redémarrage aujourd'hui est négligeable face au coût d'une intrusion. Cela vaut particulièrement si vous êtes concerné par NIS2, où un incident important doit être signalé dans les 24 heures.

Après le correctif – trois choses

1. Vérifiez sur chaque nœud. La version – pas seulement le OK du gestionnaire de paquets.
2. Relisez les journaux à rebours. Requêtes POST multipart, réponses 500 inattendues, processus de travail plantés et trafic de sources inconnues ces derniers jours.
3. Au moindre doute : déclenchez la procédure d'incident. Isolez, sécurisez les journaux, évaluez l'obligation de notification.

Sources

• CERT-EU, Security Advisory 2026-018 : https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 : https://www.php.net/
• GHSA-w8hw-w9fx-j79w : https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp : https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, liste des produits intégrant PHP : https://github.com/NCSC-NL/php2shell

---

Ce type de vulnérabilité est en soi l'argument pour une sécurité continue : des correctifs, des vérifications et une surveillance qui tournent en permanence – pas une revue annuelle. En savoir plus sur ce que signifie la sécurité continue en pratique.