El fallo crítico de PHP que se parcheó el miércoles ya se estaba atacando cuatro días antes. Amazon cuenta que su red de servidores trampa registró el 17 de octubre un intento de explotar PHP2Shell, como se conoce al par de vulnerabilidades, cuando todavía eran secretas. Y añade que, desde que se publicó el parche, se explotan «de forma generalizada». La recomendación cambia: no basta con actualizar, también hay que revisar qué pasó en el servidor desde el día 17.
Ayer contamos que PHP había publicado un parche de emergencia (8.5.12, 8.4.27, 8.3.36 y 8.2.35) para dos fallos con una puntuación de 9.2 sobre 10 que permiten ejecutar código en el servidor sin iniciar sesión. El plan era el habitual en estos casos: el arreglo se reparte en secreto a las distribuciones, que preparan sus paquetes, y todo se hace público a la vez. Ese embargo debía levantarse a las 14:00 UTC del 21 de octubre.
Dos textos publicados el mismo miércoles cuentan ahora lo que pasó alrededor de esa fecha. Uno es de CJ Moses, responsable de seguridad de Amazon, sobre lo que vieron sus sensores. El otro es de la PHP Foundation, que explica cómo se descubrió el fallo, por qué tardó en arreglarse y cómo se filtró antes de tiempo.
Claves de lo que se sabe de PHP2Shell
- El primer ataque, cuatro días antes: MadPot, la red de servidores trampa de Amazon, registró el 17 de octubre un intento de explotación desde una dirección de una red comercial de anonimización. Amazon dice que no sabe cómo consiguió el atacante la información, porque entonces el fallo aún era secreto. Es anterior incluso a la filtración del día 20.
- La filtración: según la PHP Foundation, el martes 20 hacia las 15:00 UTC empezaron a circular por foros y redes los dos números de CVE, sin detalles técnicos pero con una hora de publicación y una puntuación de 10.0 equivocadas. PHP adelantó su preaviso y movió el parche del 22 al 21 de octubre. Esa noche, Calif, una de las empresas que había encontrado el fallo, publicó por error un vídeo de su ataque funcionando; lo borró, pero las copias corrieron por las redes.
- El embargo, roto: el 21 a las 07:41 UTC, más de seis horas antes de la publicación coordinada, la empresa Chainguard publicó imágenes con el arreglo ya compilado. La fundación dice que lo hizo «unilateralmente», y que eso permitía a cualquier atacante estudiar el parche mientras el resto de usuarios de PHP seguía esperando.
- Ataques desde la madrugada: el mismo día 21, Amazon vio las primeras pruebas de concepto hacia las 02:00 UTC e intentos de explotación entre las 02:00 y las 08:00 UTC, con cargas distintas y desde redes anonimizadas distintas, lo que apunta a varios atacantes. Tras la publicación oficial salieron más exploits en cuestión de horas, y sus sensores los recibieron casi enseguida.
- ¿Funcionan esos ataques? Amazon dice que aún analiza si alguno de esos intentos habría tenido éxito contra servidores reales, y la PHP Foundation no encontró ningún exploit funcional entre los que circulaban al publicar el parche. Algunos desarrolladores, como Elias Taylor, sostienen que las pruebas de concepto públicas no funcionan contra un PHP normal. Pero la fundación confirma que el ataque completo existe: con Apache y mod_php se demostró la ejecución de código con la configuración por omisión.
- Un fallo conocido desde 2024: las primeras señales del problema aparecieron en 2024, al corregir otro hallazgo de una auditoría externa de Quarkslab. Entonces no se conocía una forma de explotarlo, había varias soluciones posibles y todas rompían algo, y el arreglo se atascó durante meses. La fundación lo llama sin rodeos «un fallo estructural». En agosto, Calif y OpenAI encontraron, cada uno por su lado el mismo día, una forma de ejecutar código con esa misma causa, y desde entonces fue la prioridad del equipo.
Qué revisar además de actualizar
Si un servidor tuyo con PHP estaba expuesto a internet, ya no basta con instalar la versión corregida: Amazon recomienda investigar desde el 17 de octubre, no desde la fecha del parche.
- Actualiza si aún no lo has hecho a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, y reinicia PHP-FPM o Apache. Amazon insiste en que es la única solución completa: ninguna configuración tapa los dos fallos.
- Busca en los registros peticiones POST de subida de formularios que contengan la cadena
PHP_SESSION_UPLOAD_PROGRESS, y cualquier actividad rara desde el 17 de octubre. - Revisa el servidor: procesos que no deberían estar ejecutándose y archivos modificados sin motivo, sobre todo en las carpetas de la web.
- Si no puedes actualizar ya, Amazon propone valorar el bloqueo de las subidas de archivos multipart, después de comprobar qué parte de la aplicación dejaría de funcionar.
- Las direcciones que publica Amazon (seis, una del 17 y cinco del 21) son de redes de anonimización compartidas por mucha gente. Amazon aconseja investigar lo que venga de ellas, no bloquearlas sin más.
Por qué ya no hay días de margen
Amazon saca dos lecciones que van más allá de PHP. La primera: un embargo solo protege hasta que otro encuentra el mismo fallo, así que la fecha del aviso público no es necesariamente la del primer ataque. La segunda: el tiempo entre un parche y un ataque que funcione se está acortando, porque el análisis asistido por IA abarata convertir un parche o un aviso técnico en un exploit. Antes, la mayoría de atacantes esperaba a que unos pocos expertos publicaran uno; ahora más gente puede hacerlo en horas o minutos. Por eso Amazon pide medir en horas, no en semanas, el plazo para parchear sistemas expuestos.
La PHP Foundation describe la otra cara de esa misma tendencia: desde julio ha publicado 15 CVE y ha descartado más de 100 informes no válidos, duplicados o imposibles de reproducir, muchos fruto de la búsqueda de fallos con IA. Las herramientas encuentran errores más rápido que nunca, dice, pero decidir cómo arreglar un problema de diseño del motor de PHP sigue en manos de muy pocos ingenieros, y pide a las empresas que viven de PHP que financien ese trabajo. Mientras tanto, para quien administra un servidor, el mensaje es claro: actualizar hoy y mirar los registros hacia atrás.
Más fuentes: PHP Foundation, «Today’s PHP Security Release, and How We’re Strengthening PHP Security», y Elias Taylor, «There isn’t an easy exploit for this PHP vulnerability». Imagen de portada: AWS.