Langflow CVE-2026-0768: la 12.ª vulnerabilidad de Langflow explotada en la naturaleza este año

CVE-2026-0768 es una vulnerabilidad de ejecución remota de código no autenticada en Langflow, el framework visual de código abierto para ensamblar canalizaciones y agentes de modelos de lenguaje grandes, y los atacantes la estaban explotando en la naturaleza a finales de agosto de 2026. La vulnerabilidad reside en el validador de código que hay detrás del editor de componentes personalizados de Langflow: el endpoint validate acepta un parámetro code y ejecuta el Python que contiene, sin autenticación y, en palabras de Zero Day Initiative, "en el contexto de root". La red de honeypots Canary de VulnCheck registró más de 50 intentos de explotación en cuestión de horas desde las primeras detecciones el 30 de agosto de 2026, y más de 360 para el lunes 1 de septiembre, todos contra sensores en el Reino Unido; Caitlin Condon, de VulnCheck, dijo que el tráfico de origen procedía principalmente de Rusia. Las solicitudes no eran ransomware. Leían variables de entorno que contenían credenciales de superusuario de Langflow, claves de API de OpenAI y claves de acceso y secretas de AWS, y luego pasaban a buscar en /root/.cache/langflow/secret_key, .ssh y .bash_history. La entrada completa de este incidente en el archivo, incluidas sus clasificaciones de gravedad, confianza y daño, se encuentra en the Orca AI Incident Archive, junto con los demás registros de robo de credenciales e infraestructura de IA que lo rodean.

Security Affairs publicó su relato el 2 de septiembre de 2026; Ionut Arghire, de SecurityWeek, informó sobre la explotación el día anterior; Bill Toulas, de BleepingComputer, la cubrió esa semana; y la AI Safety Initiative de Cloud Security Alliance publicó el 4 de septiembre una nota de investigación que reitera el mecanismo y añade recomendaciones. Ninguno de los relatos revisados para este artículo nombró a una organización comprometida. Todo se remonta a los propios sensores de VulnCheck y al aviso que Zero Day Initiative publicó en enero.

Un editor que ejecuta lo que se le pide validar.

El principal atractivo de Langflow es que se ensambla una aplicación de IA arrastrando componentes a un lienzo. Los componentes personalizados son Python: el editor permite al usuario pegar código y pulsar validar, y el servidor lo comprueba. Según el aviso ZDI ZDI-26-034, esa comprobación ejecuta el código. La frase de causa raíz del aviso es una sola línea —«la falta de una validación adecuada de una cadena proporcionada por el usuario antes de usarla para ejecutar código Python»— y el resultado es que una única solicitud HTTP no autenticada ejecuta Python arbitrario en el host.

Tres propiedades convierten eso en un incidente en lugar de un informe de error. El vector CVSS es AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, con una puntuación de 9,8: accesible a través de la red, de baja complejidad, sin privilegios, sin interacción del usuario y con pérdida total de confidencialidad, integridad y disponibilidad. El contexto de ejecución es root, y por eso los comandos del atacante que describen tanto Condon como la Cloud Security Alliance apuntan a /root/.cache/langflow/secret_key, el archivo que Langflow utiliza para cifrar las credenciales almacenadas y los datos de sesión. Y el endpoint no solicita credenciales en absoluto, por lo que la exposición depende únicamente de la accesibilidad.

El historial de divulgación influye en cómo se desarrollaron los hechos. La cronología de ZDI registra que el informe llegó a la cuenta de GitHub de Langflow el 18 de julio de 2025, una solicitud de actualizaciones el 11 de septiembre de 2025, una solicitud de la corrección el 10 de octubre de 2025 y un aviso de intención de publicar como zero-day el 10 de diciembre de 2025. ZDI publicó el aviso el 9 de enero de 2026. Los investigadores acreditados son Peter Girnus, William Gamazo Sanchez y Alfredo Oliveira, de Trend Research. La base de datos de avisos de GitHub contiene el mismo texto como GHSA-x5pr-rvjj-j6qm, publicado el 23 de enero de 2026, clasificado como CWE-94 y no indica ningún rango de versiones afectadas. La mitigación indicada por ZDI no es un parche: consiste en «restringir la interacción con el producto».

La divulgación pública sitúa el rango afectado en las versiones de Langflow hasta la 1.4.2 inclusive, la versión contra la que se compiló y probó el módulo de Metasploit añadido posteriormente. Ahí termina la certeza, y la sección sobre correcciones que aparece a continuación explica por qué.

