L'IA a exhumé un bug de 20 ans dans PHP. Il exécute du code sur votre serveur. Patchez aujourd'hui.

Le 21 octobre, le projet PHP a publié quatre versions simultanément — 8.5.12, 8.4.27, 8.3.36 et 8.2.35 — pour corriger deux vulnérabilités critiques notées CVSS 9,2 chacune : CVE-2026-109618 et CVE-2026-109619. Ensemble, elles sont désignées sous le nom de php2shell. L'une ou l'autre permet à un attaquant non authentifié d'exécuter du code sur un serveur qui ne fait rien de plus que servir du PHP. Aucun bug applicatif n'est en cause. Une simple page « Hello World » sur une version vulnérable suffit.

Les deux failles se trouvent dans les parties de PHP que presque chaque requête sollicite : la gestion de la mémoire et la gestion des erreurs. CVE-2026-109618 corrompt la mémoire dans la façon dont PHP effectue le nettoyage après avoir manqué de mémoire au milieu d'une requête. CVE-2026-109619 est un use-after-free, où l'état interne d'une requête persiste dans la requête suivante traitée par le même worker. Wiz Research les a découvertes avec l'aide d'agents IA, les a signalées de manière privée en août, et le correctif est arrivé le 21 octobre dans une version coordonnée avec les distributions et les éditeurs. Wiz indique que toutes les versions de PHP depuis la 5.4 sont affectées, soit environ la dernière décennie du langage. PHP fait tourner une large portion du web, donc le nombre de serveurs exposés est considérable.

Qui est réellement exposé

L'équipe PHP classe Apache avec mod_php comme le risque le plus élevé. Une seule requête non authentifiée peut déclencher l'exploit avant que votre code ne s'exécute, de sorte qu'aucune de vos défenses — middleware d'authentification, validation des entrées, vérifications applicatives — n'a la moindre chance d'intervenir. Une exécution de code à distance complète a été démontrée sur mod_php avec les paramètres par défaut contre des conteneurs WordPress, Drupal et Joomla fraîchement installés.

PHP-FPM n'est pas sûr non plus. L'exécution de code à distance via le bug d'état résiduel a été validée sur FPM, bien que ce chemin nécessite une opération adéquate dans l'application en cours d'exécution pour y parvenir. php-cgi, FrankenPHP et LiteSpeed sont tous concernés. Si un service sert du PHP via HTTP, considérez-le comme vulnérable jusqu'à ce que vous l'ayez patché et redémarré.

Un point pour les équipes mobiles, car l'exposition est facile à manquer : dans nos projets iOS et Android natifs, l'application elle-même est saine, mais elle communique avec une API, et cette API est très souvent en PHP. Un backend non patché expose vos utilisateurs, même si rien ne cloche sur l'appareil. Vérifiez le serveur derrière l'application, pas seulement l'application.

Ce que nous ferions en premier

D'après notre travail PHP et Docker, l'erreur que nous observons sous pression est de patcher la mauvaise chose. Deux étapes comptent plus que toutes les autres.

1. Trouvez chaque instance de PHP que vous exploitez, pas seulement la plus évidente. Il se cache dans les stacks cPanel et Plesk, les appliances fournisseurs, les anciens sites clients que personne n'a touchés depuis deux ans, les images CI et les conteneurs de base. Les recommandations de la CISA sont de faire l'inventaire en premier, car PHP est souvent enfoui dans d'autres logiciels et on ne peut pas patcher ce qu'on n'a pas trouvé.
2. Patchez, puis redémarrez, puis vérifiez la version rapportée par le processus en cours. Un nouveau paquet sur le disque ne fait rien tant que vous n'avez pas remplacé les workers en cours d'exécution. Nous avons vu des équipes « patcher » et rester exploitables pendant des jours parce que PHP-FPM n'avait jamais été réellement redémarré.

Les conteneurs aggravent ce piège. Effectuer une mise à jour dans un conteneur actif n'est pas un correctif, car votre prochain déploiement depuis l'ancienne image ramènera directement la version vulnérable. Reconstruisez sur une image de base patchée, poussez-la et faites tourner les workers. Ensuite, interrogez le serveur et confirmez que la version attendue est bien celle qui répond.

Si vous ne pouvez vraiment pas patcher aujourd'hui

L'équipe PHP est claire : seule la mise à jour constitue un correctif complet, et les paramètres intermédiaires ne font que restreindre des vecteurs d'attaque spécifiques. Ceux qui valent la peine d'être appliqués sont memory_limit=-1 imposé là où l'application ne peut pas le contourner, en utilisant php_admin_value dans votre pool FPM ou la configuration Apache, puis session.upload_progress.enabled=0, et un post_max_size conservateur. Si vous utilisez Cloudflare, la règle WAF gérée pour ces CVE est déjà active, et gagner du temps avec une règle edge pendant que les workers sont patchés est exactement le type de configuration que nous mettons en place lorsque nous configurons Cloudflare pour des clients lors d'un incident. Un bémol : cette règle s'appuie sur le nom de champ upload-progress par défaut, donc si vous avez renommé session.upload_progress.name, elle ne vous protégera pas.

Ce qui devrait vous inquiéter plus que ce seul bug

Voici ce qui m'interpelle dans php2shell. Ces bugs étaient présents dans le code depuis environ vingt ans. Personne ne les avait exploités, car transformer une chaîne de corruption mémoire en exploit fiable sur toutes les versions de PHP, les sets d'extensions et les dispositions de tas était un travail lent, spécialisé, du genre qui prend des mois. Wiz a utilisé des modèles d'IA de pointe pour réaliser cette adaptation, et cela n'a pris que quelques semaines.

Lors de nos missions de pentesting pour des studios de jeux vidéo, la partie difficile était rarement de repérer un chemin de code suspect. C'était de prouver un exploit réel et reproductible avant que quelqu'un accepte de payer pour le corriger. Cette économie a changé. Les attaquants bénéficient du même gain de vitesse, ce qui signifie que l'écart entre la publication d'un correctif et les scans massifs ne cesse de se réduire. Cloudflare a signalé des tentatives de sondage autour de la date de publication, et un proof of concept circule déjà.

Le constat honnête est donc inconfortable : votre cadence de patchage est désormais votre posture de sécurité. Si vous ne pouvez pas trouver et mettre à jour un runtime critique sur l'ensemble de votre infrastructure en une journée, c'est là le véritable écart — et php2shell ne sera pas la dernière chose à le tester.

Si maintenir PHP patché, redémarré et vérifié sur vos environnements de staging, de production et un tas d'anciens sites clients vous parle, parlons-en.