By If you upgraded Langflow to 1.8.2 thinking you were patched for CVE-2026-33017, you’re not. JFrog Security Research confirmed that 1.8.2 — the version widely reported as the fix — is still exploitable. The actual patch is 1.9.0. By the time most teams read that advisory, attackers had already been in motion: exploitation began 20 hours after disclosure and has since evolved from cryptominer drops to a full credential-harvesting botnet draining OpenAI, Anthropic, and AWS keys from unpatched deployments.
What the Vulnerability Does
CVE-2026-33017 carries a CVSS score of 9.8. The vulnerable endpoint is POST /api/v1/build_public_tmp/{flow_id}/flow — a public endpoint that lets anyone build a flow without authentication. The root cause is that Langflow passes user-supplied JSON, including Python code embedded in node definitions, directly to Python’s exec() function with no sandboxing. Send a crafted request, run arbitrary code on the server.
Langflow’s default AUTO_LOGIN=true setting makes this worse. Many production deployments ship defaults, meaning the attack surface is wider than it looks on paper.
The 1.8.2 Problem
This is the part most security advisories glossed over. Version 1.8.2 shipped a partial fix that gated access to the vulnerable endpoint — it did not remove the underlying exec() mechanism. JFrog confirmed the bypass works. The real fix in 1.9.0 removes the data parameter from the build_public_tmp endpoint entirely, eliminating the injection point instead of just adding a lock to the door.
If your version check returns 1.8.2, treat yourself as unpatched and upgrade immediately. Verify you are pulling 1.9.0 from the official PyPI package or the official Docker image — not a mirror or a cached intermediate build.
What Attackers Are Actually Doing
The early exploitation wave deployed XMRig cryptominers. That’s almost quaint compared to what followed. Current campaigns leverage the KeyHunter botnet — a NATS-backed worker pool that uses compromised Langflow instances as credential-harvesting nodes. BleepingComputer reports the attack chain plays out as follows:
- Hit the public build endpoint with a malicious flow
- Dump process environment variables
- Extract
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY, OpenAI API keys, Anthropic API keys - Validate credentials via
sts:GetCallerIdentity - Fan out to AWS Bedrock, S3, EC2, Lambda, IAM
- Run expensive AI inference on the victim’s cloud bill — Bedrock, Claude, Llama 3
This is LLMjacking, and it’s more lucrative than mining Monero. Running frontier models through a stolen AWS account compounds fast. One compromised Langflow instance with AWS Bedrock access can rack up thousands in charges before the victim notices.
How Bad Is the Exposure?
CISA added CVE-2026-33017 to the Known Exploited Vulnerabilities catalog on March 25, 2026 — eight days after disclosure, with a federal remediation deadline of April 8. The Hacker News reports more than 15,000 successful exploitation attempts have been recorded across Langflow’s CVE family. Langflow has now accumulated 12 exploited vulnerabilities in 2026 alone. That’s not bad luck. That’s a pattern.
What to Do Now
Check your version first:
pip show langflow | grep VersionIf the output isn’t 1.9.0 or later, start here:
- Upgrade to 1.9.0 — from PyPI or official Docker image only. If you can’t upgrade immediately, install
langflow-nightly 1.9.0.dev18or later as an interim measure. - Rotate all credentials — assume any API key, cloud token, or database credential accessible to the Langflow process has been exfiltrated. Rotation is not optional if the instance was internet-exposed before patching.
- Block internet access — put Langflow behind a VPN or firewall. This tool should never be directly internet-facing.
- Disable public flows — eliminate the unauthenticated endpoint as an attack surface at the application level.
- Audit logs from March 17 onward — search for POST requests to
/api/v1/build_public_tmp/in web server, reverse proxy, and container logs.
The Bigger Point
Langflow sits in front of your most expensive cloud resources. It knows your OpenAI key, your AWS credentials, your Anthropic key. Attackers know this too, which is why Langflow has become a primary target — not for its compute, but for the keys it holds. If you self-host AI tooling, you’re running a credential store. Treat it accordingly: patch cycles, network isolation, credential rotation on breach. The same discipline you’d apply to a production database.
Twelve exploited CVEs in one year is a signal. The question is whether you act on it before or after the next one.
