Le 21 octobre 2026, Elias Taylor a publié une analyse d'une vulnérabilité PHP récemment discutée. Il reconnaît l'existence du bug et son importance, mais estime que son exploitation est bien plus difficile que celle de Log4Shell, de Heartbleed ou du décodage YAML de Ruby on Rails.

Taylor affirme que GitHub contient déjà des milliers de PoC présumés. D'après ses tests, ces exemples ne fonctionnent pas contre une installation PHP standard. Il conseille de lancer soi-même un serveur PHP intact dans Docker et d'exécuter les scripts, plutôt que de faire confiance à la sortie d'un LLM.

L'article cite david-alvarez-rosa/php-rce, eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC et ikow/php2shell-poc. Taylor observe que la plupart de ces démonstrations utilisent une LFI, ou inclusion de fichier locale. Leur chaîne d'attaque suppose une autre faille du serveur qui permettrait en pratique une opération comparable à eval(read(filename_provided_by_user)). Une configuration de laboratoire dépend en outre d'une faiblesse préexistante donnant accès à `/etc/password`. Pour Taylor, cette condition préalable ne prouve pas que PHP lui-même soit exposé à une exploitation grave.

Taylor explique la multiplication de ces PoC défaillants par le transfert des décisions techniques vers Claude, GPT et des systèmes comparables. Beaucoup d'utilisateurs pensaient qu'un LLM pourrait construire immédiatement une chaîne UAF complète à partir du patch. Les tests générés auraient parfois ajouté une vulnérabilité sévère au serveur censé être vérifié. Taylor décrit ce phénomène comme des « Decision Schelling Points », des méthodes qui deviennent omniprésentes parce qu'un modèle les choisit par défaut.

L'auteur compare ce cas à des vulnérabilités plus anciennes dont le déclenchement était direct. Le décodage YAML de Ruby on Rails pouvait être provoqué par un corps de requête malveillant. Log4Shell reposait sur une valeur User-Agent préparée. Shellshock exploitait une variable d'environnement spécialement formée. Heartbleed pouvait être interrogé avec une valeur Content-Length démesurée. Selon Taylor, des botnets exploitaient ces failles peu après leur médiatisation, avant l'arrivée des LLM.

Taylor attribue la peur actuelle à l'avertissement d'un membre de l'équipe PHP, qui prédisait l'apparition d'exploits 15 minutes après le correctif. Il cite également la mauvaise réputation générale de PHP en matière de sécurité et une vidéo d'exploitation mettant en scène un personnage d'anime. Beaucoup s'attendaient enfin à ce que les LLM accélèrent les attaques, potentiellement après que jusqu'à 100 000 personnes leur ont demandé d'analyser le problème. Sa conclusion est que cette vulnérabilité ne constituait pas, au moment de la publication, un incident facile à exploiter du niveau de Log4j.