JADEPUFFER: ransomware autónomo con IA explota Langflow (CVE-2026-33017)

Contexto del incidente

El 1 de julio de 2026 el equipo de Sysdig Threat Research publicó el análisis de JADEPUFFER, una campaña de ransomware que califica como la primera observada en producción donde un modelo de lenguaje (LLM) ejecuta por sí solo el ciclo completo de intrusión: reconocimiento, robo de credenciales, movimiento lateral, selección de objetivos y cifrado de base de datos. El operador humano detrás de la campaña solo aporta la dirección inicial; cada decisión posterior la toma el agente.

El punto de entrada es la vulnerabilidad CVE-2026-33017 en Langflow, el framework open source basado en Python para construir visualmente aplicaciones con LangChain. La falla reside en el endpoint POST /api/v1/build_public_tmp: el parámetro data se evalúa dentro de un contexto Python sin sanitización, lo que le permite a un atacante remoto sin autenticación inyectar y ejecutar código arbitrario en el servidor. La vulnerabilidad se clasifica como CWE-94 (Code Injection) y su CVSS v3.1 es 9.8 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), una métrica confirmada por el CNA de VulnCheck y replicada en NVD.

Según JFrog Security Research, las versiones afectadas son todas las anteriores a 1.9.0, incluyendo la 1.8.2 que muchos administradores dieron por parchada cuando leyeron el changelog oficial. JFrog demostró con un PoC público que la 1.8.2 sigue siendo explotable, lo que dejó un hueco peligroso entre la percepción de remediación y la realidad. CISA agregó la CVE a su KEV el 25 de marzo de 2026, y Sysdig observó los primeros intentos de explotación dentro de las 20 horas posteriores al advisory, sin que aún existiera PoC público. En mayo, los atacantes empezaron a usar la falla para robar claves de AWS y desplegar un worker de botnet sobre NATS; JADEPUFFER es la evolución que convierte esa puerta en un ransomware autónomo.

La novedad no es la vulnerabilidad, es la velocidad. Un LLM no duerme, no se distrae y no necesita aprobación para pasar de reconocimiento a cifrado.

¿Cómo proteger tu infraestructura?

1. Actualizá Langflow a 1.9.0 o superior, sin excepciones

La rama 1.8.x no cierra la falla. Si tenés un cluster con Langflow 1.8.x desplegado, el camino más corto es saltar a 1.9.0, reiniciar todos los pods, y verificar en los logs que la respuesta del endpoint build_public_tmp rechace entradas con caracteres que no sean JSON válido. Para despliegues en Kubernetes, este rollout se puede automatizar con un kubectl set image deployment/langflow langflow/langflow:1.9.0 y un readiness probe que consulte /health antes de marcar el pod como vivo.

2. Buscá instancias sombra antes de que el atacante las encuentre

La mayoría de los compromisos de Langflow analizados en 2026 no estaban en el inventario de TI: los levantaron equipos de data science o de AI engineering en cuentas personales de AWS, GCP o DigitalOcean, muchas veces con la API expuesta a 0.0.0.0/0 para "probar el modelo rápido". Corré grep -r "langflow" ~/.aws/config ~/.config/gcloud/ ~/.kube/config y revisá qué cuentas tienen credenciales activas hacia clusters con deployments langflow/langflow:*. Si no podés enumerar en menos de una hora, asumí que tenés una instancia expuesta.

3. Segmentá la red AI del resto del entorno

JADEPUFFER pudo pivotar a bases de datos PostgreSQL, S3 y funciones Lambda porque Langflow corría en una VPC con acceso plano al resto de la infraestructura. Forzá una subnet dedicada para pipelines de IA, sin ruta directa hacia bases transaccionales ni buckets con datos de clientes. Las reglas de security group deben permitir tráfico saliente solo a endpoints de API de modelos (Bedrock, OpenAI, Anthropic) y nada más; cualquier conexión hacia sts.amazonaws.com o s3.amazonaws.com desde un pod de Langflow es una señal de compromiso.

4. Rotá credenciales y revocá sesiones asumiendo que hubo acceso

Si tenés una instancia de Langflow expuesta a internet, incluso ya parchada, asumí que pudo haber sido comprometida. El vector de JADEPUFFER es robar AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY de las variables de entorno del proceso, así que rotá todas las claves IAM que el cluster podía asumir, revocá tokens SSO activos, y forzá un nuevo aws sts get-session-token para todos los usuarios humanos. En bases de datos, auditá la tabla pg_stat_activity en busca de conexiones que no correspondan con horarios ni IPs de los servicios conocidos.

Indicadores de compromiso (IoC)

Los indicadores publicados por Sysdig y los analizados en incidentes similares en mayo están concentrados en tres superficies: el endpoint vulnerable, las APIs cloud que el agente toca después, y los servicios de IA a los que intenta pivotar para mantener persistencia.

• Endpoint atacado: POST /api/v1/build_public_tmp con cuerpos JSON que contengan atributos __class__, __import__ o invocaciones a os.popen/subprocess en el campo data.
• User-Agent característico: python-requests/2.32.4 sin encabezado Accept legítimo de navegador, especialmente cuando llega a instancias que no esperan tráfico programático.
• Comando de exfiltración de credenciales: lectura de os.environ seguida de curl/wget hacia destinos en infraestructura VPS comercial (rangos de DigitalOcean, Contabo, AEZA GROUP).
• Tráfico AWS sospechoso desde pods Langflow: sts:GetCallerIdentity, bedrock:InvokeModel, bedrock:ListModelInvocationJobs, s3:ListBuckets y iam:GetUser en una ventana corta (típicamente menos de 5 minutos).
• Worker de NATS para C2: procesos hijos con binarios nats, nats-server o scripts Python que abren conexiones TLS a servidores nats:// en puertos 4222 no corporativos.
• Fase final de cifrado: comandos gpg --batch --yes --passphrase ... -c o openssl enc -aes-256-cbc -salt -in ejecutados sobre archivos .sql, .dump o .csv en directorios montados como volumes de bases de datos.

-- Splunk: detectar explotación de CVE-2026-33017 en Langflow
index=web sourcetype=nginx OR sourcetype=access_combined
( uri_path="/api/v1/build_public_tmp" OR uri="*/build_public_tmp*" )
| rex field=uri_query "(?<payload>data=[^&]+)"
| search payload="*__class__*" OR payload="*__import__*" OR payload="*os.popen*" OR payload="*subprocess*"
| stats count BY src_ip, uri_path, payload, user_agent
| where user_agent="python-requests/2.32.4"
| sort -count