Deux vulnérabilités d’exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, touchent le cœur de PHP. Surnommées PHP2Shell et notées 9,2 en CVSS v4.0, elles permettent à un attaquant non authentifié d’exécuter du code sur un serveur web. L’équipe PHP a publié ses mises à jour d’urgence le 21 octobre 2026 : PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le paquet corrigé de votre distribution. Les versions 8.1 et antérieures ne reçoivent pas de correctif officiel : il faut migrer.
Les identifiants CVE ont circulé le 20 octobre vers 15h UTC, avant la divulgation prévue, ce qui a conduit l’équipe PHP à avancer sa publication. Le 21 octobre, à 14:19 UTC, watchTowr a indiqué observer des tentatives d’exploitation active des deux failles. Aucun bilan chiffré de compromissions n’est disponible à ce stade : il s’agit de tentatives observées, pas d’un décompte de serveurs touchés.
Quelle version de PHP installer, et que faire en 8.1 ou plus ancien
Première étape : relever la branche PHP en production sur chaque serveur. Le correctif dépend de ce seul paramètre.
- Branche 8.5 : passer à 8.5.12.
- Branche 8.4 : passer à 8.4.27.
- Branche 8.3 : passer à 8.3.36.
- Branche 8.2 : passer à 8.2.35.
- Branche 8.1 ou antérieure : aucun correctif officiel, la migration vers une branche récente est la seule protection.
La façon d’obtenir le correctif varie selon le mode d’installation. Si PHP vient des dépôts de votre distribution Linux ou d’un fournisseur de support long terme, ceux-ci ont reçu les patchs en avance : vérifiez le paquet proposé par votre éditeur et le numéro de version réellement installé après mise à jour. La recherche disponible ne détaille pas la disponibilité par distribution, donc consultez l’avis de sécurité de la vôtre plutôt que de supposer que le paquet est déjà publié. Si PHP a été compilé à la main, il faut recompiler depuis l’une des versions amont ci-dessus.
Pour fixer l’ordre : les serveurs accessibles depuis Internet d’abord, puisque l’exploitation observée vise des hôtes joignables. Les machines internes viennent ensuite. Un serveur en 8.1 ou antérieur et exposé cumule les deux facteurs : sa migration passe en tête de liste, en attendant qu’elle aboutisse, la seule parade documentée par les sources est de ne plus l’exposer à Internet.
Pourquoi mettre à jour WordPress, PrestaShop ou Drupal ne protège pas
Les failles se trouvent dans PHP lui-même, pas dans un CMS ni dans ses extensions. Un WordPress, un PrestaShop ou un Drupal parfaitement à jour reste exposé si le PHP du serveur ne l’est pas. Même logique pour une application développée en interne : la correction se fait sur l’interpréteur, au niveau du serveur ou de l’image de conteneur.
Une reproduction indépendante a confirmé que l’authentification applicative ne suffit pas : PHP traite la requête malveillante avant que le moindre code applicatif ne s’exécute. Une page de connexion, un mot de passe fort ou un plugin de sécurité ne se trouvent donc jamais sur le chemin de l’attaque. C’est ce qui justifie la gravité du score de 9,2.
Deux mécanismes, un même résultat : du code exécuté sur le serveur
Sans entrer dans le détail d’exploitation, les deux failles reposent sur des erreurs de gestion mémoire.
CVE-2026-109618 est une exécution de code via une corruption survenant après une erreur de mémoire (OOM). Quand cette erreur interrompt PHP alors que les données internes d’une requête ne sont qu’à moitié initialisées, l’étape de nettoyage traite ensuite ces données invalides comme si elles étaient valides.
CVE-2026-109619 relève d’un état global périmé. Un état interne lié à une requête peut survivre à la libération de la mémoire associée, et une requête ultérieure traitée par le même worker l’exploite avant qu’il ne soit réinitialisé. C’est un use-after-free inter-requêtes, ce qui explique que l’attaque puisse s’appuyer sur ce que le worker a déjà traité.
Ces défauts existaient depuis des décennies, mais leur exploitabilité était difficile à démontrer. Selon les chercheurs de Wiz, des modèles d’IA frontier auraient sensiblement abaissé cette barrière. Cette lecture reste une affirmation attribuée et conditionnelle, que les sources ne permettent pas de présenter comme établie.
Chercher une exposition ou une tentative d’exploitation
Searchlight Cyber a publié php2shell-scanner, un outil open source qui teste si un hôte est exposé aux deux CVE. Nous ne l’avons pas testé : sa fiabilité et ses conditions d’emploi sont à valider par vos soins, de préférence d’abord sur un environnement de préproduction. Le scanner indique l’exposition d’un hôte, il ne dit pas s’il a déjà été visé.
Sur ce second point, les sources disponibles sont limitées. Elles ne détaillent pas d’autres mesures de détection (règles de journaux, indicateurs de compromission, règles WAF), et nous n’en inventons pas. Les journaux de votre serveur web et de vos workers PHP restent un point de départ logique pour repérer des requêtes inhabituelles ou des plantages liés à la mémoire autour du 20 et du 21 octobre, mais aucune signature précise n’est établie à ce jour. Suivez les avis de watchTowr et de Searchlight Cyber, qui ont qualifié l’exploitation.
Ce type d’alerte rappelle d’autres cas où un composant non mis à jour ouvre la porte à l’exploitation, comme les serveurs Plex détournés pour miner des cryptomonnaies faute de mise à jour, et il alimente le flot de rapports que les éditeurs peinent à trier, comme l’a montré la suspension du bug bounty open source de Google.
Par où commencer aujourd’hui
Dressez la liste de vos serveurs avec leur version de PHP, en commençant par ceux exposés à Internet. Installez le correctif de la branche concernée ou le paquet corrigé de votre distribution, vérifiez le numéro de version après redémarrage du service, planifiez la migration pour tout ce qui tourne en 8.1 ou antérieur, puis lancez php2shell-scanner sur vos hôtes pour confirmer qu’aucun n’est resté exposé.