El 21 de octubre, las páginas web de muchos gobiernos de toda Europa dejaron de funcionar. Las agencias holandesas, francesas, danesas y finlandesas desconectaron sus servicios públicos después de que salieran a la luz vulnerabilidades críticas en PHP, el lenguaje de programación que utiliza aproximadamente el 75% de las páginas web. Las vulnerabilidades llevaban años ocultas en el código hasta que unas herramientas de IA las descubrieron.

Aunque ya se ha publicado una solución, la IA ha facilitado a los atacantes la ingeniería inversa para averiguar qué ha cambiado. Amazon informó de que su equipo de seguridad detectó un intento de explotación contra un sistema «honeypot» el 17 de octubre, cuatro días antes de que se hiciera pública la información. Los defensores ya iban con retraso incluso antes de que se publicara el aviso.

Mark Kuhr, co-fundador y CTO de Synack, y Nabil Hannan, Field CISO de NetSPI responden a las preguntas generales que se plantean los equipos de seguridad sobre cómo esta historia ilustra la nueva normalidad en la seguridad ofensiva.

1. ¿Cómo consiguen los atacantes actuar más rápido de lo que tardan los defensores en aplicar los parches?

La IA ha hecho que la detección sea barata y rápida, mientras que la corrección sigue dependiendo de personas, pruebas y ventanas de cambio que no se han acelerado al mismo ritmo. El estudio M-Trends 2026 de Mandiant estima que el tiempo medio hasta la explotación ha bajado a unos -7 días, lo que significa que la explotación suele empezar antes de que exista un parche. Además, los atacantes tienen pocos procesos que les frenen. No necesitan aprobación de cambios, pruebas de regresión ni ventanas de mantenimiento.

Esperamos que esto se intensifique. El volumen de vulnerabilidades lleva años aumentando, y la detección impulsada por la IA lo hará subir aún más. Esto ejerce presión sobre todo el ciclo de detección y corrección, y los plazos de los parches, que se miden en semanas, están cada vez más desfasados respecto a los atacantes, que ejecutan agentes automatizados las 24 horas del día. Esto es especialmente cierto en el caso de los sistemas heredados, la tecnología operativa y el hardware que no puede tolerar un reinicio no programado.

2. ¿Nuestro programa de pruebas está a la altura de los atacantes impulsados por la IA?

Para la mayoría de las organizaciones, probablemente no, y la brecha tiene que ver tanto con la cobertura como con la velocidad.

Las pruebas puntuales y orientadas al cumplimiento normativo dejan largos intervalos entre evaluaciones, y los atacantes no esperan a que termine un ciclo de auditoría. Los datos de los clientes muestran avances en cuanto a la velocidad: los clientes de Synack redujeron el tiempo necesario para corregir vulnerabilidades críticas de 63 días a 38. Sin embargo, solo alrededor del 32% de la superficie de ataque en esos datos se somete a pruebas. Corregir los problemas conocidos más rápido no sirve de nada para el 68% que nadie ha examinado.

El alcance es otro de los culpables habituales. Muchas organizaciones mantienen inventarios de activos desactualizados o incompletos, por lo que el alcance que facilitan a los evaluadores deja fuera sistemas de los que no son conscientes. Las pruebas deberían seguir el modo de operar de los adversarios, incluyendo entornos de producción donde se conoce el riesgo. Restringir en exceso una prueba porque afecta a la producción suele costarle a la organización los hallazgos más valiosos. Yendo un paso más allá, las pruebas de penetración continuas proporcionan un flujo constante de señales verificadas en lugar de una instantánea anual.

3. ¿Cómo priorizamos qué arreglar primero cuando la IA encuentra más de lo que podemos gestionar?

Prioriza según la explotabilidad y el contexto empresarial, en lugar de basarte solo en la puntuación de gravedad. Los responsables de seguridad nos han comentado que encontrar más vulnerabilidades no ayuda necesariamente al equipo si no tiene capacidad para solucionar los problemas conocidos.

Ahora tienen que centrarse en priorizar el riesgo, y eso requiere contexto. Empieza a preguntarte: un inventario interno fiable de activos, junto con saber qué controles de seguridad cubren cada activo, muestra qué correcciones reducen el riesgo demostrado. Un fallo de gravedad media en un sistema crítico y accesible puede ser más importante que uno de alta gravedad en un servidor aislado.

· ¿Qué activos están expuestos a Internet?

· ¿Cuáles contienen datos confidenciales?

· ¿Cuáles se conectan a algo que permitiría un movimiento lateral?

4. ¿Cuál es la combinación ideal de personas e IA para la seguridad ofensiva?

Las personas deben aportar contexto, creatividad y responsabilidad, mientras que la IA se encarga del reconocimiento y el descubrimiento a gran escala. La IA suele tener dificultades con los fallos de lógica empresarial, con encadenar debilidades para formar una ruta de ataque real y con juzgar si un hallazgo es relevante en un entorno específico. Las tasas de falsos positivos en la detección impulsada por IA siguen siendo lo suficientemente altas como para que los resultados no validados puedan saturar a un equipo de información irrelevante. Los informes públicos sobre vulnerabilidades descubiertas por la IA también muestran que, con frecuencia, son los expertos quienes guían los modelos y determinan cómo se construye un exploit.

Lo mismo ocurre del lado de los atacantes. Los adversarios son personas que dirigen la IA hacia sus objetivos, y los defensores deben realizar pruebas con la misma creatividad. En nuestros propios proyectos, los evaluadores expertos guían el desarrollo de exploits y utilizan mucho las herramientas de IA, y cada resultado lo valida una persona. Las medidas de seguridad también son importantes. Cuando la IA ofensiva se ejecuta en un entorno de producción, necesita reglas de actuación claras y límites de alcance, además de gente que supervise lo que hace.

5. ¿Qué deberían hacer los equipos de seguridad estos días?

Deberían empezar por la vulnerabilidad inmediata de PHP y, a continuación, utilízarla para poner a prueba su programa de seguridad en general. Los cierres de PHP no serán el último incidente de este tipo. Los descubrimientos seguirán acelerándose, y los equipos que mejor salgan parados serán aquellos que conozcan su superficie de ataque, la pongan a prueba continuamente y centren su limitada capacidad de corrección en lo que más importa. NetSPI+Synack colabora con los equipos de seguridad para mantenerse al día y que no quede nada que se pueda explotar.

1. Haz un inventario de todos los sistemas que ejecutan PHP, incluidos los sistemas de gestión de contenidos y las aplicaciones de terceros, e identifica quién es el responsable de cada uno.

2. Comprueba el estado de los parches y aplica las correcciones, dando prioridad a los activos conectados a Internet.

3. Comprueba si los sistemas expuestos son vulnerables para saber a qué podría acceder potencialmente un atacante.

4. Decide de antemano qué hallazgos deben desencadenar una acción inmediata, para que la próxima revelación no empiece con un debate.

5. Pasa tus activos más críticos de las pruebas anuales a un modelo continuo.