La IA abarató encontrar fallos, no arreglarlos
El caso
El 21 de octubre salieron parches de emergencia para dos vulnerabilidades en el propio PHP que como supongo ya sabéis es el lenguaje que corre detrás de buena parte de la web.
Se registraron como CVE-2026-109618 y CVE-2026-109619 con CVSS 9.2 y el conjunto recibió el nombre de php2shell (Fuente: fortune.com).
Son dos ejecuciones remotas de código, es decir… fallos que permiten a un atacante ejecutar lo que quiera en el servidor sin autenticarse antes.
Lo llamativo no es el fallo en sí sino de dónde salió.
El código llevaba más de una década ahí y era invisible pero se encontró con ayuda de IA (Fuente: fortune.com).
Cloudflare ya confirma explotación activa.
Y varios sitios de gobierno de Reino Unido y Europa además de Wikipedia e Internet Archive se cayeron de forma preventiva (Fuente: fortune.com).
Esa caída preventiva es la parte que conviene leer dos veces ya que no fue un ataque lo que tumbó esos servicios sino que fue la decisión de apagar antes de que llegara.
No es un caso aislado
La misma semana trajo otro fallo con el mismo perfil.
Oracle E-Business Suite tiene una inyección SQL sin autenticar en el servlet TCF, registrada como CVE-2026-101767 con 9.8 que encadena hasta ejecución remota (Fuente: helpnetsecurity.com).
Se parcheó en el CPU del 20 de octubre y ya hay sondeos de explotación.
Censys cuenta 2.246 propiedades web con EBS expuestas (Fuente: helpnetsecurity.com).
Fallos viejos, en software que nadie mira porque lleva años funcionando, encontrados ahora con más facilidad y explotados en cuestión de días.
Y en paralelo CISA metió en KEV PolyShell (CVE-2026-48356, 9.3) y Node2Shell (CVE-2026-111497, 9.2). Sansec ve más de 950 tiendas Adobe Commerce y Magento con un loader en bloques CMS desde julio de 2025 y ya hay intentos de explotación de Brotli contra honeypots (Fuente: thehackernews.com).
Lo que antes tardaba meses en pasar de fallo a exploit, ahora pasa en horas.
El otro lado
La IA no solo encuentra fallos…
Moonshot eliminó el material sobre ciberataques del entrenamiento antes de abrir Kimi K3.1 Pro y aun así el modelo resuelve el 81% de sus tareas internas de exploit, frente al 33% de la versión anterior (Fuente: thenextweb.com).
La capacidad ofensiva no viaja en el dataset yo creo que viaja en el acceso.
Filtrar datos no sustituye a limitar permisos ni a monitorizar qué hace el agente con ellos.
Lazarus, el grupo norcoreano, cifra el malware de Operation FlashHole con criptografía post-cuántica, activo desde julio de 2025 contra empresas surcoreanas de construcción, software y fabricación de cable (Fuente: thehackernews.com).
El vector es un watering hole, es decir, comprometer un sitio que las víctimas visitan de forma habitual, en este caso el software de seguridad obligatorio iniLINE Cross EX (Fuente: thehackernews.com).
Mi lectura es que las tres piezas cuentan lo mismo desde ángulos distintos:
- El atacante acelera en las tres fases, encontrar, armar y esconder.
- El defensor sigue midiendo su velocidad en la cuarta… parchear.
La lectura propia
Durante años el debate fue si la IA iba a encontrar fallos que los humanos no veían.
La respuesta ha llegado y es que sí.
Encontrar un fallo de una década en horas es un avance real pero si el parche tarda semanas en llegar a producción el avance solo beneficia a quien explota antes.
Es el inventario de lo que corre en producción y la velocidad de actualización en la mayoría de organizaciones se mide en meses, semanas siendo optimista.
¿Qué mirar?
- El inventario real. No el de la CMDB, el que responde a un escaneo. Si no sabes qué versión de PHP corre en cada host, el parche del 21 de octubre no te sirve de nada.
- La ventana de parcheo. Cuánto tarda un parche crítico desde que sale hasta que está en producción. Si la respuesta es más de una semana, el fallo de una década ya te ha alcanzado.
- La exposición de EBS. Si tienes Oracle E-Business Suite con el servlet TCF accesible desde internet ese es el punto que hay que cerrar antes de pensar en el resto.
¿Cómo lo probaría en mi laboratorio?
Montaría un contenedor con una versión antigua de PHP de las que llevan el fallo y lo dejaría en una red aislada.
Lanzaría un escaneo con una herramienta de análisis estático asistida por modelo y mediría cuánto tarda en señalar la función vulnerable y adelanto que no hace falta modelos frontera.
Después cronometraría lo que tardo en aplicar el parche y volver a levantar el servicio.
Aquí la cuestión es cuánto tardo yo en cerrarlo !!
Cierre
La IA ha abaratado encontrar fallos pero no arreglarlos y mientras el descubrimiento se mide en horas y el parcheo en semanas o meses, la ventaja la tiene siempre quien ataca.