Por qué gobiernos y empresas de cuatro continentes apagaron sus webs por PHP2Shell

No fue un ataque lo que dejó fuera de servicio DigiD, las webs públicas del Gobierno finlandés y cyber.gov.au el miércoles 21 de octubre de 2026. Los apagaron sus responsables, igual que el Ministerio del Interior francés hizo con las webs de las prefecturas, en su mayoría horas antes de que el proyecto PHP publicara el parche de dos vulnerabilidades críticas bautizadas como PHP2Shell. La Agencia Tributaria japonesa apagó la suya la mañana siguiente.

Que gobiernos y empresas de cuatro continentes dejaran sin servicio a la vez a ciudadanos y clientes, por cautela y en muchos casos por recomendación de sus agencias de ciberseguridad, es lo que distingue a PHP2Shell de otras vulnerabilidades críticas. La forma en que se gestó refleja además cambios en cómo se descubren, se divulgan y se corrigen hoy los fallos de software.

¿Qué es PHP2Shell y por qué causó tanta alarma?

PHP2Shell agrupa dos vulnerabilidades del intérprete de PHP, CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación CVSS v4.0 de 9,2. Permiten ejecutar código en el servidor sin credenciales y leer su memoria, donde puede haber contraseñas, tokens de sesión y claves de API de otros usuarios, según el resumen técnico de The Hacker News. Como el fallo está en el motor y no en la aplicación, una web bien mantenida queda igual de expuesta si corre sobre una versión afectada.

La escala explica el resto. PHP está detrás del 69,3 % de las webs cuyo lenguaje de servidor se conoce, según W3Techs, dato que recoge Tenable. Palo Alto Networks estimó más de 22,6 millones de instancias expuestas potencialmente vulnerables, según TechTarget, aunque otros recuentos de servidores expuestos son mucho menores. Tenable recoge estimaciones de 1,3 a 1,9 millones, y CybelAngel cifra en 2,24 millones los hosts que muestran PHP. Casi todas las versiones publicadas desde PHP 5.4 están afectadas, y solo las ramas 8.2 a 8.5 tienen versiones oficiales corregidas (8.2.35, 8.3.36, 8.4.27 y 8.5.12); para 7.4, 8.0 y 8.1 solo hay parches de código fuente.

El calendario agravó la presión. Los identificadores se filtraron el 20 de octubre, el proyecto adelantó un día la publicación y los parches llegaron poco antes de las 14:00 UTC del 21. Para entonces ya había intentos de explotación, porque Amazon Threat Intelligence registró el primero en sus sensores señuelo el 17 de octubre, cuatro días antes del parche, aunque no sabe si alguno habría tenido éxito contra sistemas en producción.

¿Quién apagó sus servicios entre el 21 y el 22 de octubre?

Varias agencias recomendaron a la vez desconectar lo que no pudiera actualizarse. Entre ellas estaban el NCSC británico, CERT-EU, INCIBE-CERT, el CCN-CERT y, en Estados Unidos, CISA y la NSA. La lista que publicó Reuters, en su versión actualizada del 22 de octubre, y la prensa de cada país permiten saber quién apagó qué. Casi todas las organizaciones citadas presentaron la retirada como una precaución, y el Ministerio de Asuntos Exteriores belga mencionó además informes de ciberataques, aunque el centro belga de ciberseguridad no había registrado ataques.

La tabla recoge solo una muestra. Hubo muchos más cierres de administraciones, empresas y organizaciones de todo tipo, y The Record hablaba de cientos de webs caídas ese miércoles.

En el Reino Unido, el Office for Budget Responsibility retiró sus webs a pocos días de la presentación de los presupuestos. En la Cámara de los Lores se mencionaron además incidencias en la DVLA, servicios policiales y ayuntamientos como Edimburgo, Oxford o Bristol, según The Register. En Países Bajos, NL Times informaba el jueves de que el instituto de salud pública RIVM, la línea de denuncia anónima de la policía y varias sedes de Veilig Thuis, el servicio de ayuda contra la violencia doméstica, seguían sin web.

Un portavoz del ministro del Interior australiano, Tony Burke, confirmó a la cadena ABC, según recoge iTWire, que "algunas webs no están disponibles temporalmente mientras se trabaja para mitigar los riesgos derivados de esta vulnerabilidad". En Canadá, el ministro Evan Solomon explicó que algunas webs del Gobierno se habían retirado por precaución siguiendo las indicaciones del Centro Canadiense de Ciberseguridad, según BetaKit.

