langflow CVE-2026-33017: the unauth RCE in your team's AI prototyping tool is exfiltrating your AWS keys in under 20 hours flat

# langflow CVE-2026-33017: the unauth RCE in your team's AI prototyping tool is exfiltrating your AWS keys in under 20 hours flat

if you self-host langflow, the open-source visual builder for llm agent chains, and you have it exposed to the internet on the default port 7860 "just for team demos" — your aws keys, openai keys, anthropic keys, and pinecone creds are gone. probably already gone. probably gone within 20 hours of you first standing it up.

cve-2026-33017 was disclosed 2026-03-17. the first sysdig honeypot got probed at 16:04 utc the next day. the first successful credential exfil happened in under 25 hours from disclosure. cisa added it to the kev catalog days later. and it's still being mass-exploited in 2026-05 because the bug class is exactly the kind that gets reintroduced — this is the second rce through the same exec() call in this codebase. the first one (cve-2025-3248) got patched. they put the call back in.

the bug, the exploit chain, the payload, and how to actually clean up if you're already running it.

#the bug

unauthenticated rce. one http post. no creds.

POST /api/v1/build_public_tmp/{flow_id}/flow

note the _public_ in the path. the endpoint was wired up to be reachable without auth on purpose, for "share a flow" workflows. inside, the code path runs through 10 function calls and lands at src/lfx/src/lfx/custom/validate.py:397:

exec(compiled_code, exec_globals)

no sandbox. no allowlist of safe builtins. no ast inspection. the attacker controls compiled_code end-to-end via the node_code field in the post body. one line, full python execution as the langflow process user.

this is the second time. cve-2025-3248 (april 2025) was the exact same bug. it got patched. someone refactored the validation code and put the exec back in. the regression shipped through the testing pipeline because there was no integration test guarding against "an unauth http request reaches exec()." there is now. it's late.

#the active-exploitation pattern

attackers find vulnerable langflow instances the obvious way:

1. shodan / censys query for the langflow login favicon and port :7860
2. http verb-curl-grep loop: post to /api/v1/build_public_tmp/*/flow with a benign payload to confirm the endpoint exists and responds, then weaponize
3. successful instances get scanned in under an hour after standing up — researchers' honeypots have logged this consistently since march

the payload that actually lands is interesting. it doesn't just establish a reverse shell. it's purpose-built for ai infrastructure:

step 1, environment dump. os.environ over the wire. the attacker exfils every variable matching:

• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_DEFAULT_REGION
• OPENAI_API_KEY, OPENAI_ORG_ID
• ANTHROPIC_API_KEY
• HF_TOKEN, HUGGINGFACE_TOKEN
• PINECONE_API_KEY, WEAVIATE_API_KEY
• SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY
• GITHUB_TOKEN, GH_TOKEN

step 2, persistence. drops a go binary named worker-linux-amd64 (~9.4mb), wires it as a systemd unit keyhunter-worker.service. the worker uses the utls library to spoof tls fingerprints (so the outbound c2 traffic looks like a normal chrome connection at the packet level), and bundles gitleaks v8.24.3 for in-process secret scanning of any path it touches.

step 3, c2 join. the worker subscribes to nats topics on 45.192.109.25:14222:

• task.scan_cde — scan you for additional cardholder data env contents
• task.scan_web — scan you for additional exposed services
• task.validate_aws — confirm the stolen aws keys still work
• task.validate_ai — confirm the stolen openai/anthropic keys still work

results get published back on result.scan and keyhunter.result.

#why nats

a quick aside on why every modern infostealer botnet is using nats now. nats is a high-throughput pub/sub message broker — think redis pub/sub on steroids, with first-class clustering, durable jetstream queues, and built-in mtls. it's used legitimately by every microservices shop. that's the point. nats workers are extremely cheap to scale to thousands of bots, the wire protocol is binary and looks indistinguishable from legitimate microservice traffic at the network layer, and the controllers can fan-out one command to ten thousand bots in milliseconds.

botnet operators noticed in mid-2025. the technique now has a name: nats-as-c2. sysdig published a writeup. you should expect to see it on every "ai-adjacent" rce campaign going forward.

#affected versions and the fix

• vulnerable: all langflow ≤ 1.8.1
• patched: 1.9.0 (pr #12160, commit 73b6612e, merged 2026-03-10 — before public disclosure)

upgrade path:

pip install -U langflow==1.9.0
# or for the docker users:
docker pull langflowai/langflow:1.9.0

then never expose langflow on 0.0.0.0:7860 again. put it behind one of:

• tailscale (members of your tailnet only)
• cloudflare access (oauth gating)
• a reverse proxy with basic auth (truly minimal but better than nothing)
• vpn-only access for the ml team

#iocs to grep for

if you've been running langflow exposed at any point since march, assume compromise until you've verified otherwise. things to look for:

files on disk:

• worker-linux-amd64 (the 9.4mb keyhunter go binary)
• keyhunter_worker.py
• deploy.sh
• worker.yaml
• new systemd unit at /etc/systemd/system/keyhunter-worker.service

network connections:

• outbound to 45.192.109.25:14222 (nats c2)
• outbound to 159.89.205.184:8888 (staging)
• any persistent outbound tls session with a non-corporate destination at high port numbers

process behavior:

• the langflow container process making os.environ reads followed by outbound network calls
• new long-lived python processes spawned by the langflow process
• gitleaks invocations in your langflow host's syslog

http logs:

• any request matching /api/v1/build_public_tmp/*/flow from non-team source ips
• post bodies containing node_code fields with python literal-block content

