Le 21 octobre 2026, l’équipe de sécurité de PHP a publié en urgence les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 pour combler deux failles, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur l’échelle CVSS v4.0. Elles permettent d’exécuter du code à distance sans être authentifié, et Cloudflare a déjà observé du trafic d’attaque, selon IT-Connect. Le CERT-FR a relayé l’alerte le jour même, rapporte Le Monde Informatique.
Que permettent ces deux failles ?
La première, CVE-2026-109618, survient lorsqu’un manque de mémoire interrompt PHP alors que des données de la requête ne sont que partiellement préparées : la phase de nettoyage les traite ensuite comme si elles étaient valides. La seconde, CVE-2026-109619, est une utilisation de mémoire déjà libérée : après une erreur fatale, la requête suivante traitée par le même processus peut réutiliser ces références. D’après IT-Connect, la fonction Session Upload Progress, active par défaut, constitue un chemin d’attaque confirmé.
Concrètement, selon Le Monde Informatique, l’exploitation pourrait mener à l’installation de logiciels malveillants ou à des rebonds vers d’autres ressources du réseau. Les modes d’exécution concernés sont nombreux : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L’équipe PHP juge mod_php le plus exposé, car une requête anonyme peut déclencher l’attaque avant même que le code de l’application ne s’exécute.
Une divulgation qui a échappé au calendrier
Le 20 octobre, l’équipe PHP avait publié sur php.net un avis inhabituel annonçant une mise à jour pour le lendemain à 14 h UTC et invitant tous les utilisateurs à « se préparer dès maintenant », raconte IT-Connect. Entre-temps, un message sur Hacker News, depuis supprimé, avait déjà décrit deux failles d’exécution de code à distance remontant jusqu’à PHP 5. La société watchTowr a confirmé leur existence et reproduit l’une d’elles sans en publier le détail.
Les failles ont été signalées par Calif, OpenAI et Wiz, avec l’aide de modèles d’IA. Selon IT-Connect, le défaut sous-jacent avait été repéré dès 2024 lors d’un audit de Quarkslab, sans être corrigé, ce que la PHP Foundation a reconnu comme un échec structurel. Wiz dit avoir obtenu une exécution de code non authentifiée sur WordPress, Drupal et Joomla, ainsi qu’une fuite de mémoire susceptible d’exposer mots de passe ou clés d’API. Cloudflare signale des charges modifiées qui contournent ses règles de pare-feu applicatif.
Qui doit agir, et comment ?
Pour les branches 8.2 à 8.5, la réponse est simple : installer la version corrigée. La situation est plus délicate pour les sites restés sur PHP 8.1 ou antérieur, branches que l’équipe PHP ne maintient plus. Elle a publié des correctifs sources minimaux pour 7.4, 8.0 et 8.1, à compiler soi-même ; au-delà, il faut migrer, passer par un éditeur proposant un support étendu ou bloquer en amont les requêtes multipart. Sur Debian et Ubuntu, les dépôts d’Ondřej Surý couvrent toutes les branches de 5.6 à 8.5, mais gardent les numéros de version d’origine : c’est la révision du paquet qu’il faut vérifier, précise IT-Connect.
- En attendant le correctif : désactiver session.upload_progress.enabled, réduire post_max_size et redémarrer tous les processus PHP.
- Bloquer les requêtes dont le type de contenu est multipart, par un pare-feu applicatif ou un proxy inverse.
- Identifier les équipements concernés, comme le recommande le CERT-FR cité par Le Monde Informatique.
Ces parades ne couvrent que les chemins liés aux sessions et ne remplacent pas la mise à jour. Le NCSC britannique conseille même, selon IT-Connect, de déconnecter les systèmes qui ne peuvent pas être corrigés. Le Monde Informatique rapporte que certains sites exposés, dont des sites de préfectures, auraient suspendu leur accès en ligne par précaution.
Ce que l’épisode révèle
PHP fait tourner une large part du web, des sites vitrines de PME aux portails publics. L’épisode illustre l’écart, souligné par Le Monde Informatique, entre la vitesse à laquelle l’IA aide à découvrir des failles et la capacité des organisations à les corriger. Il rappelle aussi le risque des versions en fin de vie : PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026, selon IT-Connect. Les hébergeurs mutualisés, qui gèrent eux-mêmes la version de PHP, sont en première ligne ; leurs clients ont intérêt à vérifier rapidement la version réellement servie.
Questions fréquentes
Mon site WordPress est-il concerné ?
Oui s’il tourne sur une version de PHP non corrigée : Wiz a démontré l’exploitation sur WordPress, Drupal et Joomla. Il faut vérifier la version de PHP utilisée par l’hébergement, pas seulement celle du CMS.
Quelles versions de PHP sont sûres ?
PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, publiées le 21 octobre 2026. Sur Debian ou Ubuntu via les dépôts Surý, il faut contrôler la révision du paquet.
Les failles sont-elles déjà exploitées ?
Selon IT-Connect, Cloudflare a observé du trafic d’attaque visant ses clients. Le Monde Informatique, lui, parle surtout d’un risque ; mieux vaut considérer l’exploitation comme probable.
Sources
- PHP2Shell : les correctifs de sécurité sont là, les attaques aussi ! — IT-Connect, 2026-10-21
- PHP : deux failles critiques ont fuité avant l'heure, un correctif d'urgence arrive ce 21 octobre ! — IT-Connect, 2026-10-21
- Deux failles critiques dans PHP : les entreprises sous pression — Le Monde Informatique, 2026-10-22