Attackers Hit Langflow 12 Times This Year. They Are Not Stealing Data, They Are Stealing Your API Keys

Last week a honeypot run by threat intelligence firm VulnCheck started lighting up. Between August 29 and 30, sensors recorded more than 50 exploitation attempts against Langflow within hours. By Monday that number had climbed past 360, and according to the Cloud Security Alliance's research note published September 4, most of the traffic traced back to Russia.

The target was CVE-2026-0768, an unauthenticated remote code execution bug in Langflow with a CVSS score of 9.8. What makes this one worth your time is not the score. It is what the attackers did after breaking in.

They did not deploy ransomware. They did not wipe anything. They opened a shell and went straight for the loot: environment variables holding Langflow superuser tokens, OpenAI API keys, and AWS access keys. They read the cached secret key Langflow stores at /root/.cache/langflow/secret_key. They probed SSH access and shell history for lateral movement.

That is the entire business model now. Your AI framework is a wallet, and someone just walked off with it.

The Year Langflow Became an Attack Surface

If you have not used it: Langflow is an open-source, Python-based visual framework for building AI agents and RAG pipelines. Drag and drop components, wire them into a workflow, run it. It is under the DataStax umbrella, popular enough to have more than 145,000 GitHub stars, and like most AI tooling it was designed for demos and speed, not for sitting on the open internet.

Here is the part that should reframe how you think about AI tooling security. Per the CSA note, CVE-2026-0768 is the twelfth Langflow vulnerability exploited in the wild this year. Before 2026, the platform had exactly one known exploited flaw in its history. Total exploitation attempts across Langflow's 2026 CVE portfolio now exceed 15,000.

The three you should actually know:

• CVE-2026-0768 (CVSS 9.8, actively exploited since late August): unauthenticated RCE. Attackers run code as root, then sweep environment variables for OpenAI keys, AWS keys, and the Langflow secret key. Belgium's Cyber Security Centre, the CCB, rates it critical and confirms the credential-harvesting pattern.
• CVE-2026-33017 (CVSS 9.3, CISA KEV since March 25): unauthenticated RCE through a public flow-building endpoint that executes attacker-supplied Python. Sysdig documented it being exploited roughly 20 hours after disclosure, used for AWS key theft, harvesting .env and database files, and deploying botnet implants. About 7,000 servers saw attack traffic.
• CVE-2026-55255 (CVSS 9.9, IDOR): a cross-tenant bug where any authenticated user could run another user's flow by passing its UUID, with the injected prompt leak api keys. It is inert alone, because flow UUIDs are 122-bit random values you cannot guess. But in the session Sysdig observed on June 25, the operator first called the flow-listing endpoint to enumerate IDs, then replayed them into the vulnerable endpoint. Chain complete.

That last one is my favorite case study in a year full of them, because the fix is so ordinary. Ownership check on a database lookup. PR #12832, shipped in Langflow 1.9.1. Twelve exploited CVEs, and a meaningful share traces back to things a code review should catch.

Why Nobody Locked the Door

This is not a Langflow problem. It is an adoption-speed problem. Langflow went from a demo tool to production infrastructure in the time it takes most teams to schedule a security review. Meanwhile:

• Your AI keys are the new crown jewels. A single Langflow flow routinely embeds an OpenAI or Anthropic key, maybe AWS credentials for a retrieval step, maybe a database connection string. One compromised host can yield access to dozens of connected services.
• The keys are liquid. Stolen data needs a fence. Stolen API keys spend themselves. Attackers run their own workloads on your account, or resell the keys. Sysdig assessed the June operator as opportunistic and financially motivated, monetizing whatever each host yielded: compute for botnets, credentials for resale.
• Self-hosting moved the risk to you. Langflow Cloud gets patched. That VPS you spun up in January and forgot about does not. This is the same pattern I keep seeing in the local-model space: pulling software onto your own hardware means you own the patching, whether you planned to or not.
• Security reviews did not keep up. AI frameworks got adopted bottom-up by developers, the way hip modules and internal scripts always are. Nobody treated them like production infrastructure, so endpoints shipped without authentication or ownership checks.

Full disclosure: I have not run Langflow in production myself. I run my own AI agent infrastructure, built on custom agents I control end to end, and I have never put an AI orchestration platform on a public IP. But the patch-and-rotate checklist below is standard exposure response, and if I did run Langflow, this is exactly what I would do today.

