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

Threat intelligence firm VulnCheck and the Cloud Security Alliance report that attackers exploited CVE-2026-0768, an unauthenticated remote code execution vulnerability in the open-source AI framework Langflow, more than 360 times in a single day, with most traffic traced to Russia. The attackers targeted environment variables containing API keys and superuser tokens, marking the twelfth Langflow vulnerability exploited in the wild this year, with total attempts exceeding 15,000. Experts urge immediate patching to Langflow 1.9.0 or later, noting that version 1.8.2 remains vulnerable.

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 https://labs.cloudsecurityalliance.org/research/csa-research-note-langflow-ai-framework-credential-harvesting 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. 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: .env and database files, and deploying botnet implants. About 7,000 servers saw attack traffic. 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. 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: 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. 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: 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. Treat this as mandatory, not precautionary. The observed attackers specifically targeted these, so rotate all of them: /root/.cache/langflow/secret key was a direct target. Rotate it and re-encrypt stored credentials. 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. 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: User-Agent containing Hello, World or Crypto /api/v1/build public tmp/<flow id /flow /tmp/lang pwn GET /api/v1/auto login calls, and flow enumeration via GET /api/v1/flows/ 83.142.209.214 CVE-2026-33017 activity or 45.207.216.55 the June operator 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 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.