Langflow CVE-2026-0768: One Endpoint Turns Your AI Stack Into an Attacker's Python Shell

Over the weekend of 30 August 2026, VulnCheck's canary sensors lit up. Fifty successful exploitation attempts in the first few hours; by Monday, more than 360. The target was not a hypervisor, an identity provider, or an edge appliance. It was Langflow — the low-code builder people use to wire up their LLM agents — and the vulnerability, CVE-2026-0768, hands an unauthenticated attacker arbitrary Python execution as root. The first thing the attackers did was read the environment for OPENAI_API* and AWS_SECRET*. The AI stack has become a soft target, and the people breaking into it know exactly which secrets make it worth the trip.

What CVE-2026-0768 actually is

Langflow ships a validation feature so builders can check that a custom component's Python compiles before they drop it into a flow. That check lives at /api/v1/validate/code, and to validate the code it runs it. CVE-2026-0768 is the consequence: a code parameter that reaches the Python interpreter without meaningful sanitisation, exploited as CWE-94 code injection. The CVSS score is 9.8, and the vector matters more than the number — AV:N/AC:L/PR:N/UI:N means network-reachable, low complexity, no privileges and no user interaction required. An attacker who can send an HTTP request to your Langflow instance can run code in the context of the root user.

Python makes this worse than a typical "eval the string" bug. Decorator expressions and default arguments are evaluated the moment the interpreter parses a function — before anything is called. So a payload does not need the validator to execute the function it submitted; embedding the malicious expression in a decorator triggers execution at parse time. Validation, in other words, is exploitation.

The same endpoint, for the third time

If this feels familiar, it should. The /api/v1/validate/code endpoint is a recurring RCE magnet, and CVE-2026-0768 is at least the third serious flaw to come through it.

The lineage is worth stating plainly, because it is the real story:

• CVE-2025-3248 (CVSS 9.8): the same endpoint ran untrusted Python through exec() with no authentication and no sandbox. Langflow fixed it in 1.3.0 by requiring a JWT or API key on the endpoint. It landed on CISA's KEV catalog after being weaponised by the Flodrix botnet — and, more consequentially, by JadePuffer ransomware, in which an autonomous LLM agent ran the entire kill chain: reconnaissance, theft of cloud API keys, lateral movement to production databases, and data encryption.
• Follow-on fixes that were not fixes. JFrog documented that a later "patched" Langflow release remained exploitable — the validation path kept finding a way back to code execution.
• CVE-2026-0768 now arrives unauthenticated again (PR:N). Whatever guard was supposed to stand in front of code execution has been walked around one more time.

"We patched Langflow in March. We're covered." "Which CVE did you patch, and did the fix survive the next release? Because the endpoint that ran arbitrary Python in March is running arbitrary Python again — and this time nobody needs a token."

This is the pattern behind most "we were patched and still got hit" post-mortems: the fix closed one door on one version, and the feature it was guarding — running user-supplied code — was never removed, only fenced. Fences on that feature keep getting jumped.

Why the AI stack is the soft target

Look at what the attackers reached for the instant they had a shell. Per VulnCheck, the requests queried these environment variables and files:

• LANGFLOW_SUPERUSER — the admin login for the Langflow instance itself.
• OPENAI_API* — the model provider keys. Stolen, they become someone else's inference bill and someone else's access to your fine-tuned models and prompts.
• AWS_ACCESS*, AWS_SECRET* — cloud credentials, the pivot from "one AI box" to "your whole account."
• /root/.cache/langflow/secret_key — the application secret that signs Langflow's own sessions.
• .ssh access and .bash_history size — reconnaissance for lateral movement and for what the operator has been doing on the host.

That is not a scattershot smash-and-grab. It is a shopping list written by someone who understands that an AI orchestration server is a credential concentrator. The whole point of Langflow is to hold the keys to your model providers, your vector databases, and the cloud services your agents call. Breach the orchestrator and you inherit all of it in one hop. The 2025 JadePuffer incident already proved the endgame — an agent that stole cloud keys and moved to production databases. CVE-2026-0768 is the same door, reopened, with the same loot behind it.

There is a second front in the same campaign. VulnCheck reports the operators simultaneously exploiting CVE-2026-66066 — "KindaRails2Shell," a CVSS 9.5 flaw in Ruby on Rails' Active Storage. A discrepancy in how Active Storage and libvips read an uploaded image lets an attacker exfiltrate secret_key_base, the Rails master key, database passwords, and cloud tokens, then reach RCE. Notably, the vendor patch (Rails 8.1.3.1) blocks the libvips file-read primitive, but the RCE gadget still executes on a patched server given a valid signature — the exfiltrated secret_key_base is what makes that signature forgeable. Patch and rotate, or the patch is cosmetic.

Two playbooks on the same door

The exploitation isn't monolithic. In VulnCheck's broader Langflow campaign analysis, the same endpoint fed two very different operators — a useful reminder that a single CVE is a door, not a destination:

	"Grab the creds and run"	"Spin up the miners"
First move	Python credential harvester	Cryptominer deployment
Persistence	Proxy agents, SimpleHelp RAT	.sysd / .cache-sysd, .watchdog.sh, cron
C2	IRC beacon (185.117.74[.]172:6667)	Miner pool + botnet check-in
Objective	Cloud/API key theft, lateral movement	Monetise CPU ("pearl-miner" XMR)
Tell	Exfil to 23.234.98[.]182:9999	auditd disabled, PocSuite3 scanning to pivot

