# LangFlow: dos fallos 9.8 abren la puerta de tus agentes de IA > Dos vulnerabilidades 9.8 en Langflow permiten ejecutar código sin cuenta a través de MCP. Solo se corrigen en la 1.13.0 y ya hay módulo de ataque público. > Por José Maldonado · Ciberseguridad · 2026-11-03 LangFlow, una de las herramientas de código abierto más usadas para construir agentes y flujos de trabajo con [inteligencia artificial](https://observatorioblockchain.com/inteligencia-artificial/gemini-4-carbon-ciberseguridad-fairwind/), acumula dos vulnerabilidades críticas que permiten a un atacante sin cuenta ejecutar código en el servidor. Son [CVE-2026-93680](https://www.ibm.com/support/pages/security-bulletin-langflow-oss-affected-multiple-vulnerabilities-2) y CVE-2026-110186, ambas con una puntuación de 9.8 sobre diez, y afectan a todas las versiones publicadas entre la 1.0.0 y la 1.12.8. La única salida es la 1.13.0, lanzada esta semana. El problema no es solo la gravedad, es la superficie. Un despliegue de LangFlow no es una aplicación aislada: es el pegamento que conecta modelos, herramientas y datos, y suele tener credenciales de varios servicios a la vez. Quien ejecuta código ahí no obtiene una máquina cualquiera, obtiene llaves de API, accesos a bases de datos y la posibilidad de manipular las respuestas que otros sistemas dan por buenas. El vector concreto que convierte a LangFlow en objetivo interesante es el protocolo que usa para ofrecer sus flujos como herramientas a otras aplicaciones de IA. Ese canal, pensado para que un agente encuentre y use capacidades ajenas, permite enumerar lo que el servidor expone y, en el peor caso, llegar a ejecutar comandos del sistema operativo sin haber presentado una sola credencial. ## Dos 9.8 y una sola versión que arregla La diferencia entre las dos vulnerabilidades importa poco para quien tiene que decidir esta tarde si actualiza. Una permite saltarse la autenticación y la otra abre la ejecución de código a través de la generación de componentes, y las dos se suman a un tercer problema de exposición de credenciales mal protegidas. Juntas dibujan un escenario en el que el atacante entra, ejecuta y se lleva lo que encuentra. Los rangos de versión afectados son amplios. Cualquier instalación que no haya seguido el ritmo de publicaciones desde la 1.0.0 arrastra el problema, y en proyectos de agentes es habitual quedarse en una versión concreta porque los flujos cambian de comportamiento entre actualizaciones. Esa costumbre, razonable en un laboratorio, se vuelve peligrosa cuando el mismo servidor atiende a usuarios reales. La 1.13.0 corrige, pero exige migrar. Quien tenga flujos personalizados o componentes propios debería probarlos antes de subir el cambio a producción, algo que consume tiempo justo cuando el reloj corre. Es el clásico dilema entre actualizar rápido y actualizar bien, con la diferencia de que aquí el exploit ya está escrito. ## MCP, la puerta que nadie estaba mirando El Model Context Protocol se ha convertido en el estándar de facto para que los modelos usen herramientas externas, y con él llegó una superficie nueva que muchas empresas conectaron sin inventariar. Un servidor MCP que expone acciones sobre el mundo real necesita autenticación, límites y registro de actividad, y en la práctica muchos despliegues se montaron para una demo y se quedaron en producción. LangFlow ofrece sus flujos como herramientas MCP, lo que multiplica el interés de atacarlo. Si consigues listar esas herramientas y una de ellas ejecuta código o consulta datos sensibles, tienes una vía directa sin necesidad de entender la lógica de negocio. La enumeración de herramientas deja de ser un paso de reconocimiento menor y se convierte en la vulnerabilidad en sí. Ya hay un [módulo público de pruebas de penetración](https://thehackernews.com/2026/11/critical-langflow-flaws-could-let.html) que se conecta al endpoint MCP sin credenciales, abre sesión y lista las herramientas disponibles. El módulo no ejecuta código, pero demuestra lo fácil que resulta confirmar si un servidor concreto es vulnerable. Con esa información, el resto es cuestión de paciencia y de qué herramientas exponga cada instalación. ## ¿Por qué no está en KEV y aun así corre prisa? Ninguno de los dos fallos figura en el [catálogo de vulnerabilidades explotadas](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) de la agencia estadounidense, aunque LangFlow ya tiene [seis entradas](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) allí, la última de agosto con CVE-2026-9198. La ausencia de una entrada no significa calma: el catálogo refleja explotación confirmada, y esa confirmación llega con retraso, especialmente en software de nicho. La historia de la herramienta juega en contra de la tranquilidad. Seis fallos previos explotados indican que hay interés real en atacarla, y un producto que acumula ese historial suele estar en el punto de mira de cualquiera que busque acceso inicial barato a entornos de IA. La probabilidad de que el séptimo se sume a la lista no es especulativa. Existe además un motivo estructural. Los equipos que montan agentes suelen priorizar que funcionen, no que resistan, y la presión por entregar demos rápidas deja configuraciones abiertas que después nadie revisa. El fallo del software es la mitad del problema, la otra mitad es el despliegue. ## Cómo comprobar si tu instalación está expuesta La primera comprobación es de versión. Si el servidor ejecuta cualquier build anterior a la 1.13.0, está afectado por los dos fallos críticos, sin excepciones. La segunda es de exposición, y es la que suele pasar desapercibida: buscar endpoints MCP abiertos, paneles de administración accesibles desde fuera y servicios que respondan sin pedir credenciales. La tercera es de contenido. Un despliegue de LangFlow suele guardar claves de API de varios proveedores, cadenas de conexión a bases de datos y credenciales de herramientas internas. Si el servidor estuvo expuesto antes de actualizar, esas credenciales deben rotarse todas, no solo la del modelo principal. Conviene además revisar el registro de accesos de las últimas semanas buscando sesiones sin autenticación, llamadas al endpoint de herramientas y errores repetidos en la enumeración de componentes. Un atacante que prueba herramientas deja un rastro bastante reconocible si alguien conserva los logs el tiempo suficiente. Y hay una medida que no depende de LangFlow. Los servidores que ejecutan acciones sobre el mundo real no deberían vivir en la misma red que las bases de datos de clientes. Segmentar esa capa reduce el daño de cualquier fallo, presente o futuro, sin necesidad de acertar con la predicción de cuál será el próximo. ## El inventario que falta La pregunta que debería activar una revisión no es si tu empresa usa LangFlow, sino cuántos servidores con capacidad de ejecutar acciones andan sueltos en la red interna. Los equipos de plataformas han pasado años inventariando bases de datos y servicios web, y la mayoría no tiene una lista equivalente de herramientas de IA conectadas a datos sensibles. Actualizar a la 1.13.0, rotar las credenciales que hayan pasado por esos servidores y revisar qué herramientas MCP están expuestas es el mínimo. Después toca algo más difícil: decidir qué puede hacer un agente sin supervisión. Un flujo que crea usuarios, mueve ficheros o consulta información de clientes merece el mismo trato que una cuenta con privilegios, porque en la práctica lo es. La lección del caso es incómoda para el entusiasmo actual. Construir agentes es fácil, conectarlos a todo también, y la seguridad se ha quedado en el paso que nadie quiere dar porque frena la demo. Con dos 9.8 sin parchear en el mercado, la cuenta de esa deuda empieza a llegar. Lo que viene no depende de LangFlow, depende del sector. Cada herramienta de orquestación que se popularice repetirá el patrón: primero la adopción, luego los avisos. Si algo aprendimos con los servidores de aplicaciones hace quince años es que la capa intermedia es donde se acumula el riesgo, y ahora esa capa intermedia habla con modelos.