España quedó en segundo plano. Según Escudo Digital, no hubo un apagón masivo de los grandes portales ministeriales, aunque algunas administraciones locales, centros de investigación y universidades abrieron ventanas de mantenimiento nocturnas. INCIBE-CERT publicó su aviso con severidad crítica el mismo 21 de octubre y recomendó aislar de las redes públicas lo que no pudiera actualizarse, y el CCN-CERT pidió actualizar con urgencia las aplicaciones PHP o desconectar los servicios no indispensables.

¿Cuál fue el alcance del apagón?

UptimeRobot, que vigila la disponibilidad de las webs de sus clientes, registró el 21 de octubre unas 37.000 alertas de caída por minuto en el pico, once veces lo normal, y unas veinte veces lo normal en Europa. Entre las webs que vigila, las de dominio .nl sin respuesta pasaron de 4.356 a 14.682 en un día, y las .de, de 8.660 a 18.422. La curva empezó a subir antes del parche, a última hora de la mañana en Europa, y a las 09:00 UTC del día 22 las alertas seguían un 30 % por encima de lo normal.

No consta ningún compromiso confirmado en las grandes administraciones. La ministra británica de Tecnología, la baronesa Lloyd, dijo no tener constancia de compromisos en los sistemas del Gobierno central, el NCSC neerlandés no veía explotación activa en el país y Valtori no había detectado intentos en Finlandia. Los atacantes sí estaban activos. Cloudflare pasó de ver miles de intentos en las horas previas a millones después, según The Register.

El responsable de inteligencia de amenazas de watchTowr, Jake Knott, dijo el 21 de octubre a The Record que nadie había logrado explotarlo, "pero no esperamos que eso dure mucho". Al día siguiente, la empresa VulnCheck anunció un exploit, solo disponible para sus clientes, que esquiva la protección ASLR en servidores x86-64 con la configuración de producción recomendada, según The Register. A 22 de octubre, la CISA no había incluido los fallos en su catálogo de vulnerabilidades explotadas (KEV).

El coste del apagón fue, por tanto, sobre todo de servicio, con trámites sin hacer, avisos de interrupción de nóminas en al menos un proveedor de software de RR. HH. y líneas de ayuda sin web durante horas. Se asumió para evitar un compromiso masivo con robo de credenciales desde la memoria de los servidores. Por ahora no consta que la cautela fuera innecesaria, y es previsible que los ataques contra servidores sin parchear continúen durante semanas.

¿Cómo refleja PHP2Shell el momento tecnológico?

¿Cómo aceleró la IA el hallazgo y la explotación?

Según la PHP Foundation, Calif y OpenAI comunicaron por separado la misma causa raíz el 11 de agosto. Wiz Research encontró el primero de los fallos de forma independiente el 19 de agosto con modelos de Google y OpenAI. Wiz atribuye a esos modelos buena parte del desarrollo del código de explotación y sostiene que un único investigador completó en una semana un trabajo que habría llevado meses a un equipo de primer nivel.

OpenAI dice haber coordinado durante dos meses una coalición para preparar las correcciones antes de hacerlas públicas, y reconoció, según The Record, que la IA "también puede ayudar a los atacantes a explotar" las vulnerabilidades. El NCSC británico, según la ministra, había recibido información de OpenAI sobre la vulnerabilidad la semana anterior.

¿Por qué se rompió la divulgación coordinada?

Cuantas más partes saben de un fallo, más difícil es mantener el embargo. Los identificadores se filtraron dos días antes de la fecha prevista, apareció en redes un vídeo de la cadena de explotación y un distribuidor de imágenes de contenedor publicó compilaciones con el parche unas seis horas antes de la hora acordada, según The Hacker News. Para Amazon, los defensores no deben asumir que la fecha de divulgación es la fecha más temprana de explotación.

¿Por qué los plazos de parcheo se quedan cortos?

Amazon escribe en su análisis que, en gestión de parches, un acuerdo de nivel de servicio de 7 o de 30 días "presupone un margen que ha dejado de existir". La directiva BOD 26-04 de CISA ya había fijado tres días para los fallos del catálogo KEV que dan control total del sistema. Aun así, ese plazo se quedaría corto ante un fallo atacado antes de su publicación, que además, a 23 de octubre, seguía sin figurar en ese catálogo.

¿Por qué el software abierto depende de equipos tan pequeños?

Un desarrollador del núcleo vio indicios del fallo de memoria en 2024, al corregir otro problema de la auditoría externa de PHP, sin encontrar entonces una vía de explotación. Las propuestas de corrección se atascaron después durante meses. La PHP Foundation lo ha calificado de "fallo estructural", atribuido al proceso de decisión de su equipo de seguridad y a la falta de recursos. Buena parte de la web mundial depende de un puñado de personas que mantienen el motor, y esa dependencia no suele figurar en ningún contrato.

