PHP ha sido la brecha, Cloudflare ha sido el escudo que ha protegido al otro 40% de internet de caer

El miércoles, varias webs de gobiernos europeos se quedaron sin conexión.

El Ministerio de Finanzas de Japón suspendió parte de sus contenidos y muchas empresas optaron por desconectar sus páginas ante la posibilidad de sufrir un ciberataque.

Nadie quería ser el primero en caer .

El motivo que hizo contener el aliento a los los administradores de servidores de todo el mundo fue un fallo escondido durante más de una década en el código de PHP , el lenguaje que mueve casi el 70% de todas las páginas de internet.

Mientras unos pulsaban el botón del pánico en sus servidores, Cloudflare adoptaba un papel inesperado: se convertía en el escudo que protegía las webs de millones de usuarios y pequeñas empresas que no tienen un equipo de expertos en ciberseguridad en nómina.

La brecha llevaba décadas ahí.

L os dos errores se registraron como CVE-2026-109618 y CVE-2026-109619, aunque ya se les conoce por todo el mundo como PHP2Shell.

Tal y como avisa el INCIBE, esta vulnerabilidad permite a un atacante sin credenciales ejecutar código malicioso directamente en el servido.

Es una amenaza considerada como muy grave con una puntuación de 9,2 sobre 10 de ahí que muchos administradores prefirieran darle un tirón al enchufe de sus servidores antes que exponerse a un ciberataque.

En Xataka Cada cuánto debemos cambiar TODAS nuestras contraseñas según tres expertos en ciberseguridad La Fundación PHP admite que el problema se intuyó en 2024, tras una auditoría externa, pero el arreglo se atascó durante meses y ha asumido el "mea culpa" reconociendo que "el retraso fue un fallo estructural".

En agosto, Calif y OpenAI demostraron que se podía ejecutar código sin credenciales, y todo cambió de prioridad, pero el parche no pudo implementarse a tiempo.

Cuatro días antes del parche .

El anuncio de la existencia de la vulnerabilidad y su parche llegó el miércoles 21 de octubre, lo cual desató el pánico entre los administradores.

Pero Amazon ya detectó un intento de ataque a esa vulnerabilidad el 17 de octubre contra uno de sus señuelos (servidores trampa para estudiar atacantes).