Attackers are actively exploiting Langflow, the open-source AI workflow builder used for agents, chatbots, and retrieval-augmented generation pipelines, in campaigns aimed at stealing cloud and AI service credentials from exposed servers.
The latest activity centers on CVE-2026-0768, an unauthenticated remote code execution flaw in Langflow’s custom component code validator. BleepingComputer reported on September 1 that VulnCheck observed exploitation attempts against honeypots over the weekend, with attackers querying environment variables and local files for Langflow administrative credentials, OpenAI API keys, AWS access keys, AWS secret keys, SSH access, shell history, and Langflow’s own secret key file.
That makes the story larger than one old bug being rediscovered. Langflow is the kind of system many teams rushed into service while experimenting with AI agents: it connects model providers, API keys, vector databases, internal tools, file stores, prompts, and workflow logic in one place. When those servers are left reachable from the internet, they can become credential concentrators rather than simple demo apps.
Why Langflow is attracting attackers
Langflow gives developers a visual way to assemble AI applications. A team can connect a model, retrieval source, prompt chain, custom Python component, API integration, and deployment endpoint without building the whole orchestration layer by hand. That convenience is also what makes compromised instances valuable: a working Langflow host may already have tokens for OpenAI, Anthropic, AWS, databases, internal APIs, vector stores, or other services wired into its flows.
VulnCheck’s August 28 research described Langflow as a rapidly growing open-source AI tool with more than 153,000 GitHub stars and nearly 10,000 forks. More importantly for defenders, the company said it has seen 11 additional Langflow vulnerabilities targeted and reported as exploited in 2026 after only one known exploited Langflow flaw before this year. Across confirmed canary activity, VulnCheck counted more than 15,000 successful attempts using CVE-2026-0769, CVE-2025-3248, and CVE-2026-5027.
The exploitation pattern is not uniform. VulnCheck described one attacker using a Langflow file-write vulnerability to install a Python credential harvester, proxy tooling, SimpleHelp remote access, cron persistence, and IRC command-and-control. Another focused on cryptomining, using older Langflow remote-code-execution paths, Chisel tunneling, XMR mining, auditd disruption, persistence scripts, and scanning for more targets.
The common thread is access. An AI workflow server may sit close to the credentials that make an organization’s AI experiments useful: model APIs, cloud resources, private data stores, internal automation endpoints, and saved workflow secrets. Once an attacker can execute code on that host, the Langflow process, its environment, its files, and its database become part of the incident.
What CVE-2026-0768 exposes
CVE-2026-0768 was disclosed in January and affects Langflow versions 1.4.2 and earlier, according to public vulnerability records cited by BleepingComputer. The flaw sits in handling of a code parameter supplied to the validate endpoint. Because the input is not properly validated before being used to execute Python code, a remote attacker can run arbitrary code without authentication.
The September exploitation reports are especially useful because they show what attackers actually ask for after they get code execution. The probes are not limited to proof-of-concept commands. They look for names and files that would immediately matter in a real deployment: LANGFLOW_SUPERUSER, OpenAI API variables, AWS access variables, AWS secret variables, Langflow’s cached secret_key, SSH access, and shell history.
That turns remediation into a post-compromise question. Upgrading Langflow closes known vulnerable code paths, but it does not undo a stolen OpenAI key, AWS key, database password, or Langflow administrator credential. Any exposed and vulnerable host should be treated as potentially compromised until logs, credentials, containers, jobs, files, and outbound connections say otherwise.
The broader Langflow flaw chain
CVE-2026-0768 is only one piece of the Langflow risk picture. A March Langflow advisory for CVE-2026-33017 described an unauthenticated RCE path in POST /api/v1/build_public_tmp/{flow_id}/flow, where attacker-supplied flow data containing Python code could be passed into graph building and ultimately executed without sandboxing. The affected versions were Langflow 1.8.2 and earlier, with patched versions starting at 1.9.0.
Another important flaw, CVE-2026-55255, hit the OpenAI-compatible /api/v1/responses endpoint. GitHub’s advisory describes an insecure direct object reference that could let an authenticated attacker execute another user’s flow by specifying that flow’s ID. Sysdig’s analysis noted that exploitation depends on obtaining a valid flow UUID, but that operators observed in the wild combined IDOR activity with more direct RCE attempts.
CVE-2026-5027 adds a separate file-upload angle. Security researchers have described it as a path traversal issue in Langflow’s file upload handling, allowing arbitrary file writes that can become remote code execution in common deployments. In practical terms, defenders should not triage Langflow as a single-CVE problem. The product has seen repeated exploitation across authentication bypass, code injection, path traversal, IDOR, sensitive information exposure, and eval-style execution paths.
What Langflow admins should do now
Langflow users should upgrade to the latest available release. BleepingComputer reported that version 1.11.6 addresses all known flaws as of the September 1 report. Teams should verify the version actually running in production, development, demo, and shadow IT environments, especially Docker containers and instances that were spun up for pilots.
Access controls should come next. Langflow should not be directly reachable from the public internet unless there is a deliberate, reviewed reason. Put it behind SSO, a VPN, a private network, or tightly scoped firewall rules. Disable default convenience settings that weaken deployment boundaries. If a workflow needs public access, expose only the intended application layer, not the full builder, admin surface, API, file upload routes, and validation endpoints.
Run the service with least privilege. Several Langflow issues become more damaging when the process can write broadly, read sensitive files, run as root, or inherit powerful environment variables. Containers should avoid privileged mode, keep mounted volumes narrow, and separate secrets by purpose. Production OpenAI, AWS, database, and internal API credentials should not live in a lightly protected experiment server.
For any Langflow server that was internet-exposed and vulnerable, rotate credentials before assuming the incident is over. That includes OpenAI API keys, AWS keys, database credentials, Langflow superuser credentials, SSH keys, webhook secrets, vector database tokens, and any secrets stored in flows or reachable through environment variables. Review cloud logs for new access keys, unusual API calls, unexpected regions, privilege changes, new compute, data export, or suspicious billing spikes.
Host-level review should include web access logs, container logs, Langflow application logs, shell history, cron entries, new files in writable directories, unexpected Python scripts, remote access tools, proxy binaries, outbound connections, disabled audit logging, and signs of cryptomining. VulnCheck’s canary reporting shows both credential-harvesting and mining playbooks, so defenders should hunt for both quiet secret theft and noisy resource abuse.
The lesson for AI tooling
Langflow is not being targeted because it is obscure. It is being targeted because it sits at the intersection of fast AI adoption, internet-exposed developer tooling, custom code execution, and valuable secrets. The same risk can show up in other low-code AI builders, agent platforms, notebook servers, vector database dashboards, model gateways, and internal AI automation portals.
The useful security boundary is not simply “AI app” versus “normal app.” It is whether the tool can execute code, call external services, store secrets, reach private data, or act on behalf of a user or organization. Once an AI workflow tool has those powers, it belongs in the same risk tier as CI systems, RMM platforms, developer portals, and cloud admin utilities.
For teams still experimenting, the safest move is to assume prototypes can become production attack surface faster than expected. Inventory AI workflow tools, remove public exposure, patch aggressively, isolate secrets, and treat agent builders as privileged infrastructure. Attackers already are.
