IA

Langflow, el constructor de agentes de IA: dos fallos críticos permiten ejecutar código sin autenticación

IBM documenta cuatro vulnerabilidades en Langflow, el constructor de agentes de IA: dos permiten ejecutar código sin autenticación y el único parche es la versión 1.13.0.

Fernando Luis

— 10 min read

Hay una clase de software que hace un par de años era de nicho y hoy es infraestructura de producción: los constructores de agentes de IA. Herramientas donde dibujas un flujo, lo conectas a un modelo, a una base de datos, a un buzón de correo y a un ERP, y el resultado lo consume un chatbot o un proceso automático que corre mientras nadie mira. Langflow es una de las herramientas más conocidas de esa categoría: código abierto, se instala con pip o con Docker, publica sus flujos como herramientas mediante el Model Context Protocol (MCP) y se usa tanto para prototipos como para entornos internos de empresas que ya están en producción.

El boletín de seguridad de IBM actualizado el 29 de octubre recoge cuatro vulnerabilidades en Langflow OSS. Dos de ellas son críticas, con una puntuación CVSS de 9.8, y no requieren cuenta: una permite saltarse los controles de autenticación y la otra permite ejecutar código arbitrario en el servidor. Según el boletín, están afectadas todas las versiones publicadas desde la 1.0.0 hasta la 1.12.8, y el único arreglo es la 1.13.0.

Y hay un detalle que convierte el asunto en algo más incómodo que un CVE más. Desde el 22 de septiembre, Metasploit tiene un módulo público que se conecta al punto de MCP de Langflow sin credenciales, abre una sesión y lista las herramientas que el servidor ofrece. El módulo no ejecuta código: es de reconocimiento. Pero describe el camino exacto, con las peticiones HTTP y el identificador de sesión, y está en el repositorio público de la herramienta que todo el mundo usa para auditar redes.

Qué es Langflow y por qué el caso importa

Langflow es un editor visual de flujos. Cada nodo es un componente: un modelo de lenguaje, un componente de Python que ejecuta código, una consulta a una base de datos, un cliente de correo, un buscador web, un servidor MCP. Los componentes se conectan entre sí y el conjunto se ejecuta como una unidad. Eso lo hace cómodo para prototipar y peligroso para producción, por una razón muy concreta: el resultado de esa composición se guarda en la base de datos del servidor de Langflow, junto con las claves de API que necesitas para que los modelos funcionen.

Hay dos hechos de arquitectura que explican por qué los cuatro fallos tienen la forma que tienen.

El primero es que Langflow expone sus flujos como herramientas de MCP. El protocolo sirve para que una aplicación de IA, como un cliente de escritorio o un editor con agentes, use herramientas sin integrarse con cada una. Langflow es un servidor de MCP, y por tanto escucha en un endpoint HTTP propio, con una interfaz distinta de la API web de la aplicación.

El segundo es que el producto genera código. Un "componente" de Langflow es código Python que se guarda y se ejecuta en el servidor. El asistente agéntico integrado escribe componentes a partir de una descripción en lenguaje natural. Esta capacidad es el producto: es lo que hace que una herramienta como Langflow ahorre horas de trabajo. También significa que la generación de código es una primitiva de ejecución disponible para quien llegue al endpoint.

Los cuatro avisos de IBM

El boletín de IBM, publicado el 28 de octubre y actualizado al día siguiente, describe cuatro vulnerabilidades propias de Langflow. Las dos primeras son las críticas:

  • CVE-2026-93680, con 9.8 y vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Un atacante remoto sin cuenta puede saltarse las restricciones de seguridad por una autenticación inadecuada (CWE-287).
  • CVE-2026-110186, también con 9.8 y el mismo vector. Un atacante remoto sin cuenta puede ejecutar código arbitrario por un control inadecuado de la generación de código (CWE-94).
  • CVE-2026-110193, con 8.8 y privilegios bajos (PR:L). Una cuenta de bajo privilegio puede hacer que el asistente agéntico genere o envíe código de componente usando patrones que no están bloqueados, lo que acaba en ejecución de comandos del sistema operativo en el servidor. También es CWE-94.
  • CVE-2026-110192, con 6.5. Con una cuenta se puede obtener información sensible por credenciales que no están suficientemente protegidas.

La diferencia entre los dos críticos no es acádémica. El primero (CWE-287) es un fallo de autenticación: el servidor acepta a quien no debería. El segundo (CWE-94) es un fallo de control sobre la generación de código: el servidor ejecuta lo que le mandan. Los dos juntos significan que no hace falta una cuenta para llegar al servidor ni una cuenta para ejecutar en él.

El resumen del propio boletín describe los cuatro problemas con otras palabras: una remediación incompleta del control de seguridad de inicio de sesión automático, ejecución de código agéntica a través de una biblioteca de terceros, exposición de credenciales de API inyectadas por el operador que se puede alcanzar sin la autorización prevista, y ejecución remota de código sin autenticación explotable mediante la enumeración de herramientas de MCP. El mismo boletín incluye además avisos de vulnerabilidades conocidas en dependencias del proyecto, entre ellas la biblioteca Hono.

