Ingeniería AI-native

La semana en que los gobiernos desenchufaron: por qué organismos públicos desconectaron webs PHP en lugar de parchear

Las agencias pidieron parchear PHP o desconectarlo y varios gobiernos lo hicieron: qué dijeron CISA, la UE, Reino Unido y Países Bajos

Publicado 2026-10-25Actualizado 2026-10-255 min de lectura

PHPsector públicogestión de vulnerabilidadesaplicación de parchesrespuesta a incidentes

Este artículo es educativo y no sustituye una auditoría formal de smart contracts, asesoría legal, asesoría financiera ni una revisión de seguridad específica del protocolo.

En la semana del 21 de octubre de 2026, las agencias de ciberseguridad de Estados Unidos, la Unión Europea, Reino Unido y Países Bajos dieron la misma instrucción ante dos vulnerabilidades críticas de PHP: parchear ya y, si no es posible, desconectar los sistemas afectados. Varios gobiernos hicieron exactamente eso, y el Gobierno neerlandés desconectó de forma preventiva webs como MijnOverheid.nl y DigiD. En Reino Unido, una ministra explicó en la Cámara de los Lores que 32 servicios del Gobierno no estaban disponibles, en gran parte por medidas preventivas.

La lección no es que estos organismos fallaran. Cuando llegar a un parche verificado lleva días, apagar un servicio es la opción controlada que queda, y esta semana mostró con qué frecuencia la informática pública está en esa situación.

Alcance: este artículo se basa solo en lo que las instituciones publicaron entre el 21 y el 23 de octubre de 2026. Las citas en inglés y neerlandés van en el original con traducción al español. «Desconectar» se refiere a una medida preventiva, en palabras de las propias instituciones. Ninguna de estas fuentes informa de un compromiso confirmado de los organismos citados ni del porcentaje de servidores desconectados.

Una mano desenchufa un cable junto a una pantalla de directorio apagada con un LED ámbar en un pasillo institucional. — Ilustración conceptual.

Qué pasó, por fechas

21 de octubre de 2026: PHP publica las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen CVE-2026-109618 y CVE-2026-109619. Según CISA, el par, conocido como «php2shell», permite la ejecución remota de código sin autenticación.
21 de octubre: CISA y una declaración conjunta de la UE (DG CNECT de la Comisión Europea, ENISA, CERT-EU, Europol EC3 y la red de CSIRT de la UE) piden a las organizaciones parchear de inmediato.
21 de octubre, 15:13 hora local: el Gobierno central neerlandés informa de que varias de sus webs se han desconectado de forma preventiva, antes de que la actualización estuviera disponible.
22 de octubre: se responde en la Cámara de los Lores una pregunta urgente (Private Notice Question) sobre la vulnerabilidad de PHP.
23 de octubre: CISA revisa su alerta, añade una regla de detección y refuerza las pautas de mitigación existentes.

Qué dijeron las agencias

La alerta de CISA es directa sobre el plan B: «Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated» (las organizaciones que no puedan actualizar de inmediato, o que sigan usando PHP 8.1 o versiones anteriores sin soporte, deberían desconectar los sistemas basados en PHP hasta que puedan parchearse o actualizarse). También advierte de que el inventario es más difícil de lo que parece: «PHP is often a component of other software and prevalence may not be directly observable» (PHP suele ser un componente de otro software y su presencia puede no ser directamente observable). En el momento de publicar, CISA indicó que no había observado explotación con éxito de estas vulnerabilidades en entornos reales («not observed successful exploitation of these vulnerabilities in the wild»).

La declaración conjunta de la UE usa un tono más suave en la misma dirección: «Where immediate remediation is not feasible, consider isolating exposed applications from public networks until fixes can be applied» (cuando no sea viable corregir de inmediato, considere aislar las aplicaciones expuestas de las redes públicas hasta que puedan aplicarse las correcciones). Añade que «Many commercial and open-source products rely on PHP in the background» (muchos productos comerciales y de código abierto dependen de PHP en segundo plano), así que algunas organizaciones pueden estar afectadas aunque PHP no sea visible.

En Países Bajos, la nota del Gobierno recoge el consejo del centro nacional de ciberseguridad neerlandés (NCSC). Los responsables de webs deben «zelf een risicoafweging te maken en hun websites eventueel preventief offline te halen tot die update er is» (hacer su propia evaluación de riesgos y, si es necesario, desconectar sus webs de forma preventiva hasta que esté disponible la actualización). La nota añade: «Dit geldt ook voor Rijksoverheidsorganisaties» (esto también se aplica a las organizaciones del Gobierno central).

Qué hicieron los gobiernos

La nota neerlandesa dice que varias webs se han «uit voorzorg offline gehaald» (desconectado por precaución), «Bijvoorbeeld ook overheidswebsites als Overheid.nl, MijnOverheid.nl en DigiD» (también, por ejemplo, webs gubernamentales como Overheid.nl, MijnOverheid.nl y DigiD). Y da la otra cara: «Op een groot deel van de websites van de Rijksoverheid, zoals Rijksoverheid.nl, wordt geen gebruik gemaakt van PHP» (una gran parte de las webs del Gobierno central, como Rijksoverheid.nl, no usa PHP).

