Failles critiques dans PHP (octobre 2026) : versions touchées et que faire

Le 21 octobre 2026, le projet PHP a publié en urgence des correctifs pour deux failles critiques qui permettent d’exécuter du code à distance, sans authentification, sur un serveur qui sert des pages web en PHP. Le CERT-FR, le centre gouvernemental de veille et de réponse aux attaques, a émis l’alerte CERTFR-2026-ALE-014 et a connaissance de preuves de concept.

Si votre site ou votre application est en PHP, voici ce qu’il faut savoir et faire.

Ce que permettent ces failles

Les deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, touchent la gestion interne des requêtes par PHP lui-même, avant même que le code de votre application ne s’exécute. Un attaquant peut, avec une requête forgée, faire exécuter le code de son choix sur le serveur.

Selon l’avis de sécurité de PHP, toutes les installations qui servent des requêtes web sont exposées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php. Le framework utilisé (Symfony, Laravel, CakePHP, Drupal, WordPress…) ne change rien : la faille est en dessous.

Les versions touchées et les versions corrigées

Branche	Version corrigée	État de la branche
PHP 8.5	8.5.12	Maintenue
PHP 8.4	8.4.27	Maintenue
PHP 8.3	8.3.36	Correctifs de sécurité seulement
PHP 8.2	8.2.35	Fin de vie le 31 décembre 2026
PHP 8.1 et antérieures	Aucune	Plus maintenues

Toutes les versions antérieures à celles du tableau sont vulnérables, y compris toutes les versions de PHP 5, 7, 8.0 et 8.1.

Mon application tourne sur PHP 8.1, 7.4 ou plus ancien

C’est le cas le plus délicat. Le projet PHP ne publie plus de versions pour ces branches. Il a mis à disposition des correctifs minimaux pour 7.4, 8.0 et 8.1, à compiler soi-même, et certaines distributions Linux ou certains fournisseurs de support étendu les intègrent dans leurs paquets.

Trois options, de la plus durable à la plus provisoire :

1. Migrer vers PHP 8.4 ou 8.5. C’est la seule solution qui règle aussi les prochaines failles. Une application ancienne demande souvent de monter aussi son framework de version : nous détaillons la démarche sur notre page migration PHP.
2. Obtenir un PHP corrigé auprès de votre hébergeur ou de votre distribution, s’il en propose un pour votre version. Demandez-lui explicitement si les CVE-2026-109618 et CVE-2026-109619 sont couvertes.
3. Appliquer les mesures d’attente ci-dessous, en sachant qu’elles réduisent le risque sans le supprimer.

Les mesures d’attente

Pour une installation qui ne peut pas être mise à jour immédiatement, l’avis de PHP propose des contournements dans la configuration (php.ini), à appliquer puis à suivre d’un redémarrage de chaque processus PHP :

; Contre CVE-2026-109619
session.upload_progress.enabled = 0

; Sur PHP 8.5 uniquement
fatal_error_backtraces = 0

Contre CVE-2026-109618, l’avis recommande de lever la limite de mémoire interne de PHP (memory_limit = -1), de réduire la taille maximale des requêtes acceptées (post_max_size) et de limiter à la place la mémoire disponible pour PHP au niveau du système. Ces réglages ont des effets sur l’application, comme l’envoi de fichiers volumineux : testez-les avant de les appliquer en production.

PHP le dit clairement : ces contournements « ne rendent pas une installation sûre ». Le CERT-FR rappelle que seule la mise à jour protège, et recommande d’isoler les systèmes concernés en attendant.

Une troisième faille, sans correctif pour l’instant

Le 23 octobre, PHP a signalé une autre faille d’exécution de code à distance, CVE-2026-115560, ajoutée à l’alerte du CERT-FR le 26 octobre. Elle n’est exploitable que dans une configuration rare : une application qui change le format de sérialisation des sessions en cours d’exécution, avec le suivi de progression des envois de fichiers activé. Son correctif sortira avec les prochaines versions de PHP.

Si vous avez désactivé session.upload_progress.enabled après l’alerte du 21 octobre, laissez ce réglage en place.

Comment savoir quelle version de PHP vous utilisez

• Votre hébergeur l’indique dans son espace client, souvent dans la rubrique d’hébergement web ou de configuration PHP.
• En ligne de commande sur le serveur, php -v donne la version du PHP en ligne de commande, qui peut différer de celle qui sert le site.
• Votre développeur ou votre prestataire de maintenance peut vous la donner en quelques minutes.

Ce que cette alerte nous rappelle

Les failles critiques dans PHP lui-même sont rares, mais des failles moins spectaculaires sont publiées chaque mois, dans PHP, dans les frameworks et dans les bibliothèques. Les applications qui ont traversé cette semaine sans stress ont deux points communs : une version de PHP maintenue, et quelqu’un chargé d’appliquer les mises à jour.

C’est le rôle d’un contrat de tierce maintenance applicative. Et si vous ne savez pas dans quel état est votre application, un audit de sécurité vous le dira en quelques jours.

Sources : alerte CERTFR-2026-ALE-014 du CERT-FR, mise à jour le 27 octobre 2026, et avis de sécurité publiés sur php.net. Article à jour au 1er novembre 2026.