El mecanismo: enumerar herramientas sin credenciales

El caso más interesante para un lector técnico es el de la enumeración por MCP, porque no requiere ninguna vulnerabilidad exótica. Basta con hablar el protocolo como se debe.

El camino es éste. El servidor de Langflow expone un punto de eventos enviados por el servidor, el protocolo SSE, en la ruta /api/v1/mcp/sse. Una petición GET a esa dirección, sin cabeceras de autenticación y sin sesión, devuelve una respuesta 200 con el identificador de sesión. Con ese identificador, el cliente inicializa una sesión de MCP y pide la lista de herramientas. Eso es todo: no hay que adivinar rutas, no hay que forzar una autenticación, no hay que construir nada raro. El endpoint responde a quien pregunte.

El módulo de Metasploit, publicado el 22 de septiembre y firmado por Richard Howe, hace exactamente eso. Está clasificado como auxiliar de recopilación, no como módulo de explotación: se conecta al punto de eventos, extrae el identificador de sesión de la respuesta, inicializa la sesión de MCP y recoge la información de las herramientas, que guarda en el almacén de botín de Metasploit con formato JSON. Su valor es doble: sirve para reconocimiento manual y deja documentado, paso a paso y con las cabeceras correctas, el procedimiento que necesita cualquiera que quiera ir más allá.

Dos matices importan para medir el alcance real. El autor del módulo declara como afectadas las versiones 1.5.0 a 1.11.4, un rango más estrecho que el de IBM, que abarca de la 1.0.0 a la 1.12.8. Y el módulo se probó sobre la 1.8.4 con el inicio de sesión automático activado. Ninguna de las dos cosas contradice a IBM; más bien encajan con lo que veremos en el apartado siguiente.

Lo que se obtiene al enumerar no es una lista de nombres sueltos. Es el inventario de capacidades del servidor con sus esquemas: qué herramientas existen, qué parámetros aceptan, a qué apuntan. Para un atacante es un mapa. Para quien lo lea después, es la respuesta a una pregunta muy concreta: qué expone mi instalación.

El código que genera código

El segundo hecho estructural del producto es el que explica los dos fallos de la familia CWE-94, y merece un párrafo aparte porque es la parte más trasladable de este caso.

En Langflow, un componente es código. El asistente agéntico genera ese código a partir de lo que le pidas, y el servidor lo guarda y lo ejecuta. Eso convierte la generación de código en una capacidad de primera clase del producto, no en una función accesoria.

Con una cuenta de bajo privilegio, el fallo CVE-2026-110193 permite pedir al asistente que genere o envíe código de componente empleando patrones que las validaciones no bloquean, y ese código acaba ejecutando comandos del sistema operativo en el servidor. Sin cuenta alguna, el CVE-2026-110186 llega al mismo sitio por la vía de la generación de código. Son dos caminos distintos hacia la misma capacidad: ejecutar lo que el sistema acaba de escribir.

Conviene poner esto en su contexto. En una aplicación web corriente, un endpoint que compila y ejecuta el código que le mandes sería una vulnerabilidad inconcebible. En un constructor de agentes es exactamente la función principal del producto. La misma capacidad que hace útil la herramienta, la que permite crear un conector nuevo en treinta segundos en lugar de en una tarde, es la que un atacante explota. No es un defecto de la implementación de una idea ajena: es la idea misma, que en este caso carece de un control de autorización a la altura de lo que permite.

El inicio de sesión automático: un ajuste por defecto de desarrollo en un paquete de producción

La pieza que cierra el círculo está en el código, y se lee en dos versiones consecutive del propio proyecto.

En la etiqueta 1.12.8, el fichero de configuración de autenticación define el campo AUTO_LOGIN con default=True y una descripción que avisa en mayúsculas: "SECURITY WARNING: This bypasses authentication and should only be used in development environments. Set to False in production. This will default to False in v2.0". El comentario de los desarrolladores al lado del valor por defecto dice, sencillamente, "TODO: Set to False in v2.0".

En la 1.13.0 el valor por defecto pasa a ser False y la descripción se reescribe: "Enabled by default on development branches; official release packages and tags default to False. Set LANGFLOW_AUTO_LOGIN=false to require authentication". Es decir, la corrección no es borrar el ajuste, es mover el valor por defecto y dejar constancia de que la variable de entorno sigue mandando.

Lo que IBM llama una "remediación incompleta del control de seguridad de inicio de sesión automático" se entiende mejor con estos dos extractos delante. El control no era una comprobación de identidad, era un interruptor. Con el interruptor activado, que era lo que venía de serie en el paquete publicado, el servidor autentica al visitante por él y lo hace con permisos de superusuario. Por eso el módulo de Metasploit se validó con el inicio de sesión automático activado: sin ese ajuste, el camino que describen esos avisos no es idéntico.

