PHP2Shell: des failles critiques de PHP frappent le plus durement les serveurs mod_php

PHP a avancé la publication de sa mise à jour de sécurité au mercredi 21 octobre à 14 h UTC, après la fuite de détails sur deux failles sur Hacker News la veille. Les correctifs sont intégrés à PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les deux bugs se trouvent dans l’interpréteur lui-même, et non dans un CMS. Les avis de sécurité de PHP concernant CVE-2026-109618 et CVE-2026-109619 attribuent à chacune un score de 9,2 selon CVSS 4.0 et confirment une exécution de code à distance sans authentification, avec les privilèges du processus de traitement web.

La gestion des erreurs de mémoire insuffisante laisse la mémoire partiellement initialisée

La première faille tient à la manière dont PHP gère les erreurs de mémoire insuffisante. En cas d’épuisement de la mémoire (OOM), l’interpréteur utilise longjmp() pour quitter le contexte courant, même lorsque la mémoire de la requête n’est alors que partiellement initialisée. La procédure de fermeture lit ensuite cet état comme s’il était valide. Un attaquant peut provoquer cet épuisement avec une requête multipart qui reste sous la limite post_max_size, par exemple grâce à un nombre illimité d’en-têtes par partie, à des champs de fichier vides qui ne sont pas comptabilisés dans max_file_uploads, ou à des noms de champs imbriqués. Le correctif remplace longjmp() par une gestion non brutale de l’OOM au prochain point sûr de la machine virtuelle, et par un arrêt brutal via _exit() au-delà d’un second seuil, plus élevé.

La deuxième faille concerne un état global qui persiste au-delà d’une requête. Si une erreur fatale interrompt une opération avant qu’elle ne réinitialise son état, un champ global continue de pointer vers une zone de mémoire du tas déjà libérée. Lorsque la requête suivante sur le même processus de traitement lit cette valeur avant l’initialisation normale, il en résulte une utilisation après libération. PHP répertorie deux voies confirmées : le paramètre fatal_error_backtraces dans PHP 8.5 et le suivi de progression des téléversements par session, qui est activé par défaut et ne nécessite pas que l’application appelle session_start().

Pourquoi mod_php est le plus exposé

Apache avec mod_php appelle la procédure de fermeture de la requête même lorsque le démarrage de celle-ci a déjà échoué. Il suffit que la mémoire s’épuise pendant que PHP analyse le corps de la requête, sans qu’aucun code applicatif ait à s’exécuter. PHP a validé une exécution de code complète contre mod_php avec les limites de mémoire et d’entrée par défaut. PHP-FPM termine tout processus enfant dont le démarrage échoue, ce qui bloque la voie directe. Pour la deuxième faille, PHP a néanmoins confirmé un exploit contre un pool FPM standard, bien qu’il dépende d’une opération appropriée dans l’application. L’analyse du code source suggère que FrankenPHP se comporte comme mod_php, tandis que LSAPI pourrait être concerné sous certaines conditions. La complexité d’attaque élevée dans le vecteur CVSS reflète le fait que la compilation de PHP et l’agencement du tas influent sur la fiabilité.

Les tentatives d’exploitation et le rôle de l’IA

watchTowr indique observer des tentatives actives d’exploitation des deux failles, et Cloudflare a déclaré à The Hacker News avoir détecté de premières attaques avant la publication du correctif. Aucune compromission réussie n’a été confirmée jusqu’à présent. Des services publics néerlandais, dont DigiD et MijnOverheid, ont néanmoins été mis hors ligne par précaution, et le NCSC britannique conseille de déconnecter les systèmes non corrigés si aucune autre option n’est disponible.

Wiz Research a découvert les bugs et les a signalés le 24 août. Selon Wiz, Gemini 4 Argon et GPT-5.6 Sol ont contribué à la découverte, au développement des exploits et à la validation des correctifs, notamment pour adapter l’exploit à chaque cible. Wiz remercie également OpenAI et Calif pour leur aide à la découverte et à la coordination. Cela rejoint ce qu’Anthropic a récemment écrit au sujet d’une IA capable de se copier elle-même ciblant des boîtiers TV bon marché, où les modèles facilitent également les attaques.

Ce que les administrateurs doivent faire dès maintenant

La mise à jour est la seule solution complète. Les distributions Linux et les fournisseurs de versions LTS ont reçu les correctifs à l’avance et les rétroportent souvent sous d’anciens numéros de version : vérifiez donc la présence des identifiants CVE dans le journal des modifications plutôt que de vous fier au numéro de version. Les branches 7.4, 8.0 et 8.1, qui ne sont plus prises en charge, ne reçoivent que des rétroportages minimaux du code source. Si vous ne pouvez pas effectuer la mise à jour immédiatement, PHP recommande de définir memory_limit=-1 au niveau de l’administration, car c’est une limite prévisible par requête qui permet à l’exploit OOM confirmé de fonctionner. Ajoutez session.upload_progress.enabled=0 et, sous PHP 8.5, fatal_error_backtraces=0, puis redémarrez tous les processus de traitement. Si votre application n’utilise pas de formulaires multipart, bloquez-les au niveau du frontal. Aucun de ces paramètres ne constitue une solution complète. Sur un hébergement mutualisé ou un NAS doté d’un serveur web, vérifiez quelle version de PHP votre fournisseur propose.