La mañana del miércoles 21 de octubre de 2026, organismos públicos de Países Bajos y Finlandia tomaron una decisión poco habitual: apagar preventivamente sus propios sitios web. No habían sido hackeados. Lo hicieron para evitar serlo. El motivo fueron dos vulnerabilidades críticas descubiertas en PHP, el lenguaje de programación que corre detrás de una parte enorme de internet, con una gravedad de 9,2 sobre 10 según la escala CVSS. Las fallas permitirían a un atacante ejecutar código de forma remota en un servidor vulnerable, sin necesitar contraseña ni cuenta autorizada.
El aviso lo formalizó el CERT-EU, el equipo de respuesta a emergencias informáticas de la Unión Europea, bajo el boletín 2026-018. La agencia nacional de ciberseguridad de Países Bajos desconectó su propio sitio como medida de precaución, y otras instituciones europeas hicieron lo mismo. Las autoridades de Australia, Japón y Reino Unido replicaron la recomendación de revisar con urgencia cualquier sistema que dependa de PHP. Cloudflare, por su parte, reportó intentos activos de explotación y ajustó de forma temporal sus reglas de protección mientras los desarrolladores de PHP terminaban de liberar parches de emergencia.
El problema no se limita a un par de sitios institucionales. PHP es la base técnica de WordPress, Drupal, Joomla y Magento, cuatro de las plataformas más usadas del mundo para construir sitios corporativos, blogs y tiendas online. Según advirtió la firma de seguridad Wordfence, muchos administradores de sitios cometerán en los próximos días el mismo error: actualizar WordPress, sus plugins o su tema, y asumir que con eso quedaron protegidos. No es así. La versión de PHP que corre en el servidor es, casi siempre, responsabilidad del proveedor de hosting, no del equipo que administra el contenido del sitio. Y hasta que alguien no actualice específicamente esa pieza, la vulnerabilidad sigue abierta.
Qué pasó, en términos simples
Una vulnerabilidad de este tipo funciona como una puerta que nadie diseñó para que existiera. No hace falta robar una llave ni adivinar una contraseña: basta con enviarle al servidor una instrucción con el formato correcto para que este la ejecute como si viniera de un usuario autorizado. Eso es lo que significa «ejecución remota de código sin autenticación», y es la categoría de falla más grave que puede tener un sistema expuesto a internet, porque no depende de que un empleado cometa un error. Depende solo de que el servidor siga corriendo una versión de software sin el parche correspondiente.
Lo relevante de este caso no es solo la falla técnica, sino la reacción. Gobiernos de al menos cinco países decidieron que la postura correcta, ante una vulnerabilidad crítica todavía sin explotación confirmada a gran escala, era desconectar servicios por adelantado en vez de esperar a confirmar un ataque. Es exactamente el tipo de decisión que una empresa privada rara vez está preparada para tomar, porque no tiene definido de antemano quién la autoriza, con qué criterio y con qué comunicación hacia los clientes.
Las 5 lecciones de ISO 27001 detrás de esta crisis
El Anexo A de ISO/IEC 27001:2022 cubre, prácticamente punto por punto, cada decisión que una empresa debería estar tomando esta semana.
1. Saber de qué depende tu propio sistema (A.5.9 y A.8.1, gestión de activos). No es posible protegerse de una falla en PHP si nadie en la empresa sabe que el sitio corporativo, la tienda online o el portal de clientes corren sobre PHP, y menos aún en qué versión. La norma exige un inventario de activos de información que incluya el software base de cada sistema, no solo las aplicaciones visibles. Sin ese inventario, la primera pregunta frente a una alerta como esta («¿nos afecta o no?») no tiene respuesta rápida.
2. Tener un proceso de gestión de vulnerabilidades técnicas con plazos reales (A.8.8). Este control exige identificar vulnerabilidades de forma oportuna, evaluar la exposición real de la empresa y aplicar las correcciones dentro de un plazo definido según la gravedad. Una falla con 9,2 de severidad no puede quedar en la misma cola de prioridades que una actualización menor programada para el próximo trimestre. El plazo de reacción (horas o días, no semanas) tiene que estar escrito en el procedimiento antes de que ocurra la crisis, no decidido sobre la marcha.
3. Saber quién es responsable de qué proveedor (A.5.19 a A.5.23, seguridad en la cadena de suministro). El caso de PHP expone con claridad un problema que ya habíamos visto en otros contextos: casi nadie sabe, hasta que ocurre una crisis, si la actualización de un componente crítico depende de su propio equipo, de la agencia que construyó el sitio o del proveedor de hosting. ISO 27001 exige que esa responsabilidad quede definida y documentada por contrato, antes de necesitarla.
4. Definir de antemano cuándo y cómo se desconecta un servicio (A.5.29 y A.5.30, continuidad del negocio). Apagar preventivamente un sitio o una aplicación tiene un costo (operativo, comercial y de imagen) que casi ninguna empresa ha evaluado con calma antes de que la decisión tenga que tomarse en caliente. La norma exige planes de continuidad que contemplen explícitamente este tipo de escenario: cuándo una medida temporal de contención, como desconectar un servicio, es preferible a mantenerlo activo mientras se aplica el parche.
5. Comunicar con transparencia incluso sin un ataque confirmado (A.5.5, A.5.6 y A.5.24 a A.5.28, relación con autoridades y gestión de incidentes). Lo que hicieron las agencias de Países Bajos y Finlandia fue, en el fondo, comunicar una medida preventiva antes de que hubiera certeza de un ataque. Para una empresa, eso significa tener ya definido un protocolo de comunicación de crisis (a clientes, a proveedores, a la propia organización) que no dependa de esperar confirmación total del incidente para empezar a actuar.
El error más común de auditoría en este tipo de escenario
En auditorías de sistemas de gestión de seguridad de la información es habitual encontrar una política de gestión de parches que, en el papel, luce completa, pero que en la práctica solo cubre las aplicaciones y los plugins, no el software base del servidor (el sistema operativo, el motor de base de datos, el propio PHP). El auditor que revisa un registro de actualizaciones de WordPress sin preguntar quién actualiza la versión de PHP del servidor, y con qué frecuencia, está dejando pasar exactamente el tipo de brecha que esta crisis puso en evidencia a escala mundial. La pregunta correcta no es «¿tenemos un proceso de actualizaciones?», sino «¿ese proceso cubre también las capas de infraestructura que no administramos directamente nosotros?».
Checklist práctica para esta semana
Primero, confirmar con el equipo técnico o el proveedor de hosting qué versión de PHP (o del software base equivalente) corre cada sitio, aplicación o portal de la empresa, y si ya recibió el parche de emergencia. Segundo, revisar el contrato o acuerdo de servicio con ese proveedor para confirmar, por escrito, quién es responsable de aplicar ese tipo de actualización y en qué plazo. Tercero, si la empresa usa WordPress, Drupal, Joomla o Magento, no asumir que actualizar el gestor de contenido o sus plugins resuelve el problema: la versión del lenguaje base se revisa aparte. Cuarto, definir (si todavía no existe) un criterio escrito sobre cuándo desconectar preventivamente un servicio ante una vulnerabilidad crítica sin explotación confirmada, y quién tiene la autoridad para decidirlo. Quinto, dejar registrada esta crisis como un caso real dentro del procedimiento de gestión de vulnerabilidades, con fecha, decisión tomada y tiempo de respuesta, como evidencia útil para la próxima auditoría.
Qué hacer ahora
Esta crisis no se originó en un error de un empleado ni en una contraseña débil. Se originó en una pieza de software que casi ninguna empresa gestiona de forma activa, porque asume que «eso lo ve el proveedor de hosting». Esa misma suposición, sin un contrato que la respalde ni un inventario que la confirme, es la que ISO 27001 exige cerrar. El punto de partida esta semana es simple: preguntar, con nombre y apellido, quién en la empresa (o en qué proveedor) es responsable de que la versión de PHP, o su equivalente, esté siempre al día.
¿Tu empresa sabe hoy qué versión de PHP o de su software base corre cada uno de sus sitios y aplicaciones, y quién es responsable de mantenerla actualizada? En Profile Empresarial te ayudamos a cerrar esa brecha bajo el Anexo A de ISO 27001, desde el inventario de activos hasta la gestión de proveedores.
Agenda tu diagnóstico con nuestro equipo.
Profile Empresarial. Tu Certificación, Nuestro Compromiso.