Threat actors are mass-exploiting CVE-2026-0768, an unauthenticated remote code execution vulnerability in Langflow, the open-source visual builder widely used to assemble LLM agent pipelines. VulnCheck honeypots in the UK logged at least 50 exploitation attempts over the weekend of August 29-30, with the total climbing to 360 observed attacks by September 1 — the majority originating from Russian infrastructure, with a distinct second cluster running Python tooling annotated in Chinese hunting for instances already backdoored by other crews.
What happened
CVE-2026-0768 (CVSS 9.8, CWE-94 code injection) lives in the code parameter accepted by Langflow’s /validate endpoint, part of the custom component editor. The endpoint is designed to let users test Python snippets for custom nodes before wiring them into a flow, but it passes the user-supplied string straight into Python’s execution path with no authentication check and no sandboxing. Any unauthenticated network client that can reach the endpoint can submit arbitrary Python and have it run in the Langflow process — which, in the vast majority of default deployments (Docker images, quick-start installs, managed hosting), runs as root.
The bug was originally reported to Langflow through Trend Micro’s Zero Day Initiative in July 2025 and was publicly disclosed as an unpatched zero-day in January 2026 after the standard ZDI disclosure window elapsed without a vendor fix landing. All Langflow releases through 1.4.2 are confirmed vulnerable; public reporting as of this writing has not surfaced a version that closes the hole, so treat every current deployment as exposed until you’ve verified otherwise against the vendor’s own advisory.
This is the fourth Langflow RCE-class disclosure this year (following CVE-2025-3248, CVE-2026-9198, and CVE-2026-33017), all rooted in the same underlying design problem: components of the flow-building UI that execute attacker-controlled Python without treating that input as hostile.
Attack activity
Once code execution is achieved, VulnCheck’s telemetry shows attackers running a consistent reconnaissance-and-harvest playbook rather than immediately dropping payloads:
- Dumping environment variables that match
LANGFLOW_SUPERUSER,OPENAI_API*,AWS_ACCESS*, andAWS_SECRET*— directly targeting the AI-pipeline credentials and cloud keys a Langflow host is likely to hold - Reading Langflow’s local secret key at
/root/.cache/langflow/secret_key, which can be used to forge signed tokens for the application - Checking for SSH access and the size of
.bash_history, standard footprinting to gauge how much further lateral movement is worth attempting - A second, distinct campaign using Chinese-commented Python is specifically probing for instances already compromised by other actors, apparently to hijack existing backdoors rather than establish new ones — evidence that this vulnerability has been exploited widely enough to attract competing crews
Impact
Langflow instances are frequently deployed with cloud provider credentials, LLM API keys (OpenAI, Anthropic, etc.), and source-controlled flow definitions containing business logic — exactly the assets this campaign is harvesting. Because execution happens as root by default, a compromised host isn’t just an application breach: it’s full control of the underlying VM or container, including anything else co-located on it. Organizations running Langflow to orchestrate agentic AI pipelines in production should assume that any internet-reachable instance has already been probed, and treat successful exploitation as a strong possibility rather than a hypothetical.
Mitigation — do this now
- Take the
/validateendpoint off the internet immediately. If Langflow must be reachable externally, put it behind an authenticating reverse proxy or VPN — do not rely on the application’s own access controls, which this bug bypasses entirely. - Check for a vendor patch before assuming you’re covered. No confirmed fixed release had been publicly documented as of this writing; monitor the Langflow GitHub security advisories and upgrade the moment a fix ships.
- Rotate every credential the Langflow host could reach: cloud provider keys, LLM API keys, the Langflow secret key itself, and any SSH keys accessible from the host filesystem.
- Hunt for prior compromise. Review process execution logs and outbound network connections from the Langflow host for anomalous Python subprocess activity, unexpected outbound calls to unfamiliar IPs, or new SSH keys/cron entries — this campaign has been active since at least August 29.
- Isolate the workload. Run Langflow as a non-root user and inside a container with no more cloud IAM permission than the specific flows it needs to run — default-root, default-full-access deployments are what make this bug catastrophic rather than merely bad.
Sources
- SecurityWeek: Hackers Start Exploiting Critical Langflow Vulnerability
- BleepingComputer: Critical Langflow flaw exploited to steal OpenAI and AWS keys
- The Hacker News: Attackers Exploit Critical Langflow and Rails Flaws in Credential-Probing and C2 Activity
- SecurityAffairs: Hackers Target Langflow in CVE-2026-0768 Attacks
- DEV Community: Exploitation of Langflow CVE-2026-0768 — From Unauthenticated Root RCE to Secret Theft and Lateral Movement