La nouvelle faille PHP, référencée CVE-2026-115560, a été signalée par l’équipe de PHP le 23 octobre, deux jours après les correctifs d’urgence contre PHP2Shell. Au 28 octobre, aucune exploitation n’est connue et aucun correctif d’urgence n’est prévu. Pour un responsable de site, la consigne se fait en deux temps : installer les versions du 21 octobre, puis désactiver un réglage dans la configuration de PHP.
CVE-2026-115560 : une faille réelle, mais difficile à exploiter
PHP a publié son alerte au niveau « informatif ». La faille appartient pourtant à la même famille que les précédentes. C’est une faille mémoire qui permet, en théorie, une exécution de code à distance : quelqu’un lance des commandes sur le serveur web depuis l’extérieur. L’équipe de sécurité du langage juge ce scénario « improbable », car il demande une « combinaison exceptionnelle de configurations et de code ».
Concrètement, trois conditions doivent être réunies en même temps. La première porte sur session.serialize_handler, le paramètre qui fixe la façon dont PHP enregistre les données de session : il doit valoir php_binary ou php_serialize. La deuxième porte sur le code du site : il doit modifier ce réglage en cours d’exécution, avec la fonction ini_set(), avant l’appel à session_start(). La troisième porte sur le suivi de progression des envois de fichiers, qui doit être activé.
Seule cette troisième condition est courante. Les deux autres relèvent de choix de développement rares. PHP intégrera donc la correction à sa prochaine version classique.
Faut-il refaire une mise à jour de PHP ?
Pas pour cette faille. En revanche, la mise à jour du 21 octobre reste la priorité si elle n’est pas encore faite sur vos serveurs. Elle corrige PHP2Shell, le nom donné à deux failles notées 9,2 sur 10. CVE-2026-109618 est une corruption de mémoire. CVE-2026-109619 vient d’un état de requête interne obsolète. Ensemble, elles permettent de prendre le contrôle d’un serveur. Nous avions détaillé les deux failles critiques de PHP corrigées le 21 octobre au moment de leur annonce.
Les failles touchent les branches 8.2 à 8.5. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les branches 8.1 et antérieures sont en fin de vie : elles ne reçoivent plus aucun correctif officiel.
Contre PHP2Shell, les attaques sont avérées. Le 27 octobre, la CISA, l’agence américaine de cybersécurité, a ajouté les deux failles à son catalogue des vulnérabilités exploitées connues (KEV). Perplexity a observé une attaque réussie sur ses serveurs pièges, appelés honeypots. « C’est désormais une exécution de code à distance confirmée, avec une fuite de mémoire exploitable, et pas seulement un plantage suivi d’un processus suspect », explique Adel Karimi, responsable détection et réponse chez Perplexity. Les attaquants visent Apache avec le module mod_php, sous PHP 8.4.26. Les tentatives se comptent en millions. Des sondages ont même été repérés quatre jours avant la publication des correctifs.
Le parc exposé reste large. 5,1 millions d’adresses IP exécutent PHP, dont au moins 758 000 dans une version en fin de vie. Environ 50 % des systèmes vulnérables ne recevraient jamais de patch.
La vérification à faire sur vos serveurs et vos sites
PHP recommande d’appliquer d’abord la mise à jour. Il faut ensuite ajouter la ligne session.upload_progress.enabled=0 dans le fichier php.ini, ou dans la configuration de PHP-FPM, le service qui exécute PHP derrière le serveur web. Ce réglage supprime la troisième condition. La chaîne d’exploitation ne peut alors plus aboutir.
Pour contrôler la situation, affichez une page phpinfo() ou lancez php -i en ligne de commande. Relevez trois valeurs : la version de PHP, session.upload_progress.enabled et session.serialize_handler. Cherchez ensuite dans le code, les thèmes et les modules les appels à ini_set(‘session.serialize_handler’) placés avant session_start(). Cette recherche vaut pour WordPress comme pour PrestaShop, où une extension tierce peut contenir ce type d’appel sans que vous le sachiez.
Une limite à retenir : passer en 8.2.35 ou plus protège de PHP2Shell, pas de CVE-2026-115560. Le réglage reste donc nécessaire après la mise à jour. Un serveur en 8.1 ou plus ancien ne recevra aucun correctif et doit changer de branche. Un piège revient souvent dans les contrats d’hébergement : la mention « mises à jour incluses » couvre parfois les versions mineures d’une même branche, mais pas la migration vers une branche maintenue, facturée à part. Relisez cette clause.
Pourquoi les audits menés par IA vont révéler d’autres failles
CVE-2026-109618 n’est pas nouvelle. Elle avait été repérée en 2024, lors du premier audit de sécurité externe de PHP depuis plusieurs années, puis laissée sans correctif. Elle est revenue en août, avec des audits menés à l’aide des services d’IA d’Anthropic et d’OpenAI. Un chercheur de la société Calif l’a signalée le 11 août.
La PHP Foundation explique ce retard par la place de ces failles au centre du moteur, sollicité par presque chaque requête. Il fallait les corriger sans casser la compatibilité, sans dégrader les performances et sans imposer de changements aux extensions tierces. Elle cite aussi « l’absence de voie connue vers une exécution de code à distance » et « la petite équipe de développeurs disposant de la connaissance approfondie du moteur, occupés par de nombreuses responsabilités ». Cette situation a fait, dit-elle, « caler et redémarrer à plusieurs reprises, pendant des mois » le travail sur le correctif.
La divulgation a ensuite dérapé. Calif a publié par erreur une vidéo de preuve de concept. Chainguard a diffusé des images corrigées sans l’accord de PHP. Ces deux fuites ont accéléré l’écriture d’outils d’attaque. Dan Lorenc, PDG de Chainguard, salue pourtant le travail des mainteneurs, puis prévient : « Il va y en avoir beaucoup d’autres. »
Nous partageons ce pronostic. Rien n’indique que CVE-2026-115560 ait été trouvée par une IA. En revanche, des outils capables de passer au crible un code ancien en quelques jours vont produire plus d’alertes qu’une poignée de développeurs ne peut en traiter. Pour un site WordPress ou PrestaShop, il faut donc prévoir les mises à jour de PHP comme une tâche régulière, à appliquer dans les jours qui suivent chaque alerte, sur une branche encore maintenue. Si un prestataire gère votre serveur, demandez-lui par écrit son délai d’application des correctifs de sécurité. Demandez-lui aussi s’il a déjà désactivé session.upload_progress.enabled en attendant la version qui corrigera CVE-2026-115560.
