Failles PHP CVE-2026-109618 et CVE-2026-109619 : ce qu'elles permettent, les versions corrigées, et que faire en PHP 8.1 ou plus ancien

Le 21 octobre 2026, l'équipe de PHP a publié en page d'accueil de php.net un avis de sécurité au titre sans détour : « Critical remote code execution vulnerabilities, update now ». Deux failles, CVE-2026-109618 et CVE-2026-109619, peuvent permettre à quelqu'un d'exécuter son propre code sur votre serveur, sans compte et sans mot de passe.

Les deux fiches techniques publiées sur GitHub par le projet PHP les classent « critical », avec un score CVSS 4.0 de 9,2 sur 10 chacune.

Ce qui suit reprend l'avis de php.net et ces deux fiches, lus le 23 octobre 2026. Nous n'y ajoutons aucun détail d'exploitation.

Qui est concerné

D'après php.net, toute installation PHP qui sert des requêtes web est exposée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le cas le plus grave est mod_php : l'équipe de PHP indique avoir vu fonctionner une attaque où une requête anonyme déclenche la faille « before any application code runs », donc avant que votre application, Symfony ou autre, n'ait exécuté une seule ligne.

Conséquence directe : un framework à jour, un pare-feu applicatif dans le code ou une authentification bien faite ne protègent pas ici. La faille est dans le moteur, pas dans votre code.

Ce que font les deux failles, en clair

CVE-2026-109618, « RCE via OOM corruption ». Quand PHP manque de mémoire au mauvais moment, il interrompt la requête alors que certaines de ses données internes ne sont qu'à moitié initialisées. Le nettoyage de fin de requête peut ensuite traiter ces données invalides comme valides. La fiche GitHub décrit plusieurs façons de provoquer ce manque de mémoire avec une requête d'envoi de formulaire (multipart) qui reste, en apparence, sous les limites fixées par la configuration.

CVE-2026-109619, « RCE via stale global state ». Un processus PHP traite les requêtes les unes après les autres. Certaines informations propres à une requête peuvent survivre à la libération de sa mémoire. La requête suivante, traitée par le même processus, peut alors s'en servir avant la remise à zéro normale. C'est ce qu'on appelle une utilisation après libération (« use after free »), et la fiche indique qu'une disposition de la mémoire bien préparée mène à l'exécution de code.

Les versions corrigées

Les versions et les dates viennent de l'avis du 21/10 et de la page des versions supportées de php.net, lues le 23/10/2026.

Si votre serveur utilise les paquets de votre distribution Linux, le numéro peut différer : php.net précise que les distributions et les fournisseurs de support long ont reçu les correctifs en avance. Ce qui compte, c'est que votre paquet annonce la correction de ces deux CVE dans son journal de modifications, pas son numéro.

Un piège courant : la version affichée par php -v en ligne de commande n'est pas forcément celle qui sert votre site. Vérifiez aussi le PHP-FPM ou le module Apache, puis redémarrez tous les processus après la mise à jour.

Votre projet tourne en PHP 8.1, 8.0 ou 7.4

C'est la partie délicate. Le projet PHP ne publie plus de mise à jour pour ces versions. L'avis ouvre trois portes :

• Votre distribution ou un fournisseur de support long. Certains reportent les correctifs sur les anciennes versions. Demandez-leur si les deux CVE sont couvertes, et sur quel paquet.
• Les correctifs minimaux de l'équipe de sécurité. Vu la gravité, elle a tout de même publié des branches de code source corrigées pour PHP 7.4, 8.0 et 8.1. Elles servent à qui compile PHP lui-même. Ce n'est pas un retour du support : la prochaine faille n'aura peut-être pas ce traitement.
• Passer sur une version supportée. C'est la seule voie qui ne dépend pas de la bonne volonté d'un tiers.

Le dernier point a un coût. Monter de PHP 7.4 ou 8.0 à 8.4, c'est souvent changer aussi la version de Symfony et des bibliothèques, et corriger le code que les nouvelles versions refusent. Cela se planifie en jours ou en semaines selon la taille du projet, pas en une soirée. D'où l'intérêt d'appliquer tout de suite un correctif de distribution ou une mesure d'attente, puis de lancer la migration à froid.

Un rappel pour ceux qui sont en PHP 8.2 : vous êtes corrigés avec la 8.2.35, mais la branche s'arrête le 31/12/2026 selon php.net. Dans un peu plus de deux mois, vous serez dans la situation des projets en 8.1 aujourd'hui.

Si vous ne pouvez pas mettre à jour aujourd'hui

L'avis de php.net est explicite : seule la mise à jour règle le problème, et les mesures suivantes « reduce exposure to specific attack paths but do not make an installation safe ». Elles réduisent le risque le temps de déployer. Rien d'autre.

Contre CVE-2026-109618 :

• memory_limit=-1, posé là où l'application ne peut pas le modifier (par exemple php_admin_value dans le pool FPM ou la configuration Apache), en vérifiant qu'aucun autre réglage ne remet une limite.
• Un post_max_size bas : 8M si l'application ne reçoit pas de fichiers, 32M sinon, avec upload_max_filesize en dessous.
• Des limites au niveau du serveur web ou du proxy sur la taille des requêtes, le nombre de champs, de parties et d'en-têtes, y compris pour les requêtes sans Content-Length utilisable.
• Une limite mémoire de conteneur ou de cgroup, de préférence qui ne tue que le processus touché. L'avis déconseille RLIMIT_AS et RLIMIT_DATA, qui peuvent justement provoquer la panne mémoire en cause.

Contre CVE-2026-109619 :

• session.upload_progress.enabled=0 dans php.ini ou le pool FPM, puis redémarrage de tous les processus. Un ini_set() ou un fichier .user.ini ne suffit pas, le réglage doit s'appliquer avant la lecture de la requête.
• En PHP 8.5, fatal_error_backtraces=0, avec redémarrage.
• Supprimer les réglages invalides ou dépréciés appliqués à chaque requête qui produisent des avertissements. Masquer ces avertissements ne sert à rien.

Une remarque pratique sur le premier point : retirer la limite mémoire supprime aussi un garde-fou. Un script qui s'emballe peut alors consommer toute la mémoire de la machine. La limite de conteneur, citée par php.net, est ce qui le rattrape.

Par où commencer, ce matin

1. Lister chaque serveur et chaque conteneur qui exécute PHP pour le web, avec la version réellement servie.
2. Mettre à jour ceux qui ont une version corrigée disponible, puis redémarrer tous les processus PHP.
3. Pour les autres, poser les mesures d'attente et demander à l'hébergeur ou à la distribution s'il existe un paquet corrigé.
4. Pour chaque projet en 8.2 ou plus ancien, fixer une date de migration.

Les fiches GitHub complètes (GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp) donnent le détail technique, pour vos équipes d'exploitation.

Et après

Une faille de cette gravité tombe rarement au bon moment. Un serveur bien suivi se corrige vite. Le projet resté en 7.4 ou en 8.0, parce que tout fonctionnait, demande bien plus.

Nous travaillons en Symfony et en PHP depuis plus de dix ans, et les montées de version font partie de ce que nous faisons pour nos clients. Si votre application tourne sur une version que le projet PHP ne suit plus, notre page agence Symfony explique comment nous reprenons et faisons évoluer une application existante. Pour un premier avis sur votre cas, écrivez-nous.