#24-hour response checklist

# 1. take it off the internet right now
docker stop langflow || systemctl stop langflow

# 2. check for compromise
ss -tnp | grep -E "45\.192\.109\.25|159\.89\.205\.184"
systemctl list-units | grep -i keyhunter
find / -name "worker-linux-amd64" -o -name "keyhunter_worker*" 2>/dev/null
grep -r "build_public_tmp" /var/log/

# 3. rotate every key the container could read.
#    do this from a different machine (the keyhunter worker can detect
#    revocation cli invocations on the compromised host).
aws iam list-access-keys --user-name <user>
aws iam create-access-key --user-name <user>
aws iam delete-access-key --access-key-id <OLD> --user-name <user>

# rotate openai (platform.openai.com → api keys)
# rotate anthropic (console.anthropic.com → settings → keys)
# rotate hugging face (huggingface.co → settings → tokens)
# rotate pinecone (app.pinecone.io → api keys)
# rotate supabase service-role (only via dashboard)
# rotate github pats (github.com/settings/tokens)

# 4. cloudtrail audit on aws — anything anomalous in the window
#    between when you first exposed langflow and now?
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=<langflow-iam-user> \
  --start-time "$(date -u -d '60 days ago' +%FT%TZ)"

# 5. patch
pip install -U langflow==1.9.0

# 6. before restart: put auth in front of it
#    docker compose with cloudflared sidecar, or a tailscale serve config,
#    or a caddy reverse proxy with basic_auth.

#the bigger lesson: ai/ml infra is the new jenkins

the threat model on ai tooling is the same threat model that destroyed jenkins teams in 2017-2019. one unauth rce gets you:

• aws keys with broad iam (because the engineers granted *:* "just for the demo")
• openai/anthropic keys (worth real money on dark-pool inference resale)
• pinecone / weaviate vector db creds (training data + customer embeddings)
• github pats with repo access (because the rag pipeline pulls docs from internal repos)
• supabase service role (full db dump)

the engineering culture around ai/ml prototyping in 2026 is exactly where webapp prototyping was in 2017: tools deployed to public ips "just for the team," default credentials, no auth gate, lifecycle of "i'll lock it down later," :latest image tags, no version pinning, and broad iam for convenience. the same teams that would never run a jenkins server on 0.0.0.0 in 2026 are running langflow, dify, flowise, automatic1111, comfyui, ollama, openwebui, lobe-chat, and a dozen others wide open.

every one of those tools is an exec call away from being the next langflow.

at valtik we do external scans against client perimeters specifically looking for self-hosted ai tooling without auth. it's not in any standard pentest checklist yet. it should be. if you want a second set of eyes on what your ai team has stood up over the last six months, contact us.

sources:

• thehackernews langflow writeup: https://thehackernews.com/2026/03/critical-langflow-flaw-cve-2026-33017.html
• sysdig — nats-as-c2: https://webflow.sysdig.com/blog/nats-as-c2-inside-a-new-technique-attackers-are-using-to-harvest-cloud-credentials-and-ai-api-keys
• barrack ai — exec rce deep dive: https://blog.barrack.ai/langflow-exec-rce-cve-2026-33017/
• csa research note: https://labs.cloudsecurityalliance.org/research/csa-research-note-cve-2026-33017-langflow-ai-pipeline-rce-20/
• gbhackers writeup with full ioc list: https://gbhackers.com/langflow-cve-2026-33017-exploited/