El 21 de octubre de 2026, Elias Taylor publicó un análisis sobre una vulnerabilidad de PHP recientemente discutida. No niega que exista un fallo ni que sea importante. Su argumento es que explotarlo resulta mucho más difícil que aprovechar Log4Shell, Heartbleed o la decodificación YAML de Ruby on Rails.

Taylor afirma que GitHub ya reúne miles de PoC supuestos. Según sus pruebas, esos ejemplos no funcionan contra una instalación de PHP sin modificar. Recomienda levantar un servidor intacto en Docker y ejecutar personalmente cada script, en lugar de confiar en los resultados generados por un LLM.

El artículo menciona david-alvarez-rosa/php-rce, eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC e ikow/php2shell-poc. Taylor señala que la mayoría de estas demostraciones dependen de LFI, o Local File Inclusion. La cadena de ataque necesita otro fallo en el servidor que, en la práctica, permita algo parecido a eval(read(filename_provided_by_user)). Una configuración de laboratorio requiere además una vulnerabilidad previa que permita acceder a `/etc/password`. Para Taylor, esa condición no demuestra un exploit grave contra PHP.

Taylor atribuye la proliferación de PoC que no funcionan a la delegación de decisiones técnicas en Claude, GPT y sistemas similares. Muchos usuarios esperaban que un LLM construyera de inmediato una cadena completa de explotación UAF a partir del parche. En algunos casos, las pruebas generadas habrían introducido una vulnerabilidad grave en el servidor que pretendían examinar. Taylor describe esta repetición como «Decision Schelling Points», porque un método se vuelve dominante cuando el modelo lo elige por defecto.

El autor compara este episodio con vulnerabilidades antiguas que tenían rutas de ataque directas. La decodificación YAML de Ruby on Rails podía activarse con un cuerpo de petición malicioso. Log4Shell usaba un valor User-Agent preparado. Shellshock aprovechaba una variable de entorno especialmente formada. Heartbleed podía consultarse con un valor Content-Length demasiado grande. Taylor afirma que los botnets empezaron a explotar esos fallos poco después de que se hicieran públicos, antes de la llegada de los LLM.

Taylor atribuye el temor actual a la advertencia de un miembro del equipo central de PHP, que predijo exploits 15 minutos después de la publicación del parche. La desconfianza general hacia la seguridad de PHP y un vídeo de explotación protagonizado por un personaje de anime se suman a esa advertencia. Muchos esperaban que los LLM aceleraran los ataques, posiblemente después de que hasta 100.000 personas les pidieran investigar el problema. Su conclusión es que, en el momento de la publicación, no se trataba de un incidente fácil de explotar comparable a Log4j.