Cloudflare registró millones de intentos de explotar PHP2Shell después de la divulgación pública de las fallas, informó su CEO, Matthew Prince, en un mensaje en X recogido por Reuters el 22 de octubre. La actividad creció mientras empresas y organismos aplicaban las correcciones al software PHP que ejecutan sus servidores.
Prince describió una escalada por etapas: miles de intentos durante las 10 horas anteriores al anuncio público, decenas de miles en los primeros 45 minutos posteriores y cientos de miles en las dos primeras horas. Al publicar su mensaje, el recuento ya se situaba en millones.
Son cifras de intentos observados en la red de Cloudflare, no un balance de servidores comprometidos.
La compañía ya había comunicado que detectó tráfico de ataque antes de la publicación oficial y que los atacantes modificaban sus solicitudes para intentar eludir las defensas. Según su informe del 21 de octubre, las protecciones de su cortafuegos de aplicaciones web, o WAF, estaban activas por defecto para clientes que lo utilizan, incluidos los del plan gratuito.
La corrección se aplica en PHP, dentro del servidor
PHP2Shell agrupa las vulnerabilidades CVE-2026-109618 y CVE-2026-109619. Afectan al manejo de memoria de PHP y pueden permitir ejecutar código sin autenticación. El aviso del proyecto considera en riesgo las instalaciones que atienden solicitudes web y sitúa el mayor riesgo 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 con antelación, por lo que también pueden ofrecer paquetes con la corrección incorporada.
Gerardo Pavez
Cloudflare insiste en aplicar la actualización aunque el WAF esté activo. Su explicación sitúa el problema por debajo de la aplicación: actualizar el código de una web o sus plugins por sí solo deja intactas estas fallas de PHP.
El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) recomienda identificar los sistemas que utilizan PHP y priorizar los expuestos a internet. Si una organización no puede aplicar la actualización ni las mitigaciones temporales con suficiente rapidez, 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 tras 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.
Patricia Rodriguez
