No puedes predecir la próxima CVE crítica, pero sí la fecha de fin de vida de tu versión de PHP. Lo que costó PHP2Shell en un solo día y por qué usar una versión EOL convierte un mal día en una migración forzada.
A las 07:43 UTC del 21 de octubre de 2026, Cloudflare vio los primeros ataques. El parche no existiría hasta seis horas y diecisiete minutos después.
Al mediodía en Europa, la agencia neerlandesa de ciberseguridad había apagado su propio sitio web. DigiD, MijnOverheid y la Tweede Kamer (la cámara baja neerlandesa) estaban caídos. El proveedor estatal de TI de Finlandia había retirado servicios de red del gobierno y el Ministerio del Interior de Francia había desconectado sitios administrativos locales. La causa eran dos fallos de PHP, CVE-2026-109618 y CVE-2026-109619, ambos con puntuación 9.2 y ambos capaces de ejecutar código sin autenticarse.
Este artículo no explica cómo funciona el exploit. Habla de la factura. Una parte de esa factura nadie podía evitarla. Otra se agendó hace años, con una fecha impresa en php.net. La habilidad útil es distinguir una de otra.
Lo que nadie podía agendar
Esta es la cronología según la reconstrucción de Sansec. Los investigadores reportaron el primer fallo al proyecto PHP el 11 de agosto. Otro equipo reportó más el 24 de agosto. El 20 de octubre se filtraron los detalles y el equipo de PHP adelantó su lanzamiento. En la mañana del día 21 empezaron los ataques, y a las 14:00 UTC salieron las versiones corregidas. Reuters informó de que un modelo de IA ayudó a encontrar el primer fallo, una razón más para esperar que el próximo llegue más rápido.
Nadie que operara un sitio PHP tenía una entrada en el calendario para nada de esto. Si tu plan de seguridad dependía de saber el día, nunca fue un plan.
Y durante casi todo el 21 de octubre el precio fue el mismo para todos. El aviso de lanzamiento de PHP 8.4.27 decía que actualizar es la única opción segura, y hasta las 14:00 UTC no había nada a lo que actualizar. Apagar el sitio era el único control que funcionaba. Sitios neerlandeses como la Tweede Kamer y Tweakers volvieron tras el parche.
Una advertencia antes de seguir. Ninguno de los informes que encontré dice cuáles de los sitios caídos ejecutaban una versión de PHP sin soporte. Un apagón es lo que pagas cuando no estás seguro de qué ejecutas, o no puedes cambiarlo rápido. El fin de vida (EOL, end of life) no lo explica. El EOL es lo que lo empeora.
Lo que estaba impreso en un calendario
La política de PHP es simple. Cada rama recibe dos años de soporte activo, luego dos más solo de correcciones de seguridad, y después termina. La página de versiones soportadas muestra las fechas desde hace años.
| Rama | Fin del soporte de seguridad |
|---|---|
| 7.4 | 28 nov 2022 |
| 8.0 | 26 nov 2023 |
| 8.1 | 31 dic 2025 |
| 8.2 | 31 dic 2026 |
| 8.3 | 31 dic 2027 |
A las 14:00 UTC el proyecto publicó 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para 8.1 y anteriores no llegó nada. El aviso de Laravel Forge es directo: 8.1 y anteriores no reciben corrección oficial y siguen siendo vulnerables.
Algunos proveedores intervinieron. Plesk, por ejemplo, reconstruyó sus paquetes de 8.1 y 8.0 el 21 de octubre. Es una decisión del proveedor, tomada según el calendario del proveedor. Incluso el camino soportado fue desigual: Sansec señaló que el repositorio Remi, habitual en servidores basados en RHEL, no tenía la corrección el día del lanzamiento.
Así que la misma alerta produjo dos tardes muy distintas.
Dos equipos, una misma alerta
Imagina dos equipos. Es un escenario hipotético, sin cifras.
El primero ejecuta PHP 8.3 en contenedores detrás de un pipeline. Su tarde: subir la imagen base a 8.3.36, reconstruir, desplegar y reiniciar los workers (los procesos de PHP-FPM que atienden las peticiones). Es una versión de parche (patch release), así que el código de la aplicación no cambia. Lo difícil es la velocidad del pipeline, y ese pipeline lo construyeron mucho antes de hoy.
El segundo ejecuta una aplicación de diez años en 7.4. No hay parche oficial que esperar. Todas sus opciones son parciales. Puede aplicar la configuración provisional que sugirió PHP, que bloquea una vía de ataque y no es la corrección. Puede esperar un backport de un proveedor (el arreglo trasladado a una versión antigua) y confiar en que llegue pronto. Puede apagar el sitio. O puede empezar la migración que se pospuso cada trimestre, ahora con el reloj del atacante en marcha.
Esa migración no es una versión de parche. Son varias versiones menores de funciones eliminadas y comportamientos cambiados, más cada dependencia de Composer que dejó de soportar la versión antigua. Hecha en una emergencia, no tiene ventana de pruebas, ni plan de reversión, ni nadie que recuerde por qué existe esa solución improvisada de la línea 214.
El primer equipo pagó mantenimiento, en cantidades pequeñas, durante todo el año. El segundo paga el saldo completo en una tarde, al peor precio posible. Ese es el costo del EOL: no la vulnerabilidad en sí, sino perder la opción de responder con calma.
Parchear la capa equivocada
Hay una trampa para los equipos que se creen cuidadosos. Muchas organizaciones actualizan WordPress, Drupal o Joomla y sus plugins con un calendario estricto. Es buena higiene y no toca este problema. Según la declaración de Automattic, actualizar el CMS o sus plugins no corrige el runtime de PHP que hay debajo. Los investigadores demostraron el ataque contra instalaciones actuales de WordPress, Drupal y Joomla.
Si el intérprete está congelado en una versión que nadie parchea, una aplicación perfectamente mantenida se apoya sobre unos cimientos sin mantenimiento.
La cola larga
La emergencia no termina cuando los sitios vuelven. El NCSC neerlandés dijo que la experiencia con fallos similares indica que los atacantes siguen explotándolos durante mucho tiempo, y que es probable que aquí ocurra lo mismo.
Un sitio parcheado deja de ser objetivo. Uno sin parchear sigue en la lista. Y hay muchos sitios en esa lista: un análisis de septiembre de datos de WordPress.org, publicado por un proveedor de software de hosting, situó las ramas que ya pasaron su fin de vida en el 37.6 % de las instalaciones de WordPress que reportan, con la 7.4 sola en el 16.7 %. Tómalo como indicativo, porque viene de una fuente secundaria.
La objeción razonable
El EOL no siempre significa desprotegido. Las distribuciones Linux suelen mantener versiones antiguas de PHP durante años. Un informe de 2023 señaló que Red Hat listaba 7.4 como soportada en RHEL 8 hasta mayo de 2029, mientras que Azure App Service seguía el fin de vida de la comunidad. Si usas una distribución soportada con backports, tienes una opción real.
Pero tiene costos. Dependes del calendario de otro, también un día como el 21 de octubre. Sigues debiendo la migración, solo que más tarde y más grande. Y necesitas saber exactamente qué paquete recibe la corrección, lo que nos devuelve al inventario. Los backports son un puente. No son un destino.
Qué revisar esta semana
Empieza por la pregunta que los apagones le impusieron a todo el mundo: ¿qué PHP ejecutamos realmente? No lo que dice la documentación. Lo que está instalado y lo que está corriendo.
# Host: la CLI instalada y el PHP-FPM que realmente atiende peticiones
php -v
php-fpm8.4 -v # cambia 8.4 por tu rama
# Contenedores: primera línea de `php -v` en cada contenedor en ejecución
for c in $(docker ps --format ''); do
v=$(docker exec "$c" php -v 2>/dev/null | head -n 1)
echo "$c: ${v:-no se encontró php}"
done
Un paquete nuevo en disco no cambia un worker que ya está en ejecución, así que reinicia PHP-FPM o el servidor web después de cualquier actualización. Luego anota las respuestas: cada servicio, su rama de PHP y su fecha de fin de vida.
Siguen tres hábitos más. Pon las fechas de EOL en un calendario compartido con seis meses de antelación y trata el 31 de diciembre de 2026 (fin de la 8.2) como la primera entrada. Presupuesta la actualización menor anual como mantenimiento, porque PHP publica una versión nueva cada noviembre. Y mide cuánto tardas en llevar a producción una versión de parche de extremo a extremo, porque ese número decidió quién pasó el 21 de octubre reiniciando workers y quién lo pasó tomando decisiones.
Conclusión
Nadie agendó el 21 de octubre. La alerta de las 07:43 de Cloudflare nació de un reporte de agosto, una filtración y una carrera que ningún equipo de aplicación podía ver. Esa parte solo se sobrevive, siendo rápido y sabiendo qué ejecutas.
Pero alguien sí agendó el 31 de diciembre de 2026, y está en php.net para que cualquiera lo lea. Escrito el 22 de octubre, a PHP 8.2 le quedan diez semanas. La vulnerabilidad fue una sorpresa. La fecha límite nunca lo fue.
Top comments (0)