En una sesión de mayo de 2026 que los investigadores reconstruyeron más tarde, bastó una sola instrucción enviada por Telegram para poner en marcha toda una campaña de intrusión. El resto —buscar servidores vulnerables en internet, elegir el exploit adecuado, lanzarlo y evaluar el resultado— lo hizo un agente de inteligencia artificial sin que nadie volviera a tocar el teclado. Lo documenta la unidad de investigación Unit 42 de Palo Alto Networks, que atribuye la actividad a un actor de habla china conocido por los alias knaithe y KnYuan.
Merece la pena leer el caso sin dramatismo. De los cerca de 460 objetivos que el agente llegó a atacar, solo un puñado cayó. Y la operación salió a la luz porque el propio agente cometió un error de configuración —arrancó un servidor web desde su directorio de trabajo— y dejó a la vista todo su instrumental: claves, guiones de ataque y hasta el registro de sus propias decisiones. Que una máquina hackee sola y sin fallos no ocurre, al menos todavía. Lo que sí ha cambiado es más concreto: rastrear internet en busca de una víctima cuesta ahora una fracción del tiempo y del dinero de antes.
- Qué ha pasado. Un actor de habla china usó el modelo DeepSeek como motor de decisión de un agente de código abierto (Hermes Agent) para automatizar la búsqueda y explotación de servidores expuestos, orquestándolo todo por Telegram.
- Alcance real. Unos 460 objetivos atacados y un número reducido de compromisos confirmados por Unit 42, sobre todo exfiltración de memoria en dispositivos Citrix NetScaler.
- Por qué importa. La novedad no es la potencia, sino la velocidad: el reconocimiento y la explotación que antes llevaban horas se comprimen en minutos y se ejecutan en paralelo.
- Qué hacer. Reducir la superficie expuesta, inventariar y parchear las herramientas de desarrollo de IA accesibles desde internet, priorizar los CVE del catálogo KEV de CISA y vigilar el comportamiento, no solo las firmas.
Cómo se orquestó la campaña
El montaje es sencillo de describir, y por eso mismo inquieta. DeepSeek actúa como el cerebro que decide; Hermes Agent, un marco de agentes de código abierto, le da manos: puede abrir una terminal, ejecutar órdenes y salir a internet. Entre ambos, Telegram funciona como puesto de mando —un canal de mando y control improvisado— desde el que el operador humano lanza la tarea inicial y, a partir de ahí, se aparta.
De una instrucción a cientos de objetivos
En la sesión que Unit 42 reconstruyó, el agente partió de una vulnerabilidad crítica en Langflow, CVE-2026-33017, una herramienta para construir flujos de agentes de IA. Buscó un exploit público en GitHub, localizó con el buscador FOFA 84 servidores de Langflow accesibles desde internet y los evaluó uno a uno. Después pidió al modelo que investigara por su cuenta fallos de más valor: encontró una prueba de concepto para una cadena de vulnerabilidades en n8n, otra plataforma de automatización de flujos de trabajo. Todo ello sin intervención humana.
Siete vías de entrada, todas asomadas a internet
El repertorio del agente no era exótico: vulnerabilidades conocidas en productos accesibles desde internet, la mayoría divulgadas hace poco. La tabla resume las siete, descritas a nivel conceptual —qué exponen— sin detalle que sirva para reproducir un ataque.
| Producto | Identificador | Qué expone (a nivel conceptual) |
|---|---|---|
| Langflow | CVE-2026-33017 | Ejecución remota de código sin autenticación en una herramienta para construir flujos de agentes de IA. |
| n8n | CVE-2026-21858 y CVE-2025-68613 | Cadena de fallos en una plataforma de automatización de flujos de trabajo. |
| Citrix NetScaler | CVE-2026-3055 | Lectura de memoria del dispositivo, con posible filtración de datos sensibles. |
| Apache Tomcat | CVE-2026-34486 | Elusión del cifrado entre nodos de un clúster (componente EncryptInterceptor). |
| Marimo Notebook | CVE-2026-39987 | Ejecución de comandos en cuadernos de datos accesibles desde internet. |
| Palo Alto PAN-OS | CVE-2026-0300 | Fallo en el sistema operativo del cortafuegos. |
| Windows (extensiones IKE) | CVE-2026-33824 | Fallo en el componente IKE de VPN de Windows. |
Vulnerabilidades citadas por Unit 42 en la campaña. Descripción conceptual; no constituye una guía de explotación.
La ironía es doble: dos de los blancos —Langflow y n8n— son precisamente herramientas para construir automatizaciones y agentes de IA. La misma clase de software con la que se montó el ataque forma parte de la superficie de ataque que ese ataque busca. Es el patrón que ya rastreamos en el robo de modelos de IA: la pila de IA empieza a ser herramienta y objetivo a la vez.
Qué reveló de verdad el caso
Tres datos ordenan la lectura. El primero: la autonomía no equivale a omnipotencia. Frente a 460 intentos, Unit 42 confirma un número reducido de éxitos —sobre todo exfiltración de memoria en equipos Citrix NetScaler— y un intento de secuestro de sesión contra una entidad gubernamental que la propia investigación describe como sospechoso, no confirmado. El agente probaba mucho y acertaba poco.
El segundo: el descuido delató la operación. El agente arrancó sin querer un servidor web desde su directorio personal y dejó accesible el arsenal completo: claves de API, guiones de explotación, listas de objetivos y el historial de la terminal. La automatización que daba escala al ataque fue también la que lo puso al descubierto.
El tercero, y el que debería ocupar a cualquier responsable de seguridad: lo que se ha comprimido es el tiempo. Unit 42 calcula que el conjunto de DeepSeek, Hermes Agent y utilidades asociadas redujo a minutos lo que antes eran cientos de horas de trabajo manual de selección de objetivos. No hace falta un adversario más hábil; basta con uno más rápido y barato, capaz de repetir el ciclo en paralelo contra miles de direcciones.
La ventana entre el aviso y el ataque se estrecha
El caso de Langflow ilustra el cambio. La vulnerabilidad CVE-2026-33017 es crítica (CVSS 9,3 según CISA) y permite ejecución remota de código sin autenticación. Su explotación comenzó unas 20 horas después de publicarse el aviso, según la telemetría de Sysdig que recogen varios medios. CISA la añadió a su catálogo KEV, y los analistas de JFrog descubrieron que la versión supuestamente corregida seguía siendo explotable. Súmalo todo: cuando la explotación se automatiza, el margen entre divulgar un fallo y sufrir un rastreo masivo se mide en horas, no en semanas. Y las herramientas de desarrollo de IA —Langflow, n8n, cuadernos como Marimo— se han colado en la superficie expuesta de muchas organizaciones sin pasar por el inventario ni por el ciclo de gestión de vulnerabilidades. Nadie las vigila como a un servidor de producción, pero están tan expuestas en internet como cualquiera de ellos.
Detección: mirar el comportamiento, no la firma
Ninguna de estas técnicas trae una firma nueva que copiar a un antivirus. Se detectan por lo que hacen, no por lo que son. Estos son los rastros que merece la pena cazar en la telemetría, planteados como hipótesis de threat hunting:
- Ráfagas de intentos de explotación contra CVE divulgados en los últimos días, en especial desde una misma dirección y contra rangos amplios: la huella del rastreo automatizado.
- Peticiones a los puntos de acceso de herramientas de IA (Langflow, n8n, Marimo) desde orígenes que no deberían hablar con ellas, o desde equipos donde nadie recuerda haberlas instalado.
- Indicadores de lectura de memoria en dispositivos Citrix NetScaler y respuestas anómalas en sus interfaces de gestión.
- Descargas de pruebas de concepto desde repositorios públicos ejecutadas en servidores que jamás deberían compilar ni traer código de GitHub.
- Tráfico de salida hacia la API de Telegram o hacia canales de mando y control efímeros desde cargas de servidor, no desde puestos de usuario.
El hilo conductor es la anomalía de comportamiento: un servidor que de pronto se comporta como la estación de trabajo de un atacante —descarga utilidades, escanea, habla con servicios de mensajería— es una señal, aunque cada acción por separado parezca legítima.
Qué defensa sigue valiendo
La parte tranquilizadora es que los fundamentos no cambian; solo se vuelven más urgentes. Cuatro prioridades ordenan la respuesta.
Primero, encoger lo que se ve desde fuera. Cada servicio accesible desde internet es un blanco potencial para un agente que rastrea sin descanso, así que conviene saber en todo momento qué se expone y por qué.
Segundo, tratar las herramientas de IA como lo que son: software de producción. Inventariar los Langflow, n8n y cuadernos de datos que haya sueltos por la organización, parchearlos y, si nadie los usa, retirarlos. Una auditoría de seguridad de agentes y MCP ayuda a ver esa capa que casi nunca aparece en los diagramas.
Tercero, gobernar a los propios agentes como identidades. Un agente que actúa por su cuenta es, a efectos de control, una identidad no humana: necesita credenciales acotadas, permisos mínimos y trazabilidad de cada acción, igual que exigiríamos a un usuario con privilegios.
Cuarto, acelerar el parcheo de lo que de verdad se explota. Priorizar por el catálogo KEV y por la evidencia de explotación —no solo por la puntuación CVSS— y fijar plazos que la organización cumpla de verdad. Con la explotación automatizada, un CVE crítico expuesto ya no da semanas de margen.
En clave normativa, nada de esto es nuevo: NIS2 y DORA ya exigen gestionar la exposición de los activos accesibles desde internet y parchear a tiempo. La automatización del atacante solo estrecha los plazos con los que se juzgará si esas obligaciones se cumplieron.
Lo que cambia y lo que no
El titular tentador —«la IA ya hackea sola»— se queda corto y largo a la vez. Corto, porque describe una capacidad que aún falla mucho: 460 intentos para un puñado de éxitos, y una operación descubierta por un error del propio agente. Largo, porque insinúa una ruptura que todavía no existe: el adversario no es más listo que ayer, solo llega antes y a menor coste. Para el defensor, la consecuencia es práctica. Los fundamentos siguen siendo los de siempre —conocer lo que se expone, parchear lo que se explota, detectar lo que se comporta raro—, pero ahora se juegan a contrarreloj. Un servidor expuesto con un fallo sin parchear ya no espera semanas a que alguien repare en él: puede tener compañía en cuestión de horas.
Este artículo describe técnicas de ataque con fines defensivos: detección, contención y gobierno. No incluye código explotable ni pasos reproducibles. Las recomendaciones de detección y parcheo deben validarse en un entorno controlado antes de aplicarse en producción.
Fuentes y atribución: el análisis de la campaña se basa en la investigación pública de Unit 42 (Palo Alto Networks) con la información disponible en la fecha de publicación. Las cifras de objetivos y compromisos proceden de esa investigación; las atribuciones a un actor o grupo pueden evolucionar a medida que avanza la información.