Lo que las detecciones de 360 establecen y lo que no

Los Canaries de VulnCheck son sensores expuestos a internet diseñados para parecerse a lo que un atacante está escaneando. La empresa observó la explotación por primera vez de CVE-2026-0768 el 29–30 de agosto de 2026: más de 50 detecciones en unas pocas horas el domingo, que superaron las 360 para el lunes. Condon, vicepresidente de investigación de amenazas de VulnCheck, describió la actividad en LinkedIn como "una mezcla de reconocimiento y recolección de credenciales", y añadió que el tráfico de origen provenía principalmente de Rusia y que "hasta ahora habían afectado exclusivamente a Canaries en el Reino Unido".

La secuencia de comandos que captaron los sensores es lo bastante específica como para constituir un manual de actuación. Los atacantes consultaron el entorno en busca de LANGFLOW_SUPERUSER, de variables que coincidieran con OPENAI_API y de claves AWS_ACCESS y AWS_SECRET —las tres familias de credenciales que es más probable que contenga un host de Langflow. Leyeron la clave secreta en caché en /root/.cache/langflow/secret_key. Comprobaron el acceso a .ssh e inspeccionaron el tamaño de .bash_history, ambos indicios de si un operador puede moverse lateralmente en lugar de limitarse a leer secretos. Un informe comunitario sobre la cadena de ataque, citado por Cloud Security Alliance, añade que la misma actividad buscó secretos incrustados en árboles de código fuente y archivos .env, exfiltró lo que encontró y comprobó si un operador anterior ya había introducido una puerta trasera en un host antes de añadir su propia persistencia.

Lo que eso establece es que el exploit funciona, que se utilizó contra instancias de Langflow expuestas a Internet y que el objetivo eran las credenciales, no la interrupción. Lo que no establece es una víctima. Los canarios son señuelos; una detección es una solicitud, no un robo confirmado. El archivo clasifica este registro como daño real, y el daño documentado en las fuentes públicas es la ejecución confirmada de código de recolección de credenciales contra sistemas expuestos, no una organización nombrada cuyas claves fueron utilizadas.

Un detalle contradice la versión habitual sobre la divulgación. Según VulnCheck, no existía ninguna prueba de concepto pública para CVE-2026-0768 cuando comenzó la explotación. El aviso llevaba casi ocho meses siendo público y describía la falla con la precisión suficiente como para que alguien construyera un exploit a partir del texto. La interpretación de la empresa, según lo reportado por The Hacker News, es que se trató de una derivación independiente y no de la reutilización de código filtrado.

Doce fallos, quince mil intentos — y dónde se doblan esos números

La estadística que da peso a este incidente proviene de VulnCheck, y merece la pena citarla con las propias palabras de la empresa en lugar de parafrasearla. «Antes de 2026, la evidencia mostraba solo una vulnerabilidad de Langflow conocida por haber sido explotada en la naturaleza», afirmó. «En 2026, las cosas han cambiado rápido». SecurityWeek informa de que VulnCheck sigue «11 vulnerabilidades adicionales que fueron objetivo de ataques y reportadas como explotadas en la naturaleza» durante 2026.

Sume esas y obtendrá doce vulnerabilidades explotadas de Langflow, una de las cuales es anterior a este año. Eso no es lo mismo que doce en 2026, y las fuentes oscilan entre ambos enfoques. El titular de Forkast califica a CVE-2026-0768 como «la 12.ª CVE explotada de Langflow en 2026», mientras que el cuerpo del mismo artículo describe la docena como «11 vulnerabilidades nuevas y una identificada antes del comienzo del año». El título del registro sigue al titular. Si se lee estrictamente, 2026 contabiliza once de las doce, y la duodécima —la que se conocía antes de este año— completa el total.

La cifra de 15.000 tiene un matiz comparable. SecurityWeek, The Hacker News y Forkast atribuyen todos «más de 15.000 ataques exitosos» a tres vulnerabilidades nombradas: CVE-2026-0769, CVE-2025-3248 y CVE-2026-5027. Es un número grande, pero es un recuento de tres CVE, no de todo el catálogo de 2026 de Langflow. Formularlo como intentos de explotación contra el catálogo —como hace el resumen del archivo— es más amplio que lo que publicó VulnCheck.

