PHP2Shell: la IA destapa 40 años de deuda técnica

PHP2Shell: el bug que puso a media internet en modo mantenimiento

PHP2Shell obligó a cientos de sitios web a salir de línea en octubre de 2026 —entre ellos propiedades de gobiernos de Países Bajos, Canadá, Francia, Alemania, Finlandia, Bélgica y República Checa— y puso en riesgo plataformas como NASA, Wikipedia y la Casa Blanca, según IEEE Spectrum. Lo llamativo no es el ataque: es que el fallo se había reportado a la PHP Foundation ya en 2024 y quedó sin arreglar porque solo provocaba un error de memoria que hacía crashear el programa. Molesto, no peligroso.

Ese es el dato que un founder debería retener. La IA no creó esta vulnerabilidad: convirtió un bug aburrido de hace una década en ejecución remota de código sin autenticación. Y el mismo mecanismo aplica a todo el software heredado que sostiene tu producto.

Qué es PHP2Shell y a quién dejó expuesto

PHP nació en 1994 bajo el nombre de «personal home page» y hoy es la base de gestores de contenido como WordPress y Drupal. Según algunas estimaciones recogidas por TechTarget, corre en el 70% de los sitios de internet, lo que explica la escala del incidente.

¿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 →

Los detalles técnicos, según TechTarget y Hackread:

PHP2Shell agrupa dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, ambas calificadas con 9.2 en CVSS v4.0 por Hackread.
Las dos permiten ejecución remota de código sin autenticación. La primera nace de un error de memoria; la segunda, de punteros que sobreviven a la petición que los creó.
Los parches —PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35— se publicaron el 21 de octubre de 2026. El 23 de octubre PHP divulgó un tercer fallo, CVE-2026-115560, aún sin parche al 27 de octubre.
La configuración de mayor riesgo es Apache mod_php, porque el ataque funciona antes de que el código de la web empiece a ejecutarse.

El impacto operativo fue visible: la Wikimedia Foundation, Internet Archive, BBC, OpenStreetMap y Duolingo restringieron acceso a sus sitios hasta poder parchear, según TechTarget.

Por qué la IA convirtió un bug de 2024 en una emergencia global

En 2024, una auditoría de Quarkslab financiada por la agencia alemana Sovereign Tech Agency ya había detectado indicios del problema de memoria detrás de CVE-2026-109618, pero no encontró una ruta de explotación, según TechTarget. El bug quedó ahí, durmiendo.

El 30 de julio de 2026 arrancó una auditoría de la firma 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 incondicional sobre el mismo problema de memoria. Wiz Research, parte de Google Cloud, encontró y reportó las dos vulnerabilidades por su cuenta. Y OpenAI halló de forma independiente la causa raíz.

La frase que mejor resume el cambio de régimen la dejó Wiz en su divulgación, citada por TechTarget: el código vulnerable llevaba más de una década ahí, y lo que la IA cambió fue la capacidad de entender la debilidad y convertirla 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.

Greg Brockman, presidente de OpenAI, añadió en X que el bug llevó 14 años dentro de PHP, según Mashable. La versión pequeña apareció en 2024 y nadie la tomó en serio; la versión completa llegó en agosto y septiembre de 2026.

Suman Jana, profesor asociado de ciencias de la computación en Columbia University, lo pone en términos más terrenales en IEEE Spectrum: explotar el bug no es ciencia espacial, es mucho razonamiento muy específico y doloroso de hacer, y la IA lo hace muy bien. Su matiz importa: no dice que la IA lo haga sola. Dice que el 0,1% de expertos ahora rinde mucho más, y que quienes están justo por debajo pueden llegar sin dominar todos los detalles finos.

La asimetría que va a definir tu presupuesto de seguridad

Encontrar bugs y arreglarlos no cuesta lo mismo. Jana lo explica así: al arreglar tienes que asegurarte de cerrar todas las partes del ataque y de no romper nada de lo que ya funciona. Esa asimetría castiga al defensor.

Los números de 2026 lo confirman. Wired reportó que Microsoft publicó parches para 974 CVE en un solo mes, un récord; que Oracle envió 1.448 parches en julio frente a 309 en julio de 2025; y que las dos versiones mayores de Chrome de junio incluyeron 1.072 parches, más que las 23 versiones anteriores juntas. El proyecto cve.icu, citado por Wired, registró 66.401 CVE en lo que iba del año, contra 25.000 en todo 2022.

