PHP2Shell se atacaba cuatro días antes del parche: la historia del fallo y cómo saber si tu web ha sido objetivo

Ayer te contamos qué es PHP2Shell y qué hacer si tienes una web. Desde entonces han salido dos documentos que cambian la foto: el informe de Amazon, que vio ataques antes de que existiera el parche, y la explicación de la PHP Foundation, que cuenta con bastante franqueza cómo se llegó hasta aquí.

Cronología: de 2024 al parche

Hemos ordenado las fechas de los dos documentos. Las horas están en hora peninsular española:

Cuándo	Qué pasó
2024	Una auditoría externa de PHP lleva a un desarrollador a ver los primeros indicios del problema de memoria. No encuentran cómo explotarlo y el arreglo se atasca durante meses.
11 de agosto de 2026	La empresa Calif informa de que el fallo permite ejecutar código a distancia. OpenAI llega por su cuenta a la misma causa, y Wiz y OpenAI aportan más vías de ataque en agosto y septiembre.
17 de octubre	Amazon detecta el primer intento de ataque en sus servidores señuelo, desde una IP de una red de anonimato.
20 de octubre, 17:00	Los identificadores del fallo empiezan a circular en foros y redes, con una hora de publicación y una gravedad equivocadas. PHP adelanta su aviso y la publicación del parche un día.
20 de octubre, 22:00	Calif publica por error un vídeo de su prueba de ataque. Lo borra, pero las copias siguen circulando.
21 de octubre, 05:02	Cloudflare activa sus reglas contra el ataque en todos los planes con cortafuegos, incluido el gratuito.
21 de octubre, 09:41	Chainguard publica imágenes con el arreglo más de seis horas antes de lo pactado, lo que permite estudiarlo a cualquiera.
21 de octubre, 16:00	PHP publica las versiones corregidas.

Lo que admite la propia PHP

La fundación no se esconde. Explica que el equipo de seguridad barajó varias soluciones y que todas tenían inconvenientes: romper compatibilidad, abrir otra vía de ataque o exigir cambios a extensiones de terceros. Al decidir por consenso y con poca gente que conociera tan a fondo el motor de PHP, el trabajo «se paró y se reinició repetidamente durante meses». Lo llama directamente «un fallo estructural» y dice que ya ha cambiado su forma de decidir.

Sobre la filtración, la fundación asegura que no se filtraron detalles técnicos y que no identificó ninguna prueba de ataque funcional antes de publicar el parche. El informe de Amazon no contradice eso, pero añade un matiz: alguien ya probaba el 17 de octubre, y no se sabe cómo consiguió la información. Amazon tampoco sabe si alguno de esos intentos habría funcionado contra una web real.

Por qué esto nos preocupa más que el fallo en sí

Amazon saca dos conclusiones que compartimos. La primera: el día en que se publica un fallo no es el primer día en que se ataca, así que, si tienes una web, debes revisar lo que pasó desde el 17 de octubre y no desde el 21. La segunda: el tiempo entre que sale un parche y aparece un ataque que funciona se está acortando, en parte porque la IA abarata convertir el código de un arreglo en un ataque. Según Amazon, con PHP2Shell aparecieron nuevas pruebas de ataque a las pocas horas de publicarse el parche, y ya hay intentos masivos.

Nuestra opinión: para una web pequeña, la lección práctica es que ya no basta con actualizar «cuando haya un rato». En fallos así, la diferencia entre actualizar hoy o la semana que viene puede ser la diferencia entre no pasar nada y tener que limpiar la web.

Cómo saber si han intentado atacar tu web

Amazon recomienda a quien gestiona servidores estos pasos, que hemos traducido y ordenado:

1. Busca en los registros del servidor peticiones POST que lleven el texto PHP_SESSION_UPLOAD_PROGRESS en el formulario. Es la huella de una de las vías de ataque.
2. Revisa los registros desde el 17 de octubre, no desde el 21.
3. Comprueba si hay procesos que no esperabas o ficheros modificados en el servidor de la web.
4. No bloquees sin más las IP que publica Amazon. Son de redes de anonimato que usa mucha gente; Amazon pide investigarlas, no bloquearlas.

Si tu web está en un alojamiento compartido y no ves los registros, puedes hacer dos cosas. Pide a tu proveedor que revise los accesos desde el 17 de octubre y que te confirme que ha actualizado PHP. Y en tu WordPress, o en el panel de tu tienda, mira si hay usuarios administradores que no reconoces, extensiones que no instalaste o cambios recientes en ficheros que no hayas hecho tú. Esto último no lo dice Amazon: son las comprobaciones que haríamos nosotros con nuestra propia web.

El fallo no solo afecta a webs. INCIBE avisa de que Fortinet está revisando varios de sus productos de seguridad que usan PHP, aunque todavía no ha confirmado qué versiones están afectadas.

Si tienes una web con PHP y aún no has comprobado la versión, no esperes al lunes. Ya hay ataques en marcha y empezaron antes de lo que nadie sabía.