Las entradas individuales que hay detrás del patrón están documentadas. CVE-2025-3248 era un fallo de inyección de código en el mismo endpoint /api/v1/validate/code, corregido en Langflow 1.3.0 al sustituir la ejecución por una validación de solo compilación, según el aviso de GitHub GHSA-rvqx-wpfh-mfx7 citado por la Cloud Security Alliance, lo que significa que CVE-2026-0768 es la misma clase de error en la misma ruta de código, aproximadamente cuatro meses después de que se publicara esa corrección. CVE-2026-33017, una RCE no autenticada en el endpoint público de compilación de flujos, fue armada en un plazo de aproximadamente 20 horas tras su divulgación en marzo de 2026 y se usó para tomar credenciales de OpenAI, Anthropic y AWS antes de pivotar hacia el criptominado de Monero, según el relato de la Cloud Security Alliance. La nota de la misma alianza del 12 de junio de 2026 abarca CVE-2026-5027, un fallo de travesía de rutas en el endpoint de carga de archivos que los investigadores vincularon con el grupo MuddyWater, patrocinado por el Estado iraní, y su nota del 4 de septiembre registra CVE-2026-55255, una omisión de autorización que permite que un usuario autenticado ejecute los flujos de otro usuario, y que entró en el catálogo Known Exploited Vulnerabilities de CISA el 7 de julio de 2026. Esos cuatro comparten una forma: un endpoint que se saltaba la autenticación o se saltaba la sanitización, en una plataforma cuya función es custodiar credenciales para todo aquello con lo que se comunica.

Por qué merece la pena una plataforma de orquestación

Una instancia de Langflow en producción está configurada con claves de API de proveedores, credenciales de nube, cadenas de conexión a bases de datos y secretos de integración, porque los flujos que ejecuta las necesitan en el momento de la llamada. Por lo tanto, comprometer el host otorga acceso operativo a todos los servicios cuyas credenciales almacena la instancia. Las claves robadas de OpenAI o Anthropic permiten a un atacante facturar la inferencia a la víctima o suplantar a la organización en etapas posteriores; las claves de AWS robadas abren infraestructura mucho más allá del contenedor de Langflow. Esa ventaja, más que cualquier capacidad específica de IA, es lo que buscaban los comandos observados.

El criterio de Cloud Security Alliance es que la recurrencia en cuatro subsistemas distintos de Langflow en un solo año —validador de código, endpoint público de compilación de flujos, carga de archivos y ejecución de flujos de trabajo— apunta a una brecha sistémica en la ingeniería de seguridad, más que a una serie de defectos no relacionados. Esa es la evaluación de la alianza, ofrecida en una nota de investigación, no una conclusión de un auditor independiente, y Langflow no ha respondido públicamente a ella en el material revisado aquí.

Qué se ha corregido y qué sigue siendo ambiguo

Esta es la parte más débil del registro público, y vale la pena ser preciso sobre por qué. El aviso de ZDI no nombra ninguna versión parcheada. La entrada de la base de datos de Snyk para la CVE enumera como versiones afectadas todas las anteriores a la 1.10.1 y recomienda actualizar a la 1.10.1 o superior. Los reportes públicos, incluidos SecurityWeek y Security Affairs, describen el rango afectado como las versiones hasta la 1.4.2, pero no identifican ninguna versión corregida. La Cloud Security Alliance señaló el 4 de septiembre que los mantenedores de Langflow no habían publicado un aviso de seguridad dedicado que nombrara esta CVE, y que los sistemas de seguimiento discrepaban sobre qué versión la había remediado realmente —una ambigüedad que, según la alianza, recuerda un caso anterior de Langflow en el que una versión reportada como corregida seguía siendo explotable.

Langflow sí publicó correcciones en el área correcta, el día correcto. La versión 1.11.6 se publicó el 1 de septiembre de 2026, el lunes en que el recuento de honeypots superó los 360, y sus notas de la versión describen una retroportación de correcciones de seguridad que incluye «cerrar brechas en el escaneo de código de componentes» y «resolver anotaciones sin ejecución» (pull request 14876). La versión 1.12.0 le siguió esa misma tarde. El endurecimiento adicional de la misma ruta de código continuó después: una pull request posterior titulada «evitar que validate_code ejecute importaciones» indica que el endpoint de validación seguía reforzándose semanas después de la primera explotación. Nada de eso constituye una declaración del proveedor de que CVE-2026-0768 esté corregida en una versión determinada, y no se encontró ninguna en las fuentes citadas del registro.