En Reino Unido, la baronesa Lloyd of Effra respondió por el Gobierno el 22 de octubre. Los departamentos habían recibido aviso antes de la divulgación pública y se les indicó «identify potential affected systems, assess their exposure and prepare to implement mitigations and security updates as they became available» (identificar los sistemas que podían estar afectados, evaluar su exposición y prepararse para aplicar mitigaciones y actualizaciones de seguridad cuando estuvieran disponibles). Sobre el impacto, dijo: «32 government services are unavailable and four are partially unavailable» (32 servicios del Gobierno no están disponibles y cuatro lo están parcialmente). Según explicó, esto «has resulted largely from precautionary measures taken to protect systems while security updates and mitigations are applied» (se debe en gran parte a medidas preventivas para proteger los sistemas mientras se aplican actualizaciones y mitigaciones), y «The advice of the NCSC is to mitigate and then restore the services» (el consejo del NCSC es mitigar y después restablecer los servicios).

Por qué desconectar era la opción realista

Parchear el día de la divulgación presupone tres cosas: saber dónde corre PHP, que exista una versión corregida para tu rama y poder probarla, aprobarla y desplegarla en horas. En los entornos públicos suele fallar al menos una.

El inventario es la primera brecha. CISA y la declaración de la UE advierten de que PHP va dentro de otros productos, así que el responsable de un servicio puede no saber que existe esa dependencia hasta que el fabricante lo comunica. Si PHP viene dentro de un appliance o paquete de un proveedor, el operador tiene que esperar a la actualización de ese proveedor.

Las ramas con soporte son la segunda. Las versiones corregidas cubren las ramas 8.2 a 8.5, y CISA describe PHP 8.1 y anteriores como versiones sin soporte. Para un sistema que sigue en una de esas ramas, la solución es una migración, no un parche, y una migración no se hace en una tarde.

El control de cambios es la tercera. Las aprobaciones, las pruebas y los contratos con proveedores están pensados para trabajo planificado. Desconectar un servicio convierte una exposición desconocida en una caída conocida que la organización controla, y el restablecimiento puede esperar a que alguien compruebe qué se está ejecutando.

El coste es real: la ciudadanía pierde acceso a servicios. La velocidad es la otra presión. La ministra explicó a los Lores que «The NCSC was briefed by OpenAI last week on this potential specific vulnerability» (OpenAI informó al NCSC la semana pasada sobre esta posible vulnerabilidad concreta) y que «frontier AI allows for the identification of vulnerabilities» (la IA de frontera permite identificar vulnerabilidades), lo que «means we need to be more vigilant and quicker in readying ourselves to apply patches and other mitigations» (significa que debemos estar más atentos y ser más rápidos en prepararnos para aplicar parches y otras mitigaciones). Si el descubrimiento sigue acelerándose, el cuello de botella es el tiempo que necesita la informática pública para pasar de un aviso a una corrección verificada.

Lo que este artículo no afirma

Ningún compromiso confirmado. La ministra dijo que el Gobierno no tenía constancia de «any confirmed compromise of central government systems resulting from these vulnerabilities» (ningún compromiso confirmado de sistemas del Gobierno central derivado de estas vulnerabilidades). La nota neerlandesa dice que había «nog geen signalen dat de kwetsbaarheden actief misbruikt worden» (todavía ninguna señal de que las vulnerabilidades se estén explotando activamente).
Ninguna inclusión en el catálogo de explotación. Al comprobarlo el 25 de octubre de 2026, el catálogo de vulnerabilidades explotadas conocidas de CISA (KEV, versión 2026.10.23) no incluía CVE-2026-109618 ni CVE-2026-109619.
Ningún porcentaje. Ninguna fuente oficial da la proporción de servidores o webs públicas que se desconectaron, así que aquí no se da ninguna.
Ningún juicio sobre los organismos citados. Desconectar fue la medida que recomendaron las propias agencias.

Checklist para operadores

Inventaría cada instalación de PHP, incluido PHP integrado en productos de proveedores, appliances e interfaces de administración, y pide a cada proveedor su estado por escrito.
Anota la rama de PHP de cada sistema. Todo lo que esté en 8.1 o anterior necesita un plan de migración y, mientras tanto, un plan de aislamiento.
Decide de antemano qué servicios pueden desconectarse, quién toma esa decisión y cómo se informa y atiende a los usuarios mientras tanto.
Si un servicio tiene usuarios internos, valora aislarlo de las redes públicas, como sugiere la declaración de la UE, en lugar de apagarlo por completo.
Antes de restablecer, confirma la versión que ejecuta realmente el servicio en producción, no solo la que indica el gestor de paquetes. Primero mitigar, después restablecer.
Registra cuándo se desconectó cada servicio y cuándo volvió. Esa diferencia es tu ritmo real de parcheo.

Lectura relacionada

Guía para parchear PHP: dos RCE sin autenticación corregidas en octubre de 2026

Preguntas para esta semana

¿Qué servicios públicos nuestros usan PHP, incluido dentro de productos que compramos?
¿Cuáles están en PHP 8.1 o anterior, y quién es responsable de la migración?
Si mañana una agencia nos pidiera desconectar los sistemas PHP, ¿quién decidiría y en cuántas horas?
¿Cómo verificamos la versión en ejecución antes del último restablecimiento?

Esta semana las agencias dieron a los organismos públicos dos opciones, parchear o desenchufar, y varios eligieron la segunda. La pregunta útil es cuánto tiempo necesitaría tu propia organización para hacer posible la primera.

Si quieres comentar cómo funcionan el ritmo de parcheo y las desconexiones controladas en tus propios sistemas, la página de contacto está abierta. En el mensaje, menciona este artículo y el sistema en el que estás pensando, sin credenciales ni detalles operativos confidenciales.