✨︎ Resumen (TL;DR):
- Cloudflare observó una escalada de intentos contra PHP2Shell después de la divulgación pública de las fallas.
- La actividad pasó de miles antes del anuncio a decenas de miles en 45 minutos, cientos de miles en 2 horas y millones al momento del reporte.
- Aunque las protecciones del WAF estén activas, actualizar PHP sigue siendo necesario para corregir la vulnerabilidad en el servidor.
Cloudflare registró millones de intentos de explotar PHP2Shell después de la divulgación pública de las fallas. Matthew Prince, CEO de la compañía, reportó el aumento el 22 de octubre, mientras empresas y organismos aplicaban correcciones a PHP. La cifra representa intentos observados en la red de Cloudflare, no servidores comprometidos.
Prince describió una escalada por etapas. Cloudflare observó miles de intentos durante las 10 horas anteriores al anuncio público. En los primeros 45 minutos posteriores, la cifra llegó a decenas de miles; durante las 2 primeras horas, alcanzó cientos de miles. Para cuando el CEO publicó su mensaje, el recuento ya estaba en millones.
Cloudflare ya había comunicado que detectó tráfico de ataque antes de la publicación oficial. También señaló que los atacantes modificaban sus solicitudes para intentar eludir las defensas.
PHP2Shell exige actualizar el software del servidor
PHP2Shell es un conjunto de vulnerabilidades de PHP que afecta el manejo de memoria y puede permitir ejecutar código sin autenticación. Las fallas corresponden a CVE-2026-109618 y CVE-2026-109619.
El proyecto de PHP considera en riesgo las instalaciones que atienden solicitudes web. El mayor riesgo está en Apache con mod_php, donde existe una explotación demostrada.
El equipo de PHP publicó el 21 de octubre las versiones corregidas 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones de Linux y los proveedores de soporte prolongado recibieron los parches por adelantado, así que también pueden ofrecer paquetes con la corrección incorporada.
Los administradores deben aplicar la corrección en PHP, dentro del servidor. Cloudflare insiste en instalarla aunque el WAF, o cortafuegos de aplicaciones web, esté activo. Actualizar únicamente el código de una web o sus plugins no corrige estas fallas.
Según el informe de Cloudflare del 21 de octubre, las protecciones de su WAF estaban activas por defecto para los clientes que lo utilizan, incluidos los del plan gratuito. Esa cobertura no sustituye el parche de PHP.
Los sistemas expuestos a internet requieren prioridad
El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) recomienda identificar los sistemas que utilizan PHP y priorizar los que están expuestos a internet. Si una organización no puede aplicar la actualización ni las mitigaciones temporales con suficiente rapidez, el organismo aconseja considerar la desconexión del sistema hasta reducir el riesgo.
Ese criterio ayuda a entender los cierres preventivos. Reuters informó el 22 de octubre que Valtori, el proveedor estatal de servicios informáticos de Finlandia, estaba levantando gradualmente los bloqueos después de instalar parches. La entidad atribuyó las interrupciones a medidas de precaución y afirmó que restaurar los servicios podía tomar días o semanas por las pruebas necesarias.
Para los administradores, la decisión no termina en activar un WAF: deben corregir PHP en los servidores expuestos. Si el parche o las mitigaciones no llegan a tiempo, la recomendación del NCSC contempla desconectarlos hasta reducir el riesgo.