Lo que cambió del lado del atacante está más claro. Un módulo de explotación de Metasploit para la vulnerabilidad se abrió como pull request el 2 de septiembre de 2026 —el mismo día en que publicó Security Affairs— y se fusionó el 8 de octubre de 2026, probado contra Langflow 1.4.2. Cualquiera que sea el estado de la derivación original, explotar esta vulnerabilidad dejó de requerir trabajo original seis semanas después de que comenzara a explotarse.

La respuesta recomendada por Cloud Security Alliance es una secuencia de aplicación de parches y rotación, en lugar de aplicar parches únicamente: verificar la versión en ejecución y pasar a la versión estable actual; tratar cualquier instancia expuesta a internet que esté en una versión afectada como comprometida hasta que se demuestre lo contrario, porque la actividad observada es una recolección silenciosa y no una interrupción visible; y rotar cada secreto al que la instancia pudiera tener acceso —la contraseña de superusuario de Langflow, las claves de API del proveedor, las claves de acceso y secretas de AWS, y la propia clave secreta de Langflow—, volviendo a cifrar las credenciales almacenadas en lugar de simplemente reemplazar el archivo. También recomienda auditar los registros de acceso en busca de solicitudes al endpoint de validación, revisar authorized_keys en busca de claves SSH desconocidas y buscar evidencia de que un operador anterior ya hubiera puesto una puerta trasera en el host. Cuando la plataforma deba seguir siendo accesible, sugiere restringir o deshabilitar el endpoint de validación y dejar de usar claves de larga duración y altos privilegios almacenadas directamente en la plataforma.

Establecido, reportado y no establecido

Se establece:que CVE-2026-0768 es una RCE no autenticada en el endpoint validate de Langflow que ejecuta Python como root, documentado en ZDI-26-034 y replicado como GHSA-x5pr-rvjj-j6qm; que la explotación comenzó el 29–30 de agosto de 2026; que VulnCheck registró más de 50 detecciones en horas y más de 360 para el 1 de septiembre, contra sensores del Reino Unido, con tráfico principalmente desde Rusia; y que las solicitudes observadas se dirigieron a credenciales de superusuario de Langflow, OpenAI y AWS, además de la clave secreta en caché, .ssh y .bash_history. Estos provienen del propio aviso y de la telemetría de VulnCheck según lo informado de forma independiente por SecurityWeek, Security Affairs y The Hacker News.

Reportado, no verificado de forma independiente: cada cifra de detecciones. Las cifras de 50, 360 y 15.000 son datos propios de VulnCheck, publicados por la firma y repetidos por medios que la citan; ninguna segunda red de honeypots ha publicado un recuento que las corrobore. La atribución a infraestructura rusa es asimismo la lectura de VulnCheck del tráfico de origen, no una evaluación que ningún gobierno ni CERT haya respaldado en el material revisado.

No establecido: que alguna organización nombrada haya perdido credenciales. No se ha identificado a ninguna víctima en las fuentes del registro. Tampoco hay una versión parcheada confirmada: ZDI no menciona ninguna, Snyk dice 1.10.1, los informes señalan que está afectada hasta la 1.4.2, y las notas de la versión 1.11.6 describen correcciones de seguridad sin vincularlas con esta CVE. Tampoco el recuento de la «duodécima falla de 2026» es coherente internamente entre sus propias fuentes, como se ha expuesto anteriormente.

La parte que debería preocupar a quienes aplican parches según un calendario

El lapso de ocho meses es el hallazgo. CVE-2026-0768 se publicó como día cero el 9 de enero de 2026, con una descripción técnica lo suficientemente detallada como para reconstruirlo, y no ocurrió nada contra los sensores de VulnCheck hasta el último fin de semana de agosto. Luego llegaron varios cientos de intentos en tres días, de operadores que, según la versión de la empresa, no tenían ningún exploit público que copiar. Lo que sea que mantuvo esas instancias sin parchear durante ocho meses de un aviso crítico público es lo mismo que hizo que la vulnerabilidad valiera la pena explotar cuando alguien finalmente escribió el código.

También cierra un ciclo que abrieron las CVE anteriores de Langflow. La CVE-2025-3248 se corrigió eliminando la ejecución de la misma ruta de validación; la CVE-2026-0768 se ejecuta en esa ruta de todos modos. Una corrección que elimina un comportamiento sin eliminar la decisión de diseño que lo produjo compra tiempo y, en este caso, compró unos cuatro meses.