Conviene ser honesto con un límite de la información pública: el boletín no aclara de forma explícita si los servidores con el inicio de sesión automático desactivado son vulnerables al eludir la autenticación. Lo que sí sabemos es que el rango de versiones afectadas incluye todas las publicaciones, que el ajuste venía activo por defecto hasta la 1.12.8 y que el propio módulo de Metasploit se probó en ese escenario.

Qué hay que hacer hoy

Si tienes Langflow desplegado, el orden de las acciones es este.

  • Sube a la 1.13.0. El boletín no ofrece mitigación alternativa para quien no pueda actualizar: no hay workaround oficial. Con pip, la actualización es "pip install --upgrade langflow==1.13.0"; con Docker, la imagen langflowai/langflow:1.13.0 conservando los datos persistentes del despliegue.
  • Prepara la cuenta existente. Si el servidor usaba inicio de sesión automático, al actualizar dejará de funcionar solo. La guía de instalación de Langflow explica cómo dejar la cuenta lista para entrar con contraseña. Y ojo con el paso siguiente.
  • No borres ni reinstales para recuperar el acceso. La documentación advierte de que esa maniobra puede eliminar permanentemente tus flujos. Si te quedas fuera tras actualizar, sigue los pasos de recuperación que enlaza la propia guía.
  • Haz una copia antes de nada. Base de datos, clave secreta y ficheros subidos. Si no lo copiaste todo, este es el único momento para hacerlo.
  • Haz inventario de la exposición. ¿Quién tiene Langflow en la red? ¿El puerto 7860 es accesible desde fuera? ¿El punto de MCP responde en la red interna sin filtro? El caso típico es un servidor de pruebas que acabó en producción porque el flujo funcionaba bien.
  • Rota las claves. Si alguien pudo ejecutar código en esa máquina, el botín no es la caja: son las claves de API de tus modelos, los tokens de tus conectores de base de datos, correo y ERP, y los prompts y flujos que guardaste. En Langflow esas credenciales viven en la base de datos de la propia herramienta, y el aviso CVE-2026-110192 va precisamente de credenciales mal protegidas.
  • Busca señales en los registros. Peticiones al punto de eventos de MCP desde direcciones desconocidas, enumeraciones de herramientas fuera de horario, creación o modificación de componentes que nadie recuerda haber hecho.
  • No esperes a CISA. Los dos fallos críticos no estaban en el catálogo de vulnerabilidades explotadas conocidas en su actualización del 30 de octubre, pero hay otros seis fallos de Langflow ya listados, el más reciente el CVE-2026-9198 en agosto. El módulo de Metasploit es público desde el 22 de septiembre. El catálogo llega tarde por proceso de tramitación; el módulo va con adelanto.

Lo que deja el caso

Hay varias lecciones aquí, y no todas son sobre Langflow.

La primera es que el constructor de agentes ha dejado de ser un juguete. En cuanto un flujo dibujado en un editor visual entra en producción, hay una aplicación en el centro de la arquitectura, con usuarios, con secretos y con un puerto abierto. Merece el mismo control que cualquier otra: inventario, autenticación real, parches y monitorización.

La segunda es que MCP crea una superficie de autorización que antes no existía. Enumerar herramientas es leer la interfaz de tu sistema, y lo hace posible un endpoint que responde a un GET. Cada capacidad que expones por MCP necesita su propia decisión explícita sobre quién puede verla y quién puede invocarla. Publicar "tus agentes como herramientas" es una decisión de seguridad, no una función de compatibilidad.

La tercera es que los valores por defecto de desarrollo en paquetes publicados son un patrón, no un accidente aislado. Un "solo para desarrollo" escrito dentro de un pip install es una promesa que casi nadie cumple, porque la primera parada de un prototipo suele ser un servidor compartido. La 1.13.0 corrige este caso concreto; el patrón sigue ahí en el resto del ecosistema.

La cuarta es que una remediación incompleta merece nombre propio. Un control que se puede desactivar con una variable de entorno no es un control de seguridad: es una configuración que alguien puede cambiar sin querer, en un despliegue que nadie recuerda. La autenticación de Langflow era una bandera, y una bandera no es una frontera.

La quinta es que la generación de código es una primitiva de ejecución. En un producto cuyo valor consiste precisamente en escribir y ejecutar código a petición, la autorización sobre quién puede pedirlo y qué se le permite generar es el producto entero, no un detalle de la implementación. Si tu herramienta escribe y ejecuta código, tienes una interfaz de ejecución remota, y hay que tratarla como tal.

Y la sexta es la más importante para un constructor de agentes: el botín no es el servidor, es el mapa. Enumerar herramientas dice qué puedes hacer y con qué credenciales. En Langflow, las claves de tus modelos y las de tus conectores están en la base de datos de la herramienta que construye los agentes. Quien se loguea en una sesión de MCP de tu servidor no busca la caja: busca las llaves de todo lo que esa caja puede abrir.

Fuentes

Read more