Jerry Gamblin, de Empirical Security, lo resume en Wired con una frase que debería estar pegada en la pared de cualquier CTO: el descubrimiento escala con cómputo, la remediación escala con personas, y personas no se compran en un trimestre.

El cuello de botella no es la detección. Robbie Mueller, de ArmorCode, dijo a TechNewsWorld que la empresa promedio corre más de 40 escáneres de seguridad que producen millones de hallazgos, y que los equipos solo remedian alrededor de 1 de cada 10 vulnerabilidades abiertas al mes. Del otro lado, Microsoft reportó en su blog de seguridad que validar un hallazgo con prueba de concepto le costó en promedio 3,61 dólares en modelos y 21,5 minutos sobre 182 casos confirmados en el kernel de Linux. Detectar es barato; decidir y arreglar, no.

Qué significa esto para tu startup

Si tu producto corre sobre WordPress, Drupal o cualquier stack PHP, ya estuviste en la lista. Pero el aprendizaje es más amplio: la deuda técnica de 40 años que arrastra la industria dejó de ser un problema de mantenimiento y pasó a ser una superficie de ataque activa.

Matt Suiche, líder de investigación de seguridad en IA de la startup Tolmo, lo dice sin rodeos en IEEE Spectrum: todo el software heredado que escribieron humanos en los últimos 40 años está quedando expuesto, y ahora toca pagar la deuda técnica.

La urgencia tiene respaldo en datos. Cloudflare vio miles de exploits en las 10 horas previas al anuncio público y millones en las horas siguientes, según reportó su CEO Matthew Prince, citado por TechTarget. Imperva registró 482.342 peticiones y 122.311 sesiones de ataque contra 21.998 sitios en 103 países en las primeras 24 horas de observación, con el 64,5% de los objetivos en Estados Unidos. Y Censys mostraba 32,4 millones de servicios todavía en una versión afectada de PHP al 26 de octubre.

Cómo proteger tu stack: cuatro acciones concretas

No necesitas un equipo de seguridad de 50 personas. Necesitas cerrar los huecos que la IA de los atacantes ya sabe encontrar.

Haz un inventario real de PHP. No alcanza con mirar tu servidor web: PHP suele venir embebido dentro de otros productos. Revisa el software bill of materials de cada herramienta de terceros y pregunta a cada proveedor si su software incluye PHP y cuándo lo va a parchear.
Parchea y reinicia cada worker. Actualizar WordPress, sus plugins o su tema no reemplaza la instalación de PHP del servidor. Sube a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y reinicia todos los procesos PHP. Si sigues en PHP 8.1 o anterior, estás fuera del periodo de soporte: migra o busca un backport del proveedor.
Usa un WAF como red de seguridad. Cuando no puedes parchear todo de inmediato, un web application firewall a nivel de red reduce el riesgo mientras cierras la brecha. No es un sustituto del parche.
Busca indicios de compromiso hacia atrás. AWS detectó el primer intento de explotación el 17 de octubre, así que tu ventana de revisión debe llegar al menos hasta esa fecha. No te fíes de ocultar los mensajes de error: eso no bloquea la vulnerabilidad de estado obsoleto.

Conclusión

Matthew Green, profesor asociado de Johns Hopkins, es el contrapunto escéptico del artículo de IEEE Spectrum: nadie va a arreglar este problema hasta que pase algo realmente malo, y PHP2Shell no fue lo suficientemente malo. Su pronóstico es que el incidente que sí mueva presupuestos llegue a comienzos de 2027. Su consejo inmediato es más simple: si tu teléfono avisa que hay una actualización de seguridad, no esperes a la semana que viene.

Para un founder, la lectura útil es esta. La IA abarató la detección de vulnerabilidades para todos, atacantes incluidos, y el costo de arreglarlas sigue atado a horas humanas que no escalan. La ventaja competitiva ya no está en tener más escáneres, sino en tener un pipeline que convierta hallazgos en parches desplegados más rápido de lo que el mercado tarda en enterarse del fallo. Empieza por saber qué corre en tu stack, sigue por parchear lo que ya está expuesto y termina por medir cuánto tardas de la divulgación al parche en producción. Ese número, no el conteo de vulnerabilidades, es el que va a importar en 2027.