¿Qué hay que revisar después de parchear?

Parchear los servidores web es lo primero, y para muchos ya está hecho. En Hard2bit actualizamos nuestros sistemas y los de nuestros clientes el miércoles 21, el mismo día de la publicación. Lo que queda pendiente es menos visible.

• El PHP integrado en equipos que no son servidores web merece una revisión aparte. Palo Alto Networks confirmó que la interfaz de gestión de determinadas versiones de PAN-OS (ramas 10.2 a 12.2), de Panorama y de los equipos WildFire WF-500 está afectada. Los hotfixes de PAN-OS están previstos entre el 26 y el 30 de octubre, y Panorama y WF-500 aún no tienen fecha. A 22 de octubre, según Help Net Security, Fortinet revisaba 12 productos y Cisco 31 productos y servicios en la nube, sin ninguno confirmado como vulnerable.
• El NCSC neerlandés mantiene en GitHub una lista de productos que incluyen PHP, y una revisión de la superficie de ataque ayuda a encontrar consolas, equipos integrados y portales heredados con PHP.
• Las ramas 7.4, 8.0 y 8.1 no tienen versiones oficiales, pero el equipo de seguridad de PHP publicó parches de código fuente y algunas distribuciones y proveedores LTS ofrecen retroportaciones. Para las anteriores a la 7.4 el proyecto no publica corrección, y la 8.2 termina su soporte el 31 de diciembre de 2026. Si no hay parche aplicable ni migración, la opción más segura es aislarlas.
• El rastro desde el 17 de octubre debe revisarse. Amazon recomienda buscar peticiones POST con la cadena PHP_SESSION_UPLOAD_PROGRESS, procesos inesperados y ficheros modificados en los servidores web, y Wiz añade peticiones multipart inusuales seguidas de errores de límite de memoria o respuestas 500 repetidas. Si hay señales, el caso pasa a respuesta a incidentes, con rotación de los secretos que estuvieran en memoria, porque, como en el caso de NetScaler, el parche no retira lo que un intruso haya instalado antes.
• La exposición de los proveedores que ejecutan PHP con datos de la organización también cuenta. Dentro del programa de gestión del riesgo de terceros hay que pedirles confirmación escrita de parcheo y de revisión de registros.

Las reglas de WAF que publicaron Cloudflare, AWS y otros ganaron horas, pero solo protegen el tráfico que pasa por ellas y los atacantes ya modifican sus cargas maliciosas para esquivarlas.

¿Qué controles siguen valiendo y cuáles han caducado?

Siguen vigentes los controles básicos, con otra exigencia de velocidad. Entre ellos están el inventario fiable de dónde corre cada componente, incluido el que viene dentro de un equipo comprado, un programa de gestión de vulnerabilidades que priorice por exposición y explotación además de por CVSS, y unos registros conservados el tiempo suficiente para investigar hacia atrás. Han caducado los plazos de parcheo pensados en semanas para lo expuesto a Internet, la idea de que el WAF sustituye al parche y la confianza en que el día del aviso marca el inicio del riesgo.

En su lugar aparece un control nuevo. Desconectar solía ser la reacción a un incidente, y el 21 de octubre lo recomendaron como precaución agencias de varios países. "Si no puedes parchearlo, protégelo; si no puedes actualizarlo, desconéctalo", resumió Gavin Millard, de Tenable, según recoge iTWire. Para que funcione, la desconexión tiene que estar preautorizada. Saber de antemano qué servicios se pueden apagar, quién lo decide, cómo se avisa a clientes y ciudadanos y cómo se vuelve a encender es parte del plan de continuidad y del plan de respuesta a incidentes.

Si la IA permite encontrar en una semana lo que antes llevaba meses, el próximo PHP2Shell puede llegar con menos aviso, o sin ningún embargo. Nadie sabe aún si los defensores, que usan los mismos modelos, recortarán sus tiempos al mismo ritmo. Lo que sí está en manos de cada comité de dirección es dejar escrito, antes del siguiente miércoles como este, qué servicios se pueden apagar sin consultar a nadie y cuáles no.

Fuentes y atribución: artículo de análisis elaborado con comunicaciones públicas recogidas por los medios enlazados y con avisos de PHP, Amazon, Palo Alto Networks y agencias como INCIBE-CERT, con la información disponible a 23 de octubre de 2026. No incluye código de explotación. La retirada de un servicio en los casos citados no implica que sus sistemas fueran comprometidos ni que existiera un fallo en sus productos o servicios. Las cifras de explotación y exposición proceden de terceros (Amazon, Cloudflare, Palo Alto Networks, UptimeRobot), y versiones, parches y alcance pueden cambiar.