Same vulnerability, two economies. The current CVE-2026-0768 wave — source traffic primarily from Russia, dropping a Python credential harvester, proxy agents, a SimpleHelp RAT and an XMR miner — looks like both operators showed up to the same open door at once.

Remediation

Treat any internet-reachable Langflow instance as already compromised until proven otherwise. The recon-of-secrets behaviour means credential theft is the first-order impact; assume the keys are gone and work backwards.

1. Am I affected?

Find your Langflow instances and whether the code-validation surface is reachable:

# Locate exposed Langflow (default port 7860)
curl -s -o /dev/null -w "%{http_code}" http://TARGET:7860/health

# Is the code-validation endpoint reachable without auth?
curl -s -X POST http://TARGET:7860/api/v1/validate/code \
  -H 'Content-Type: application/json' \
  -d '{"code":"1+1"}' -o /dev/null -w "%{http_code}\n"
# A 200/422 that processes the body without a 401/403 = exposed and dangerous.

Shodan/Censys for title:"Langflow" or the default port will show you what an attacker sees. Anything answering from a public IP is in scope.

2. Patch — and don't trust one version bump

Upgrade to the latest Langflow release, then verify the fix held — the endpoint's patch history (CVE-2025-3248 fixed in 1.3.0, later releases re-broken per JFrog) is exactly why "we upgraded" is not the same as "we're safe." After upgrading, re-run the unauthenticated POST /api/v1/validate/code probe above; it must be rejected without credentials. For the co-exploited Rails flaw, upgrade to 8.1.3.1 or later and rotate secret_key_base — the patch alone leaves the RCE gadget reachable with a stolen signing key.

3. Can't patch now? Compensating controls

• Take Langflow off the internet. It was never meant to be a public service. Put it behind a VPN or an authenticating reverse proxy; allow-list the /api/v1/validate/* and build endpoints to internal ranges only.
• Run it non-root, in a container. Root execution is what turns code injection into full host takeover. A hardened, non-root container with a read-only filesystem blunts the blast radius.
• Strip secrets from the process environment. Env vars are the first thing read. Move OPENAI_API_KEY, AWS_SECRET_ACCESS_KEY and friends to a secrets broker with short-lived, scoped tokens so a harvested value expires fast.

4. Hunt for compromise (map to MITRE ATT&CK)

• Initial access — T1190 (Exploit Public-Facing Application): POSTs to /api/v1/validate/code with bodies containing import, os., subprocess, __ (dunder), or decorator syntax (@). Any such request from an external source is an exploitation attempt.
• Execution — T1059.006 (Python): unexpected python/sh children of the Langflow process.
• Credential access — T1552.001 / T1552.005: reads of /root/.cache/langflow/secret_key, .bash_history, .ssh/, and process environment dumps referencing OPENAI_API, AWS_SECRET, LANGFLOW_SUPERUSER.
• C2 / exfil — T1071 / T1571: outbound IRC (:6667) or raw TCP to high ports such as :9999; check against the observed IOCs 185.117.74[.]172:6667 and 23.234.98[.]182:9999, and any SimpleHelp RAT install.
• Persistence / impact — T1053.003 / T1496: new cron entries (e.g. odd /usr/bin/*.sh), .sysd/.watchdog.sh files, auditd being stopped, sustained CPU from an XMR miner.

5. Eradicate + verify

Patching a box that already ran attacker Python does not clean it. Remove implants (RAT, miner, cron, .sysd/.watchdog.sh), then rotate every secret that lived on or near that host — OpenAI and other model-provider keys, AWS access keys, the Langflow secret_key and superuser, any database credentials the box could reach, and Rails secret_key_base if KindaRails2Shell was in play. Rotate after the host is clean, or you hand the new keys straight back. Confirm clean by re-imaging where feasible and watching egress for the C2 signatures above.

Where Zero Hunt fits

The uncomfortable truth of CVE-2026-0768 is timing. The endpoint was re-broken, a scanner found your instance, and 360 hosts were hit before most defenders read the advisory. An annual pentest — or even a quarterly one — is structurally blind to this: your Langflow box may not have existed at the last engagement, and the CVE certainly did not.

This is what Zero Hunt's change-triggered generative pentest is built for. A new asset appearing on the perimeter — a Langflow server a data-science team stood up on Friday — triggers a full campaign within the hour, without waiting for the next scheduled window. The 10-agent swarm's Recon and Exploit agents write a per-target exploit chain against the exact /api/v1/validate/code surface, using a local LLM rather than a public PoC, so the finding reflects your deployment and not a generic template. Every candidate skill is backtested in the AI Gym against a corpus of black-box CVE exercises before it runs against a live asset, and every finding is ECDSA-signed at write time — so when the auditor asks why an internet-facing AI orchestrator with root privileges was never flagged, you have a dated, verifiable answer instead of a shrug. It closes exactly the gap the JadePuffer agent walked through in 2025: an autonomous attacker validating exposure faster than a human schedule can.

And because the first move here is credential harvesting followed by egress — a Python harvester phoning home, a SimpleHelp RAT beaconing, an XMR miner joining a pool — Zero Hunt's AI Traffic Analysis watches the wire for the second half of the story. Its deep-learning model, with four inference heads running at multi-gigabit line rate on the appliance GPU, flags the anomalous outbound session to a never-seen ASN and the miner's steady check-in while the exfiltration is happening, not in the next morning's SIEM digest — which, on a box whose whole job was to hold your model and cloud keys, is the difference between rotating a key and explaining a breach.