PHP2Shell : deux RCE critiques touchent PHP depuis la version 5.4 et forcent un patch immédiat

20 octobre 2026, 15 h UTC. Deux identifiants CVE commencent à circuler sur les forums, avec un score CVSS erroné de 10,0 et une fausse date de correctif. 21 octobre 2026, 3 h 02 UTC. Cloudflare active par défaut des règles WAF contre l’exploitation, environ neuf heures avant la divulgation officielle. 21 octobre 2026, 14 h UTC. Le projet PHP publie 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. Pourquoi c’est important : ces deux failles d’exécution de code à distance non authentifiée vivent dans le moteur PHP lui-même depuis la version 5.4 — corriger WordPress ou vos plugins ne suffit pas, il faut patcher l’interpréteur.

Deux failles dans le cœur du moteur, pas dans vos applications

La particularité de PHP2Shell tient à sa localisation. Les deux vulnérabilités ne touchent pas une application, un framework ou un plugin : elles résident dans la gestion de la mémoire et le traitement des erreurs fatales du moteur PHP, des chemins que presque chaque requête emprunte.

CVE-2026-109618 est une corruption par dépassement mémoire. Si une requête atteint la memory_limit de PHP au mauvais moment, l’interpréteur interrompt son travail avant d’avoir correctement initialisé certaines structures internes, puis les réutilise pendant le nettoyage comme si elles étaient valides. Sur Apache avec mod_php, une requête non authentifiée peut déclencher cette condition avant même qu’un code applicatif ne s’exécute — Wiz a démontré une RCE complète avec la configuration par défaut. Le vecteur a aussi été confirmé sur PHP-FPM par des chemins applicatifs.

CVE-2026-109619 est une RCE par état périmé. Une erreur fatale survenant au mauvais moment laisse des références internes pointer vers une mémoire déjà libérée, appartenant à une requête précédente. Un worker qui traite une requête ultérieure peut alors suivre ces références et accéder à de la mémoire libérée — un use-after-free confirmé, avec crash de worker et exécution de code démontrée contre une application réelle tournant sur Apache mod_php.

Les chercheurs de Wiz ont assemblé ces primitives dans un unique script d’exploitation, php2shell, et démontré une RCE pré-authentification sur des déploiements à jour de WordPress, Drupal et Joomla (wordpress:latest, drupal:latest, joomla:latest). Séparément, ils ont prouvé qu’un attaquant pouvait lire la mémoire du processus PHP — mots de passe, jetons, clés API — sans même parvenir à exécuter du code.

Une portée historique : 70 % du web

PHP motorise environ 70 % des sites web, selon les mesures de W3Techs citées par Cloudflare. Il est le socle de WordPress, Drupal, MediaWiki (le logiciel de Wikipédia) et de la plupart des CMS hébergés. Une faille dans le cœur du moteur se propage donc à l’ensemble de cet écosystème, y compris quand le code applicatif est irréprochable.

Wiz établit un parallèle assumé avec Heartbleed (2014) et Log4Shell (2021) : des vulnérabilités qui ont remis en cause une hypothèse fondamentale sur une infrastructure partagée. Le score officiel est 9,2 sur l’échelle CVSS v4.0 — critique, mais en deçà du 10,0 qui avait fuité le 20 octobre.

Une divulgation coordonnée, puis une rupture d’embargo

La chronologie mérite d’être connue, parce qu’elle explique pourquoi il faut agir maintenant et non « dans quelques jours ».

