PHP2Shell: el bug de PHP que afecta al 70% de la web

Qué pasó con PHP2Shell y por qué la web se frenó en seco

Esta semana, millones de administradores de sitios web recibieron una instrucción poco habitual: parchear de inmediato o, si no podían hacerlo, apagar el sitio. El motivo fueron dos vulnerabilidades críticas en PHP, el lenguaje de programación de código abierto que sostiene buena parte de la web.

Según el reporte de Yahoo Tech, los bugs se conocen colectivamente como PHP2Shell y están registrados como CVE-2026-109618 y CVE-2026-109619. De acuerdo con Hoodline, que cita el aviso de CERT-EU, ambos tienen una puntuación de severidad CVSS de 9,2 sobre 10 y permiten ejecución remota de código sin autenticación: un atacante puede entrar a un servidor sin contraseña y ejecutar código propio.

La PHP Foundation publicó parches el miércoles para las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Bancos, retailers, hospitales, sitios de gaming y algunas agencias de gobierno apagaron sus servidores para aplicar la corrección, según el mismo reporte.

¿Por qué una falla de hace 14 años se volvió crítica ahora?

El detalle que más incomoda: el bug no es nuevo. Según Greg Brockman, presidente de OpenAI, el problema estuvo presente en el código durante 14 años. Los investigadores de seguridad lo habían detectado parcialmente en 2024, pero en ese momento no lo consideraron explotable y no se parcheó.

Lo que cambió fue la capacidad de demostrar que sí se podía explotar. Y ahí entra la IA.

¿Quién encontró las vulnerabilidades: humanos o modelos de IA?

Los investigadores de la firma Calif encontraron los bugs durante una auditoría del código de PHP, en el marco de la iniciativa Hack the Planet de OpenAI y Wiz. En su propio informe, Calif aclaró que la IA ayudó a explotar el bug, pero que el grueso del trabajo se apoyó en conocimiento que los investigadores ya tenían: conocían la base de código de PHP y su historial de explotación. «Ningún modelo es simplemente capaz de desenterrar todos los bugs con prompts simples. Al menos por ahora», escribieron.

Es un matiz importante para founders que evalúan herramientas de seguridad con IA: la tecnología acelera, pero no reemplaza el criterio humano. El propio podcast de TechCrunch que originó esta nota tuvo que corregir en vivo la idea de que los modelos habían encontrado las fallas solos.

OpenAI describió su iniciativa como Patch the Planet, que combina herramientas de IA con supervisión humana. Según la compañía, ingenieros de seguridad revisaron cada hallazgo antes de que llegara a un mantenedor, y el equipo de Trail of Bits trabajó con Codex y GPT-5.5-Cyber en 19 proyectos de código abierto.

Los números: ¿qué tan grande es la exposición?

• W3Techs reporta que PHP se usa en el 69,3% de todos los sitios web cuyo lenguaje de programación del lado del servidor es conocido, según sus datos de octubre de 2026.
• Censys identificó 6.292.667 hosts y 115.000.393 propiedades web que coincidían con sus consultas de exposición a PHP al miércoles.
• Wiz estimó el impacto en aproximadamente el 70% de internet, aunque la BBC dijo que no pudo verificar ese número de forma independiente.
• La NSA afirma que alrededor del 75% de las vulnerabilidades explotadas activamente abusan de fallas relacionadas con la memoria.

PHP no está solo en servidores web: también aparece en herramientas de desarrollo, paquetes de terminal y componentes de routers, dispositivos de almacenamiento y equipos de seguridad empresarial como firewalls y VPN.

¿Ya hubo ataques? Esto es lo que reportan las firmas de seguridad

Las versiones difieren, y eso es parte de la historia.

Amazon dijo en un blog que detectó explotación de PHP2Shell aproximadamente una semana antes de que los parches estuvieran disponibles, y recomendó a los defensores buscar evidencia de explotación desde el 17 de octubre. La PHP Foundation culpó a una empresa por publicar los parches horas antes de que terminara el embargo.

