El 4 de agosto CISA metió tres fallos en su catálogo de vulnerabilidades explotadas, con plazo de corrección para el día 7. Uno de ellos es un 9,8 en Langflow, una de esas herramientas que alguien monta en una tarde para «probar cosas de IA». El fallo no tiene nada de sutil: hay un endpoint que reparte tokens de superusuario a cualquiera que llegue al puerto y otro que ejecuta el código que le mandes. Encadenados, dan la máquina entera. Y el parche llevaba seis semanas publicado.
Lo interesante no es el fallo. Es que este mismo año se han publicado avisos casi calcados en tres productos distintos de la misma familia —los que montan la capa de IA y de automatización de una empresa— y todos se explican por el mismo malentendido: ese software se diseñó para tu portátil y acabó en un servidor con las credenciales de la empresa dentro.
Qué hace exactamente el fallo de Langflow
CVE-2026-9198, publicado por el PSIRT de IBM y catalogado por CISA como «IBM Langflow». Afecta a Langflow OSS de la 1.0.0 a la 1.10.0. La descripción del NVD es de las que se leen dos veces: un atacante sin autenticar encadena /api/v1/auto_login —que «emite tokens de SUPERUSUARIO a cualquiera que llame por red»— con /api/v1/validate/code —que ejecuta código de usuario mediante exec()— y consigue ejecución remota completa en un despliegue por defecto.
El nombre del primer endpoint cuenta la historia entera. Auto login es una comodidad: arrancas la herramienta en tu máquina y no tienes que teclear usuario y contraseña para trastear. Como comodidad local es razonable. Lo que no es razonable es que esa comodidad siga viva cuando el mismo contenedor se levanta en un servidor con un puerto abierto, que es exactamente lo que pasa cuando el «lo pruebo un rato» se queda. Esta lectura es nuestra; el dato duro es el del NVD, y basta con él.
- →23 de junio de 2026: sale Langflow 1.10.1, la primera versión sin el fallo.
- →17 de julio: el CVE entra en el NVD con un 9,8.
- →4 de agosto: CISA lo mete en el KEV —lo que significa explotación confirmada, no teórica— con plazo para las agencias federales el día 7.
Seis semanas entre el parche y la entrada en el KEV —y en el propio registro del NVD, CISA ya marcaba la explotación como activa desde el 17 de julio, dieciocho días antes—. Ese hueco es el que importa: no lo cierra el fabricante, lo cierras tú. Y el plazo del día 7 solo obliga legalmente a las agencias federales estadounidenses, pero para el resto sirve como termómetro: cuando algo entra en el KEV, ya no estamos hablando de riesgo, estamos hablando de gente dentro.
El mismo supuesto, tres veces
Si esto fuera un producto con mala suerte, sería una anécdota. Mira los otros dos:
- ✓Open WebUI, CVE-2026-45672 (8,8). Antes de la 0.8.12, el endpoint
/api/v1/utils/code/executeejecutaba código Python arbitrario a través de Jupyter para cualquier usuario verificado aunque el administrador hubiera puestoENABLE_CODE_EXECUTION=false. El aviso lo dice con una frase que deberían enmarcar: la configuración dice «desactivado» y el código se ejecuta igual. - ✓n8n, CVE-2026-25049 (9,9 en el NVD). Antes de la 1.123.17 y la 2.5.2, un usuario autenticado con permiso para crear o modificar flujos podía usar expresiones manipuladas en los parámetros para provocar ejecución de comandos en la máquina que corre n8n.
- ✓n8n, CVE-2026-21858 (10,0). De la 1.65.0 a la 1.120.x, ciertos flujos con formulario permitían a un atacante remoto y sin autenticar leer ficheros del servidor. Corregido en la 1.121.0. Y por si faltaba variedad, CVE-2026-59208: con más de un emisor de confianza configurado, n8n resolvía la identidad usando solo el
subdel token e ignorando eliss, así que un token válido de un emisor servía para entrar como el usuario de otro.
Tres productos, cinco avisos, un solo patrón: el modelo de amenaza con el que se diseñaron no es el del sitio donde acaban. Se piensan para una persona, en una máquina, en una red de confianza, y terminan en un servidor multiusuario al que llega media empresa —y a veces media internet— porque así el equipo lo abre desde casa.
Regla uno: un flag de configuración no es un control
El caso de Open WebUI es el más limpio de los cinco y por eso es el que usamos para explicarlo. El interruptor existía. El administrador lo puso en false. Y el endpoint no preguntó. Si al lado de esa instalación había un documento de cumplimiento diciendo «la ejecución de código está deshabilitada», ese documento era falso desde el día uno y nadie podía saberlo mirando la interfaz.
De ahí la regla que aplicamos: un control es algo que puedes verificar desde fuera de la cosa que estás controlando. Si tu única garantía de que no se ejecuta código es que la aplicación promete no ejecutarlo, no tienes un control: tienes una preferencia. Debajo de cada interruptor de la aplicación tiene que haber otro que no dependa de que la aplicación se porte bien —una regla de red, un proxy que autentica, una salida a internet cerrada, un usuario del sistema sin permisos—. Eso, y no una diapositiva, es lo que significa Zero Trust aplicado a algo concreto.
Regla dos: quien puede editar un flujo es administrador
Una plataforma de automatización guarda credenciales de todo lo que conecta: es su función. La clave de la API del CRM, el token OAuth del correo, la contraseña de la base de datos, la clave del proveedor de IA. Todo junto, en la misma máquina, porque si no, no puede automatizar nada.
Ahora júntalo con CVE-2026-25049: quien podía editar un flujo podía ejecutar comandos en el host. En el organigrama, «editor de flujos» suena a un rol menor que se le da a la persona de marketing que monta el envío de newsletters. En la máquina, ese rol y el de administrador son el mismo. El permiso de editar automatizaciones hay que tratarlo como el de administrar el servidor: las mismas personas, el mismo segundo factor, la misma revisión. Y si hay departamentos que no se fían entre sí, no es un tema de roles, es un tema de instancias separadas.
Sí, nosotros también tenemos una de estas
Escribir esto sin decirlo sería hacer trampa: usamos n8n para automatizar tareas internas. Este mismo post acaba en LinkedIn empujado por un flujo suyo. Así que no vamos a decirte que no lo montes, porque lo tenemos montado, y porque para una empresa que no quiere que sus datos pasen por un servicio de terceros, autoalojar sigue siendo la respuesta correcta.
Lo que decimos es otra cosa: el día que lo levantas, deja de ser un experimento. Entra en el inventario con nombre y dueño, tiene ventana de actualización como cualquier otro servicio, y no cuelga de internet «mientras tanto». La frontera entre un piloto y producción no la marca el tamaño: la marca si alguien se entera cuando se rompe. Un contenedor que lleva ocho meses funcionando sin que nadie sepa qué versión tiene ya es producción, se llame como se llame en la reunión.
Cuándo NO montarlo en casa
Tres situaciones en las que preferimos el servicio del fabricante aunque cueste dinero, y lo decimos sabiendo que en las tres perdemos horas facturables:
- →Si no va a tener dueño. Un contenedor sin nadie detrás es peor que una suscripción cara: la suscripción se actualiza sola y el contenedor se queda en la versión del día que se montó. Si nadie se compromete a mirarlo una vez al mes, no lo montes.
- →Si el plan es publicarlo en internet para que el equipo entre desde casa. Esa frase es la que convierte un fallo «para usuarios autenticados» en un fallo para cualquiera. El acceso remoto se resuelve con VPN o con un proxy que autentique delante, no abriendo el puerto.
- →Si el motivo era la privacidad pero no habrá copias ni registros. Autoalojaste para que tus datos no salieran, y ahora tienes las claves de tu ERP en una máquina sin backup y sin logs. Eso no es privacidad; es el mismo problema con menos gente mirándolo.
El repaso de esta semana
Lo que estamos haciendo estos días en las infraestructuras que tocamos, por si te sirve el guion:
- 1.Buscarlo. Escaneo interno de los puertos por defecto —7860 de Langflow, 5678 de n8n, 8080 de Open WebUI, publicado a menudo como 3000— y la pregunta incómoda al equipo: ¿hay algún VPS pagado con una tarjeta personal? Casi siempre lo hay.
- 2.Versiones mínimas. Langflow 1.10.1 o superior (la rama actual va por la 1.11.2, del 4 de agosto), Open WebUI 0.8.12 o superior, n8n 1.123.17 / 2.5.2 o superior y, si usas intercambio de tokens con varios emisores, 2.27.4 / 2.28.1 o superior.
- 3.Sacarlo de internet. Si está publicado, detrás de VPN o de un proxy con identidad. Y revisar qué puede alcanzar hacia fuera: una plataforma que ejecuta código y tiene salida libre a internet es una consola de mando esperando a que alguien la encuentre.
- 4.Credenciales con alcance. Nada de una cuenta de servicio que lo puede todo «para que no dé problemas». Permisos mínimos por integración y, sobre todo, que se puedan rotar sin rehacer los flujos. Si rotar una clave implica tocar treinta automatizaciones, no vas a rotarla.
- 5.Dueño y ventana. Un nombre en el inventario y una fecha al mes para actualizar. Es lo más aburrido de la lista y lo único que evita repetir esta conversación dentro de seis semanas con otro CVE.
Nada de esto es exclusivo de la IA. Es el mismo trabajo que describíamos ayer al hablar de la consola desde la que un proveedor de IT gestiona tus equipos —que, por cierto, volvió a aparecer en el mismo lote del KEV del 4 de agosto con su fallo original—, y la otra cara del inventario de IA que pide el AI Act: el reglamento te obliga a saber qué IA corre en tu empresa por motivos de transparencia; el KEV te obliga a saberlo por motivos bastante más urgentes.
Lo que dijo CISA el día 4
Conviene leer bien lo que significa una entrada en el KEV, porque se suele confundir. CISA no dijo «este software es inseguro». Dijo «alguien lo está usando para entrar». Son dos frases muy distintas y solo la segunda tiene fecha. Langflow, n8n y Open WebUI son proyectos serios que publican sus fallos, los arreglan y documentan las versiones corregidas; los cinco avisos de este post existen precisamente porque alguien hizo bien su trabajo. El agujero no está en el software: está en las semanas que pasan entre que sale el parche y alguien lo aplica en la máquina que nadie recuerda haber montado.
Si en tu empresa hay una de estas plataformas —y las hay en muchas más de las que aparecen en el inventario—, la comprobación de hoy no es un proyecto: es abrir la interfaz, mirar la versión y mirar si desde fuera de la oficina alguien llega a ella. Diez minutos. Es exactamente por dónde empezamos cuando montamos automatización con IA en un cliente: antes de automatizar nada, saber qué hay corriendo y quién puede tocarlo. Si prefieres que lo miremos nosotros, escríbenos: la primera conversación suele durar poco y acabar en una lista corta.
Fuentes (verificadas): CVE-2026-9198 (Langflow OSS 1.0.0–1.10.0, CVSS 9,8 asignado por el PSIRT de IBM, publicado el 17-07-2026, cadena auto_login + validate/code) — NVD; inclusión en el catálogo de vulnerabilidades explotadas el 04-08-2026 con plazo el 07-08-2026, junto con CVE-2026-34486 (Apache Tomcat) y CVE-2026-18556 (N-able N-central) — CISA KEV; valoración SSVC de CISA Coordinator incluida en el propio registro del NVD, con fecha 17-07-2026 y exploitation: active; fecha de publicación de Langflow 1.10.1 (23-06-2026) y de 1.11.2 (04-08-2026) — releases del proyecto; CVE-2026-45672 (Open WebUI anterior a 0.8.12, CVSS 8,8 asignado por el CNA —GitHub—, el endpoint ejecuta código aunque ENABLE_CODE_EXECUTION=false) — NVD; CVE-2026-25049 (n8n anterior a 1.123.17 y 2.5.2, CVSS 9,9 en el NVD) — NVD; CVE-2026-21858 (n8n 1.65.0–1.120.x, CVSS 10,0 asignado por el CNA —GitHub—, corregido en 1.121.0) — NVD; CVE-2026-59208 (token exchange con varios emisores, corregido en 2.27.4 y 2.28.1) — NVD; puertos por defecto — documentación de Langflow y documentación de n8n y Open WebUI. Las lecturas y recomendaciones operativas son nuestras.
¿Sabes qué versión tiene tu plataforma de automatización?
En everyWAN montamos automatización e IA como se monta producción: con inventario, dueño, permisos que se pueden auditar y una ventana de actualización. Sin humo y sin puertos abiertos «mientras tanto».
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN