PHP2Shell y Tailworm: el investigador que rechaza la IA

Por qué un investigador de seguridad rechaza los LLMs

El 70% de los sitios web del mundo corre sobre PHP, según las estimaciones que recoge TechTarget, y en octubre de 2026 dos fallos críticos en ese lenguaje —bautizados PHP2Shell— forzaron a cientos de organizaciones a restringir el acceso a sus sitios, incluidos portales de gobierno de Países Bajos, Canadá, Francia y Alemania, y servicios como Wikimedia, Internet Archive y Duolingo. En medio de esa crisis, un investigador de seguridad publicó en su blog personal un ensayo que va a contracorriente: explica por qué nunca usa modelos de lenguaje para su trabajo.

El texto no es un manifiesto anti-tecnología. El autor reconoce que los LLMs "son máquinas poderosas" y que el sector ha mostrado avances reales. Su objeción es de otro orden: no puede firmar como propio un trabajo que hizo una IA, y tampoco puede acreditarla correctamente, "porque no es una persona". Añade que le resulta insoportable ver a un modelo equivocarse con total seguridad mientras ejecuta comandos que considera absurdos.

Para un founder, el interés no está en la anécdota personal sino en el criterio. El ensayo es una lista de casos concretos donde el marketing de la IA chocó con la realidad de la ingeniería: PHP2Shell, el caso Tailscale y la ola de pruebas de concepto publicadas antes de que existieran parches. Vale la pena revisarlos uno por uno, porque los hechos verificables son más matizados que el titular de cualquier bando.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

PHP2Shell: el caso que usa como evidencia

El autor apunta a PHP2Shell como ejemplo de cómo las empresas de IA convirtieron la ciberseguridad en su canal de marketing. Tres organizaciones —Calif, OpenAI y Wiz— publicaron cada una su propio análisis, con narrativas distintas: Calif sostuvo que una IA encontró los fallos con un humano guiándola, OpenAI que el agente descubrió vulnerabilidades críticas, y Wiz tomó un punto intermedio. El ingeniero de seguridad de la fundación PHP, Volker Duse, lo calificó como el problema más serio que ha enfrentado la tecnología en más de una década, comparable a Heartbleed, según recogió BGNES.

Los hechos del caso, según la cronología que publicó TechTarget, son estos: en 2024 una auditoría financiada por la agencia alemana Sovereign Tech Agency y ejecutada por Quarkslab detectó indicios tempranos del problema de memoria detrás de CVE-2026-109618, pero no encontró una ruta de explotación. El 30 de julio de 2026 arrancó una auditoría de Calif dentro del programa Patch the Planet de OpenAI. El 11 de agosto, el investigador de Calif Ryan Austin reportó una ejecución remota de código sin condiciones. El 19 de agosto, Wiz Research encontró por su cuenta otra vulnerabilidad no autenticada usando su herramienta Atlas junto con los modelos Gemini 4 Argon y GPT-5.6 Sol. El 21 de octubre, la PHP Foundation publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

La declaración de Wiz es el mejor contrapeso al escepticismo del autor: "El código vulnerable llevaba ahí más de una década; lo que cambió la IA fue la capacidad de entender las debilidades y convertirlas en un exploit funcional. Con modelos frontera y las herramientas adecuadas, un solo investigador completó en una semana lo que antes le habría tomado meses a un equipo de primer nivel".

Eso no contradice al autor: confirma su punto de que los LLMs necesitan guía. Un investigador con experiencia dirigió el modelo. Lo que sí complica su tesis es la escala: cuando una sola persona comprime meses de trabajo, la afirmación de que la IA está sobrevendida se vuelve difícil de sostener sin matices.

Donde el autor tiene un argumento verificable es en el parcheo. Pentest Partners señala que, para las ramas de PHP fuera de soporte (5.4 a 8.1), no existe corrección para CVE-2026-109618. El autor sostiene que OpenAI, con el cómputo que tiene, podría haber retroportado las correcciones a esas versiones. Es una crítica de prioridades, no de capacidad, y los datos de exposición la respaldan: Censys registraba 32.473.855 servicios que seguían usando una versión afectada de PHP a las 15:15 UTC del 26 de octubre.

Tailworm: cuando la divulgación se convierte en campaña