The 30-Minute Lockdown

If you run, or have ever run, a self-hosted Langflow instance, the CSA treats this as an emergency patching and rotation event regardless of whether you have seen signs of compromise. Here is the sequence:

1. Patch first, rotate second (10 minutes)

Upgrade to Langflow 1.9.0 or later immediately, per the Orca Security advisory on CVE-2026-33017. One important detail from that advisory: 1.8.2 was widely reported as patched, but JFrog's security research found it is still vulnerable. If your pipeline says 1.8.2, you are not safe. If you cannot deploy 1.9.0 right away, install the nightly build (1.9.0.dev18 or later) as an interim measure.

pip install --upgrade langflow
# verify
langflow --version

Then restart the service. A patched binary that has not been restarted protects nobody.

2. Rotate every secret the instance could see (15 minutes)

Treat this as mandatory, not precautionary. The observed attackers specifically targeted these, so rotate all of them:

• LLM provider keys: every OpenAI, Anthropic, or other provider key configured in any flow. Revoke and reissue at the provider console.
• AWS access and secret keys: rotate them and check CloudTrail for calls you did not make. The Sysdig report documents AWS-key theft as a primary objective.
• The Langflow secret key: the cached copy at /root/.cache/langflow/secret_key was a direct target. Rotate it and re-encrypt stored credentials.
• The Langflow superuser password, plus any database credentials and SSH keys the host could reach.

One budgeting note worth passing to your manager: API key theft is the rare breach where the damage is a line item you can watch in real time. Watch your provider dashboards this week. If your OpenAI bill doubles, you have your incident indicator.

3. Get it off the public internet (5 minutes)

The attackers hitting honeypots found their targets through mass scanning. If your instance must be reachable, put it behind a VPN or SSH tunnel, or an authenticating reverse proxy. If it does not need to be reachable, bind it to localhost.

# Wrong for a public server
langflow run --host 0.0.0.0

# Right unless you have a specific reason
langflow run --host 127.0.0.1

Then check the logs for the indicators Sysdig documented:

• A User-Agent containing Hello, World or Crypto
• Requests to /api/v1/build_public_tmp/<flow_id>/flow
• An execution marker file at /tmp/lang_pwn
• Repeated GET /api/v1/auto_login calls, and flow enumeration via GET /api/v1/flows/
• Outbound connections to 83.142.209.214 (CVE-2026-33017 activity) or 45.207.216.55 (the June operator)

4. Pull the pattern forward to every AI tool you run (ongoing)

Twelve exploited CVEs in one product is not bad luck; it is a category signal. The same audit applies to n8n (a high-severity expression sandbox escape patched in July), Ollama on 0.0.0.0, ComfyUI, anything in the AI tooling stack that holds credentials and listens on a port. If you would not run Jenkins wide open in 2015, do not run your AI stack wide open now.

If you want a repeatable process, I walked through one in my piece on auditing your stack after NVIDIA bought Hugging Face: inventory what you self-host, identify what holds credentials, patch, and shrink the listening surface. The tooling changes. The checklist does not.

The Pattern Behind the Pattern

The June operator that Sysdig tracked was not sophisticated. A single IP, a constant TLS fingerprint, the same auto_login to flow enumeration to exploit sequence on every wave, and a payload that literally contained the string leak api keys. Sysdig found no evidence of LLM-driven or agentic behavior. It was a scripted toolkit running a fixed playbook, and it worked, roughly 20 hours after the bug was published.

That is the part I would sit with. The bar is not nation-state anymore. It is a commodity playbook exploiting drag-and-drop tools that aggregate the most liquid credentials on the internet, and your move is unglamorous: patch fast, rotate everything, and never put an AI framework on a public IP without authentication in front of it.

Your AI stack is production infrastructure now. The attackers figured that out months before most of us did.

---

I write about AI, developer security, and backend engineering every week, drawn from running my own AI agent infrastructure. Subscribe, it is free.

So, honest question: what AI tooling are you running exposed right now, and are you sure it is patched? Have you ever audited where your API keys actually live?

If you only do one thing today: list every self-hosted AI tool on every machine you own, note which ones hold API keys, and check each against its latest release. That list is your real attack surface, and most people have never written it down.