• Août 2026. Calif (le 11, par le chercheur Ryan A), OpenAI (le même jour), puis Wiz (le 24) signalent les failles à l’équipe sécurité de PHP. Quarkslab avait repéré dès 2024, lors du premier audit externe financé par la Sovereign Tech Agency, les premiers signes du problème d’OOM.
• 20 octobre 2026, 15 h UTC. Les deux CVE fuient sur les forums, avec un score et une date faux. Aucun détail technique ne circule encore.
• 20 octobre 2026, 19 h 30 UTC. PHP publie une pré-annonce et avance la sortie du correctif du 22 au 21 octobre, 14 h UTC.
• 21 octobre 2026, 3 h 02 UTC. Cloudflare active ses règles WAF par défaut, y compris pour les comptes gratuits, s’appuyant sur une nouvelle capacité de détection de transaction complète qui croise la requête et la réponse d’origine.
• 21 octobre 2026, 7 h 41 UTC. Chainguard rompt unilatéralement l’embargo en publiant des images contenant déjà le correctif — six heures avant l’heure prévue, laissant tout attaquant étudier le patch en binaire pendant que le reste du monde attendait.

Le résultat net : des PoC ont circulé et été accélérés par la fuite d’une vidéo publiée par erreur par Calif vers 20 h UTC le 20 octobre. L’équipe sécurité de PHP indique n’avoir identifié aucun exploit fonctionnel au moment de la divulgation, mais la fenêtre entre « fuite » et « correctif » est exactement celle où les défenses temporaires — un WAF — comptent.

L’IA a rendu l’exploit praticable

L’angle le moins intuitif de PHP2Shell est le rôle des modèles de frontière. Les bugs de mémoire sous-jacents étaient présents depuis plus de dix ans, mais les transformer en exploit exigeait d’enchaîner plusieurs primitives et d’adapter chaque cible à sa propre disposition mémoire — un travail manuel long, réservé à quelques spécialistes.

Wiz indique avoir utilisé Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol tout au long de la recherche, et crédite Gemini 4 Argon d’une contribution « inestimable » à la découverte, au développement de l’exploit et à la validation du correctif. La conclusion est sans détour : les modèles de frontière abaissent la barrière qui séparait une faille théorique d’une faille exploitable, en réduisant à quelques heures le travail d’adaptation d’un exploit à une nouvelle cible. C’est un changement d’économie, pas seulement un progrès technique.

Ce qu’il faut faire

La consigne est simple, et elle ne se délègue pas à un plugin.

1. Mettez à jour PHP vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 — ou la version corrigée fournie par votre distribution. Les séries 8.1 et antérieures ont atteint leur fin de vie et ne recevront pas de correctif : elles doivent être migrées.
2. Distributions et hébergeurs. Si un hébergeur gère PHP pour vous, exigez qu’il applique la mise à jour — Ubuntu, Debian et les LTS des éditeurs ont publié leurs paquets.
3. Gardez le WAF actif pendant le patch. Les règles Cloudflare, AWS, Fastly, Imperva ou équivalentes sont un defense-in-depth, pas un substitut au correctif.
4. Réduisez la surface en attendant : limitez les tailles d’upload et désactivez les uploads inutiles — ces mesures réduisent l’exposition sans remplacer le patch.

Vérifiez vos versions avec php -v et, si vous gérez des conteneurs, reconstruisez vos images : l’image de base contient souvent la version vulnérable figée.

php -v
# Si la version est antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, mettez à jour.

Verdict

Si vous exposez PHP sur Internet, patch aujourd’hui, pas cette semaine. Les deux failles touchent le moteur, pas une application : la seule frontière qui compte est la version de l’interpréteur. Si vous êtes derrière un WAF géré, considérez-le comme un amortisseur qui vous fait gagner quelques heures de répit, pas comme une solution — la fuite du 20 octobre et la rupture d’embargo de Chainguard ont déjà mis le patch en binaire dans les mains des attaquants. Et pour les équipes qui croyaient qu’une faille de dix ans sans exploit public resterait théorique : PHP2Shell est la preuve que l’IA a déplacé cette frontière.

Références

• PHP Foundation — Today’s PHP Security Release
• Wiz — PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
• Cloudflare — Cloudflare deploys protections against php2shell vulnerability
• Phoronix — PHP Updates Released For Two Critical Code Execution Vulnerabilities
• PHP.net — annonces de sécurité du 21 octobre 2026