El segundo caso que cita el autor es el de Tailscale. Según su relato, un investigador de seguridad publicó en Bluesky un hash con la leyenda "tailscale privilege escalation", fue soltando información críptica en un hilo y, al día siguiente, su empresa —de una sola persona— publicó un sitio web con todos los hallazgos. La vulnerabilidad real exigía que ya tuvieras reglas de ACL hacia una máquina y que Tailscale SSH estuviera habilitado; permitía escalar a root en esa máquina concreta. Según el autor, nunca se contactó a Tailscale antes de publicar.

SecurityWeek confirma el episodio: el informe Tailworm, de Cyberdione Labs, lista 11 hallazgos que afectan al cliente de Tailscale 1.104.2 y a headscale 0.29.5. Seis están calificados como de severidad alta y cuatro afectan a Tailscale SSH. El informe se publicó antes de que existieran parches, lo que generó críticas, aunque los investigadores argumentaron que la difusión rápida aceleraría la remediación. Mike Shaver, VP de Ingeniería de Tailscale, respondió en Reddit que la compañía ya investigaba por su cuenta y que la mayoría de los problemas se refieren a lo que ocurre después de que alguien fue autorizado a conectarse.

El punto del autor es sobre incentivos, no sobre gravedad técnica: publicar un hash con el nombre del producto al lado no es divulgación responsable, es una campaña de posicionamiento. La recomendación oficial de Tailscale mientras llegaban los parches —revisar las políticas de acceso SSH y desactivar el reenvío donde no fuera necesario— es, en la práctica, la única mitigación disponible para los equipos afectados.

¿Puede una IA encontrar vulnerabilidades sin ayuda humana?

El autor lo duda: si lanzas un LLM contra el kernel de Linux y le pides encontrar una RCE sin ninguna guía, probablemente no lo logre. Las vulnerabilidades que generaron titulares fueron halladas por investigadores con experiencia usando LLMs, en muchos casos dentro de empresas grandes con acceso a mucho cómputo. La cronología de PHP2Shell respalda esa lectura: hubo un humano reportando, un humano confirmando y una fundación coordinando.

Su ejemplo favorito va en la dirección opuesta a la narrativa dominante: el caso de eMudhra, donde la clave privada de la autoridad de certificación era, según su relato, un valor trivial. No lo encontró una IA, sino una persona que escaneaba claves por curiosidad con paranoid_crypto, una librería de Google. Para el autor, ahí está lo que se pierde cuando se delega todo: la curiosidad sin objetivo que igual encuentra algo.

Qué significa esto para tu startup

Si tu producto corre sobre PHP, la discusión sobre IA es secundaria: hay trabajo pendiente.

Actualiza ya. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si estás en una rama fuera de soporte (5.4 a 8.1), no hay parche para CVE-2026-109618 y la migración debería ser prioridad, según Pentest Partners.
Busca PHP donde no lo ves. Suele venir embebido en CMS, plugins y productos de terceros. Revisa tu inventario y tu SBOM, e incluye entornos de desarrollo y staging: no están desconectados de producción.
Revisa tus políticas de Tailscale SSH. Desactivar el reenvío SSH donde no lo necesitas mitiga varios de los hallazgos más serios, según la recomendación de la propia Tailscale.
Verifica antes de publicar. El argumento del autor sobre modelos equivocados con seguridad aplica a tu equipo: si usas IA para generar código o análisis de seguridad, el resultado se revisa con el mismo rigor que el de un junior. Y si encuentras un fallo en un tercero, avisa antes de publicar.

Conclusión

El ensayo no es un alegato contra la IA, sino una defensa de la trazabilidad. El autor no discute que los modelos sean potentes: discute que se les atribuya un trabajo que no pueden firmar y que se use la ciberseguridad como escaparate. Los hechos de PHP2Shell muestran que ambas cosas son ciertas a la vez: la IA aceleró un hallazgo real y, en el camino, el relato se infló.

Para un founder, la lección práctica es doble. Primero, la velocidad que la IA aporta al descubrimiento de vulnerabilidades también la aporta a la explotación: Cloudflare reportó miles de intentos de explotación en las 10 horas previas al anuncio de PHP2Shell y millones en las horas siguientes, según TechTarget. Segundo, la única defensa que escala es la aburrida: inventario actualizado, parcheo rápido y políticas de acceso revisadas.