Cloudflare reportó un número exponencial de intentos de explotación tras la divulgación; su CEO, Matthew Prince, habló de millones de intentos contra PHP2Shell. Su CTO, Dane Knecht, dijo que la compañía está viendo ataques tempranos y actualizando sus mitigaciones.

Palo Alto Networks (Unit 42) observó código de explotación de prueba de concepto y reportó que al menos un gobierno europeo sacó su sitio de línea como precaución. Trail of Bits confirmó compromisos y actividad posterior a la explotación. La firma watchTowr dijo haber reproducido ambas vulnerabilidades.

En contraste, CISA señaló que no había observado explotación al momento de publicar su aviso. Es decir: el panorama no es de colapso masivo confirmado, pero tampoco de calma.

¿Qué significa esto para tu startup?

1. Averigua si dependes de PHP sin saberlo

Muchos founders no saben qué corre debajo de su sitio. Si usas WordPress, Drupal, Joomla o MediaWiki, hay PHP en el stack. Pide a tu equipo técnico o a tu proveedor de hosting la versión exacta y verifica si está dentro de las ramas parcheadas (8.5.12, 8.4.27, 8.3.36, 8.2.35).

2. Prioriza la actualización sobre el parche cosmético

CERT-EU advierte que PHP 8.1 y las ramas anteriores están al final de su vida útil y ya no reciben actualizaciones del proyecto. Si tu producto corre sobre una de esas versiones, el problema no es este parche puntual: es que no vas a recibir ninguno. Planifica la migración como deuda técnica crítica, no como algo para el backlog.

3. Revisa logs, no solo el código de la aplicación

Newsbytes reportó que CERT-PH recomendó a las organizaciones monitorear logs de servidor y aplicación en busca de actividad sospechosa, y no limitar la revisión a la capa de aplicación. Si sospechas un compromiso, activa tu procedimiento de respuesta a incidentes.

4. Trata la seguridad de tu stack como riesgo comercial

Si tienes clientes empresariales, prepárate para responder en un RFP o en un cuestionario de seguridad: qué versión de PHP corres, cuándo parcheaste, qué monitoreo tienes. Esa pregunta va a llegar, y contestarla bien puede ser la diferencia entre cerrar o perder un contrato.

¿Vendrán más incidentes como este?

Casi con certeza. PHP, como otros lenguajes de hace décadas, es «memory unsafe»: puede ser atacado por toda una clase de vulnerabilidades que fuerzan al software a filtrar datos de su memoria. Eso empujó la migración hacia lenguajes memory-safe como Python, Rust y Swift.

El problema es el resto: hay una franja enorme de internet corriendo tecnologías antiguas —códecs de video, librerías de compresión, software de hace décadas— que, cuando fallen, tendrán implicaciones masivas.

Los antecedentes existen: en 2016 un botnet masivo inundó el registro de internet Dyn y ralentizó los principales servicios de la web; en 2017 Corea del Norte usó herramientas de hacking filtradas del gobierno de EE.UU. para infectar con ransomware el sistema de salud del Reino Unido; y en 2024 una actualización defectuosa de CrowdStrike provocó una caída global que tumbó computadoras Windows en todo el mundo.

Conclusión

PHP2Shell no fue el fin de internet, pero sí un recordatorio incómodo: buena parte de la infraestructura digital que sostiene tu producto depende de software mantenido por comunidades de código abierto que muchas veces no cobran por ese trabajo y no pueden pagar auditorías de seguridad externas. La IA va a hacer más fácil encontrar esos huecos, para bien y para mal.

Para un founder, la lección práctica es simple: la seguridad de tu stack no es un tema de infraestructura que se delega y se olvida. Es una conversación que deberías tener esta semana con quien mantiene tu sitio.

Fuentes

• TechCrunch: Will AI expose the rickety infrastructure of the internet? (fuente original)
• Yahoo Tech: PHP-ocalypse: How two critical web bugs almost broke the internet
• Hoodline: Two Critical PHP Bugs Put 70% of the Web at Risk, NSA Urges Immediate Patch
• Newsbytes: DICT cybersecurity unit warns of critical PHP flaws