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 Gobierno de Japón recomendó suspender 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í. Los 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.
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). Llegó desde una red de anonimato comercial. Amazon no sabe cómo obtuvo el atacante esa información.
Según explica la Fundación PHP, luego vino la filtración de la información sobre la vulnerabilidad. El martes 20 de octubre, los dos identificadores ya circulaban por foros y redes. Una de las firmas que reportó el fallo publicó por error un vídeo con su prueba de concepto. Y otra empresa soltó imágenes con el arreglo más de seis horas antes de lo pactado.
El escudo de Cloudflare. Con la noticia de la existencia de una brecha de seguridad que permitiría entrar como Pedro por su casa en millones de servicios web corriendo como la pólvora por los foros especializados, no había más remedio que tomar medidas drásticas para levantar un escudo de seguridad. Cloudflare había estado desarrollando sus reglas con la Fundación PHP, OpenAI y Wiz desde principios de octubre, según detalla la empresa. Ante la previsible avalancha de ataques, Cloudflare activó la protección por defecto el 21 de octubre. Casi once horas antes de que se anunciara el parche que solucionaba el problema.
La barrera que levantó Cloudflare no se limitó a sus clientes corporativos, sino que protegió a los clientes con cortafuegos web y a aquellos que tenían el plan gratuito. Según datos de W3Techs, este escudo de Cloudflare podría haber sido la única protección para una de cada cuatro webs de todo internet.
Las reglas normales de seguridad no bastaban para atajar la vulnerabilidad por lo que la compañía creó la "detección de transacción completa", que analiza la petición del usuario y la respuesta del servidor. Si algo no le cuadra, bloquea la respuesta antes de que llegue a quien la pidió. Es decir, su red se ha colocado entre el visitante y el servidor, que es cómo funciona Cloudflare y permite filtrar el tráfico.
Ataques a ritmo de máquina. La anticipación de Cloudflare en desplegar el escudo que ha protegido a millones de páginas estaba más que justificada. Según recogía Reuters, en las diez horas previas al anuncio, Cloudflare detectó miles de intentos de uso de esta vulnerabilidad. Su consejero delegado, Matthew Prince, aseguraba que "subió a decenas de miles en los 45 minutos posteriores al anuncio. Después, a cientos de miles en dos horas, y ahora a millones".
CJ Moses, jefe de seguridad de Amazon, considera que la IA explica buena parte de ese incremento en el número de intentos de ataque detectados y que el tiempo entre parche y exploit funcional "se está reduciendo por razones estructurales". El análisis asistido por IA lo abarata, añadió.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.