Una RCE crítica en IBM Langflow obliga a la CISA a fijar un plazo de urgencia — el mecanismo exacto (dos endpoints encadenados) es justo lo que acabamos de verificar que no existe en nuestro propio código
El 4 de agosto, la CISA inscribió una falla crítica de Langflow (CVSS 9.8) en su catálogo de vulnerabilidades explotadas activamente, con plazo de urgencia al 7 de agosto para las agencias federales estadounidenses — ayer. Langflow, adquirido por IBM con la compra de DataStax, orquesta flujos de trabajo de agentes de IA. Tomamos ese disparador en serio y verificamos nuestro propio código contra exactamente ese tipo de falla, el mismo día.
El mecanismo es simple y brutal: un atacante sin autenticar llama al endpoint /api/v1/auto_login, que, en la configuración por defecto (LANGFLOW_AUTO_LOGIN=true), entrega un token de superadministrador a cualquiera que llegue por red. Con ese token, llama después a /api/v1/validate/code para ejecutar código Python arbitrario vía exec(). Sin autenticación alguna — el exploit funciona sobre una instalación por defecto, sin configurar nada especial. Circula un código de prueba de concepto desde julio, y se ha observado explotación activa en el terreno. No es un incidente aislado para la plataforma: Forkast recoge también CVE-2026-33017 (RCE sin autenticación, explotada 20 h después de la divulgación) y CVE-2026-55255 (una falla IDOR usada para aspirar claves de proveedores LLM, credenciales cloud y secretos de base de datos) — un patrón repetido de fallas en la frontera de autenticación de la pila de infraestructura agéntica.
El reflejo de marketing sería citar esta falla para decir «miren, los demás son vulnerables, nosotros no». Preferimos verificar antes de escribir nada. Un grep completo de todo nuestro backend (server/src/*.ts) lo confirma: ningún endpoint concede un token privilegiado sin autenticación — no existe nada equivalente a auto_login en nuestro código. Los únicos 4 lugares donde AppManager lanza un proceso externo (el chat del asistente, el motor de correos, el envío a la bandeja «Enviados» y la transcripción de audio vía ffmpeg) pasan todos sus argumentos como array, nunca como cadena interpolada — la clase de inyección de shell que este tipo de falla suele explotar no tiene asidero aquí. Y sobre todo: AppManager no expone a ningún usuario un constructor visual de flujos que ejecute definiciones arbitrarias subidas — la arquitectura misma que hace a Langflow vulnerable a esta clase de falla no existe en nuestro caso, no porque la hayamos «asegurado», sino porque no la construimos.
A favor de AppH
- La verificación no es una afirmación al aire: es un grep real de todo el código servidor, hecho el mismo día de la divulgación, y el razonamiento completo (qué archivos, qué llamadas, por qué son seguras) está documentado en nuestro propio registro interno de decisiones.
- La diferencia de arquitectura es real, no cosmética: una herramienta que ejecuta definiciones de flujo subidas por el usuario tiene una superficie de ataque que nosotros sencillamente elegimos no construir.
Contra / el límite honesto
- Tres fallas críticas en 2026 sobre una sola plataforma de agentes muestran que toda la categoría es joven y está poco probada — nuestro propio código de invocación de agente (el chat del asistente) es igual de reciente y no ha recibido el nivel de examen adversarial que una herramienta usada por miles de empresas como Langflow atrae de forma natural.
- Un grep que uno hace por su cuenta no es una auditoría de seguridad independiente — es un punto de partida honesto, no una certificación. Que nadie haya encontrado una falla en nuestro código no significa que no exista, solo que nadie ha buscado todavía con la intensidad que se ve sobre Langflow.
La tentación, ante la actualidad de un competidor que arde, es usarla como prueba de que hicimos bien. Preferimos ser honestos sobre lo que esta verificación demuestra de verdad: demuestra que miramos, un día concreto, con un método concreto, y que no encontramos nada comparable — no que estemos a salvo para siempre. La verdadera lección de Langflow no es «eviten las herramientas de agentes de IA», es que la frontera entre «recomendar una acción» y «ejecutarla» debe seguir siendo estanca incluso bajo la presión de entregar rápido. En AppManager, nuestro asistente puede leer una imagen que le envíes o lanzar un proceso para transcribir una llamada — pero ninguna de esas capacidades le da poder para modificar tus datos de negocio o disparar una acción con consecuencia real sin que un humano la haya validado antes. Sigue siendo cierto hoy porque lo verificamos hoy, no porque lo decretáramos una vez y dejáramos de mirar.
Verificado por un humano de AppH