24 horas después del parche de PHP: millones de intentos, cero brechas confirmadas, 758.000 servidores…
Postmortem de php2shell: por qué la peor vulnerabilidad del año no ha roto (todavía) nada
Fuentes: The Record sobre la viabilidad de los exploits; The Register sobre la inclusión en el catálogo de CISA; análisis de Covert Swarm, VulnCheck, Sophos, Cloudflare y la Universidad de Delft; avisos de php.net.
Hace una semana, media Europa apagó sus webs públicas, una primera ministra pidió a su país revisar servidores “esta misma noche”, agencias de tres continentes recomendaron desconectar antes que arriesgarse, y en esta revista publicamos cuatro artículos seguidos sobre lo que bautizamos como la Gran Guerra de PHP. Siete días después, toca hacer lo que casi nadie hace en seguridad: volver sobre lo anunciado y compararlo con lo ocurrido. Y lo ocurrido es esto: no se conoce ni una sola web de producción comprometida por php2shell. Ni una empresa, ni una administración, ni un medio ha reconocido una brecha. La peor vulnerabilidad del año no ha roto, todavía, nada que alguien haya podido señalar.
Después de la tormenta
Millones de intentos. Cientos de webs apagadas. Cero víctimas con nombre. Qué pasó entre el anuncio y la realidad.
Lo que se anunció y lo que ha pasado
| Lo que se dijo la semana pasada | Lo que hay a 28 de octubre |
|---|---|
| “Afecta al 69% de la web” | Cierto en teoría. En la práctica, la explotación fiable depende de la arquitectura, la versión y la configuración; la mayoría de los exploits públicos no funcionan contra un servidor normal |
| “Explotación masiva inminente” (Sansec) | Millones de intentos bloqueados por Cloudflare; más de 50.000 peticiones desde 600 IPs según Delft. Intentos, no intrusiones |
| “Se intenta instalar la botnet Mirai Potassium” | Sophos: los intentos fracasaron en su mayoría; retiró su única afirmación de compromiso exitoso en un cliente |
| “25 servidores comprometidos, algunos del Gobierno de EE. UU.” | Un único informe sin confirmar por ninguna otra fuente |
| “Hay que apagar las webs” (CERT-EU, NCSC, NSA) | Se apagaron cientos. Ninguna de las que no apagó ha reportado daños |
| Ejecución remota de código demostrada | Sí: en honeypots con un solo worker (24 de octubre) y en laboratorios de VulnCheck y Covert Swarm con exploits que no son públicos |
| Catálogo de explotadas de CISA | Añadidas el domingo 26, cinco días después del parche. Confirma que hay ataques; no nombra víctimas |
Por qué el exploit no es el que te vendieron
La razón técnica de que el cielo no se haya caído tiene nombre: aleatorización del espacio de direcciones, ASLR para los amigos. Es una protección estándar de cualquier servidor Linux moderno que cambia en cada arranque la posición de la memoria. Para convertir el fallo de PHP en ejecución de código, el atacante necesita acertar direcciones de memoria, y con ASLR activo eso significa adivinar, fallar, tirar workers abajo y volver a intentarlo. VulnCheck, que lleva una semana desmontando las pruebas de concepto que circulan, lo resume sin piedad: “muy pocas contienen exploits legítimos que funcionen”, y ninguna de las públicas supera ASLR por sí sola en sistemas x86-64, que son casi todos los servidores del mundo.
Los únicos que han demostrado ejecución de código con la configuración recomendada de producción son dos equipos profesionales, VulnCheck y Covert Swarm, y el primero mantiene su exploit bajo llave. Covert Swarm lo consiguió en ARM64, donde ASLR es más fácil de forzar, con Apache y mod_php. Y los éxitos “en la naturaleza” reportados el 24 de octubre fueron contra honeypots configurados con un solo worker, un escenario que el propio investigador, Adel Karimi, advierte que no refleja servidores reales. Traducido al castellano de un administrador de sistemas: el fallo es real, el exploit fácil no existe, y el difícil lo tienen cuatro.
Una vulnerabilidad crítica en el 69% de la web no equivale a un exploit que funcione en el 69% de la web. La semana pasada se confundieron las dos cosas, y la factura la pagó quien apagó.
Hipertensión mental, siete días después
Entonces, ¿se exageró?
Sí y no, y conviene separar quién exageró qué. El equipo de PHP no exageró: calificó el fallo de crítico, dijo que no había mitigación completa y pidió actualizar. Todo eso sigue siendo cierto. CISA tampoco: tardó cinco días en incluirlo en su catálogo, precisamente porque esperó a tener pruebas de explotación, y las tiene, aunque sean modestas. Quien exageró fue la cadena que va del aviso al titular: los proveedores de seguridad que hablaron de “explotación masiva” el mismo día del parche, los medios que titularon “la peor vulnerabilidad de la historia”, y, con honestidad, también esta revista, que abrió con una guerra mundial y un apagón de internet.
Pero hay una exageración que no fue tal: la de apagar. Visto desde hoy, el Parlamento holandés o las guarderías japonesas desconectaron para protegerse de un ataque que no llegó con la fuerza prevista. Visto desde el lunes 20, con el embargo roto, un exploit filtrado en vídeo y Cloudflare viendo ataques antes del parche, apagar durante unas horas fue la decisión correcta con la información disponible. Que el huracán baje a tormenta tropical no convierte en tontos a los que cerraron las ventanas. Lo convertiría si no las volvieran a abrir.
Las tres cosas que sí pasaron, y que importan más que el exploit
- Un postmortem que admite dos años de retraso. La PHP Foundation reconoció que el fallo se detectó en una auditoría de 2024 y se quedó atascado en debates sobre compatibilidad hasta que, en agosto, cuatro equipos lo encontraron por separado con ayuda de IA. Esa es la noticia de fondo: no la gravedad del bug, sino lo frágil que es el proceso que lo dejó dos años en un cajón.
- Un embargo roto tres veces en 48 horas. Un anónimo en Hacker News, el descubridor publicando “por error” un vídeo del exploit, y Chainguard lanzando imágenes parcheadas seis horas antes de lo pactado. La revelación coordinada demostró que depende de que nadie se adelante, y en 2026 adelantarse es una decisión de negocio.
- 758.000 servidores que siguen donde estaban. VirusTotal cuenta ese número de máquinas con versiones de PHP sin parche posible. Hoy no son noticia porque el exploit fácil no existe. El día que exista, y la historia de Log4Shell dice que tarda meses, no días, ahí estará la cantera.
El tercer fallo, por cierto, sigue sin parche
CVE-2026-115560, el aviso informativo que PHP publicó el jueves 23 sobre la misma función del progreso de subida, sigue sin corrección: llegará con el lanzamiento ordinario de noviembre. Afecta solo a aplicaciones que cambian el manejador de serialización de sesión en tiempo de ejecución, un caso que PHP califica de improbable. La mitigación es la misma línea de configuración que se recomendó el día 21. Nadie ha informado de explotación. Es la prueba de que el equipo de PHP ha aprendido algo del postmortem: esta vez avisó antes de tener el parche, sin dramatismo, con la mitigación lista.
Qué deberíamos aprender, todos
La primera lección es para quien comunica seguridad, nosotros incluidos: distinguir siempre entre intentos y compromisos. “Millones de ataques” sin una sola víctima confirmada es una cifra de escáneres, no de daño, y presentarla como lo segundo erosiona la credibilidad para la próxima vez, que llegará y quizá sea peor. La segunda es para quien administra: la ventana entre aviso y explotación real fue, esta vez, más ancha de lo anunciado, pero eso es suerte estadística y configuración, no mérito. Quien parcheó el martes hizo lo correcto; quien no ha parcheado todavía sigue sin excusa, porque el exploit que hoy tienen cuatro equipos mañana lo tendrá cualquiera.
Y la tercera es para el sector entero. El sistema funcionó: el fallo se encontró, se parcheó en cuatro ramas a la vez, las agencias avisaron, Cloudflare protegió hasta a sus clientes gratuitos, y las webs que apagaron volvieron. Lo que no funcionó fue el termómetro. Durante una semana no hubo manera de saber si estábamos ante Log4Shell o ante un susto, porque todo el mundo tenía incentivos para gritar y nadie para medir. php2shell no ha roto nada todavía. Lo que sí ha roto es la ilusión de que, en plena crisis, alguien nos va a decir con calma cuánto hay que preocuparse. Esa herramienta no existe. Habrá que construirla antes de la próxima.
