Langflow RCE has moved from advisory text to commodity monetization: exposed AI workflow endpoints are now being scanned, popped, and used to mine Monero. The key number for operators is 9.3, the CVSS v4 severity score in GitHub's advisory for CVE-2026-33017, because the bug allows unauthenticated remote code execution through a public Langflow flow build endpoint.
That should make every builder running AI workflow tooling a little less casual about dashboards on the open internet. Langflow is used to build and deploy agents, RAG flows, API backed workflows, and experiments that often sit close to model keys, database credentials, vector stores, and cloud tokens. In other words, the thing attackers are abusing for a miner is also a convenient bridge into the parts of your stack that make AI apps useful.
The important read: this campaign is not exotic. It is worse in the boring way. A public AI app endpoint accepted attacker supplied flow data, that data reached Python execution, and attackers turned the foothold into CPU theft, persistence, and SSH based spread. If your Langflow instance is internet reachable, this belongs in the same mental bucket as exposed CI, notebook servers, and admin panels. For more on that pattern, our earlier guide on AI agent prototypes becoming RCE risk covers why agent tooling deserves production grade guardrails before it handles production secrets.
What actually happened to exposed Langflow endpoints?
Threat actors are exploiting CVE-2026-33017 to deploy a Monero mining toolchain against exposed Langflow systems, according to Trend Micro research summarized by The Hacker News. The reported campaign ran over a 19 day window from March 27, 2026 to April 15, 2026, and it used the Langflow bug as the initial execution path.
The vulnerable path is specific and ugly. GitHub's advisory says the unauthenticated POST /api/v1/build_public_tmp/{flow_id}/flow endpoint accepted an optional data parameter, used attacker controlled flow definitions instead of stored database flow data, and passed code to exec() with zero sandboxing in affected Langflow versions up to and including 1.8.2. The patched line is also clear: GitHub lists patched versions as >= 1.9.0 in the same advisory.
NVD tracks the same flaw as a code injection vulnerability and assigns a 9.8 CVSS v3.1 base score, while GitHub's CNA score is 9.3 under CVSS v4.0 in the NVD entry. NVD also records the weakness classes as CWE-94, CWE-95, and CWE-306, which map to code injection, dynamic evaluation injection, and missing authentication for a critical function.
CISA added the vulnerability to the Known Exploited Vulnerabilities catalog on March 25, 2026, with a federal civilian agency due date of April 8, 2026, giving agencies a 14 day remediation window as reflected in NVD's KEV section. That deadline matters even if you do not run a federal network, because KEV inclusion means the bug has crossed from theoretical severity into confirmed exploitation.
The exploit chain in the miner campaign is short enough to fit in an incident channel. The attacker gets code execution through the Langflow endpoint, launches a shell based dropper, fetches a Go based ELF payload named lambsys, then deploys a custom XMRig style Monero miner, according to The Hacker News report citing Trend Micro. The same report says the payload kills rival miner processes associated with Kinsing, WatchDog, Rocke, and Outlaw, disables host level security controls, establishes cron based persistence, and beacons to attacker infrastructure.
The chart shows why the operator response window is uncomfortable: defenders got a 14 day KEV clock, while the observed miner campaign persisted across 19 days.
The miner label can make this feel like a nuisance incident. That is the wrong read. Mining is the cash register, but the access path is remote code execution inside AI application infrastructure.
Why is this worse than another cryptominer alert?
A cryptominer on a random web server is bad. A cryptominer on an AI workflow server is a sign that attackers found a control plane with secrets nearby.
Langflow's own PyPI page describes the package as a platform for building and deploying AI powered agents and workflows, with flows that can be exposed as APIs and MCP servers in the project description. That feature set is exactly why the blast radius is larger than a CPU bill. A compromised workflow host can hold model provider keys, database connection strings, vector database tokens, tool credentials, prompt logs, uploaded files, and internal API routes.
GitHub's advisory lists environment variable exfiltration, API keys, database credentials, cloud tokens, reverse shell access, lateral movement, and data exfiltration from flows and stored credentials as impact paths in its impact section. That list should change your triage language from patch ticket to incident review if the service was reachable before you remediated.
The campaign behavior reinforces that view. The malware can propagate to other systems through reused SSH keys, according to The Hacker News report on Trend Micro's findings. That means the operator question is not only whether Langflow was exploited, but whether the host could authenticate to build boxes, GPU nodes, databases, bastions, or shared admin targets.
Three practical consequences follow.
- Your AI workflow server is production infrastructure. If it can call real model APIs, query real data, or reach internal systems, it deserves the same network posture as CI, not the posture of a demo app.
- A miner is evidence of arbitrary execution. The payload you found may be
lambsysor XMRig, but the vulnerability lets the attacker run something else on the next request. - Secrets near flows need short lifetimes. Long lived provider keys in environment variables are comfortable for builders and comfortable for thieves.
There is also a roadmap lesson. Public sharing features and execution features collide badly when the same endpoint can accept user supplied graph data. The vulnerable endpoint was intended to support public flows, but GitHub's advisory says it incorrectly accepted attacker supplied executable flow data through the optional data parameter in the summary and affected code analysis. If you build agent tooling, the boundary to defend is not the UI login screen. It is every path that turns external input into tool calls, code, graph execution, file access, or credentials.
Which Langflow systems should you treat as exposed?
Start with anything running Langflow <= 1.8.2. GitHub names <= 1.8.2 as affected and >= 1.9.0 as patched for CVE-2026-33017 in the official advisory.
Then check how you installed it. PyPI lists langflow 1.10.1 as the latest stable release published on June 23, 2026, and the release history shows 1.9.0 published on April 14, 2026 on the Langflow package page. If your image, lockfile, Helm chart, Docker tag, or development template still pins a pre 1.9.0 package, treat it as vulnerable until proven otherwise.
Exposure means more than a public DNS record. You should include any host where the Langflow API is reachable from the internet, a partner network, a VPN segment with broad user access, a shared development VPC, or a cloud load balancer path. The GitHub advisory says the vulnerable endpoint requires no authorization header, no API key, and no credentials in its proof of concept path for unauthenticated exploitation.
Also look for inherited exposure. If a notebook, reverse proxy, internal platform portal, tunnel, or preview environment publishes Langflow behind a friendly URL, it still counts. Attackers do not care that you called it staging.
Your search list should include:
- Public endpoints exposing port
7860, reverse proxy routes, or paths under/api/v1/. - Containers or virtual machines with
langflowinstalled through pip,uv, Docker, or baked images. - Shared demo instances with public flows enabled.
- AI workflow boxes with
.envfiles, cloud metadata access, SSH keys, or model provider credentials. - Security events involving
curl,wget,sh, cron edits,chattr,iptables,ufw, AppArmor, SELinux, or suspicious writes under/var/tmp/.
The last item matters because the miner campaign reportedly used standard Linux utilities and host hardening changes rather than a flashy loader. Trend Micro's reporting, as summarized by The Hacker News, says the binary disabled AppArmor, Ubuntu's Uncomplicated Firewall, iptables, SELinux, the kernel NMI watchdog, and Alibaba Cloud's Aliyun agent during execution. That is operationally loud if you collect process, file, and service telemetry.
What should operators do in the next 24 hours?
Patch first. Move all Langflow deployments to >= 1.9.0, and preferably to the current stable package for your environment, because PyPI showed 1.10.1 as the latest stable release on July 1, 2026 after a June 23, 2026 release.
Remove direct internet exposure next. Put Langflow behind SSO, VPN, zero trust access, or private networking, and block unauthenticated access to build, run, flow, and admin style endpoints at the edge. This compensating control is basic, but it catches the class of mistake that made this bug valuable: public routes that unexpectedly reach code execution.
Assume compromise for any exposed pre 1.9.0 system. CISA's KEV listing records active exploitation and requires mitigation or discontinuing use if mitigation is unavailable in the NVD KEV entry. For a public Langflow host, that means you should rotate secrets even if the only obvious symptom is high CPU.
Do the incident work in this order:
- Snapshot before cleanup. Preserve disk, container image digests, process lists, cron entries, auth logs, shell history, and network connections.
- Kill persistence after evidence capture. Check user crons, system crons,
/etc/rc.local, systemd units,/var/tmp/,/tmp/, and immutable file attributes. - Rotate reachable secrets. Include OpenAI, Anthropic, cloud provider keys, database credentials, vector database tokens, Git tokens, webhook secrets, and SSH keys present on the host.
- Invalidate lateral access. Review
known_hosts, SSH agent use, bastion logs, cloud audit logs, and east west connections from the Langflow host during and after March 27, 2026. - Add detections for the pattern. Alert on Langflow processes spawning shells, Python invoking
os.system, web app users callingcurlorwget, and unexpected outbound traffic to bare IP infrastructure.
One hard rule for future deployments: workflow builders should run with no ambient production credentials. Use per flow scoped credentials, short lived tokens, and service accounts that cannot enumerate the rest of your cloud account. If a public flow endpoint becomes an execution endpoint again, the attacker should inherit a cramped sandbox, not your whole AI platform.
What comes next for AI workflow security?
Expect more scanning of AI app infrastructure. The payoff is obvious: these systems often have GPU adjacent compute, model provider keys, database access, and immature exposure controls. Trend Micro's framing, reported by The Hacker News, is blunt: exposed AI application endpoints are becoming another route into enterprise environments through commodity payload delivery.
The uncomfortable part for builders is that the vulnerable feature was close to the product's value. Langflow lets users customize components with Python, and its PyPI project description highlights source code access for component customization as a feature. That means security cannot depend on banning code execution after the fact. The safer architecture is to isolate execution, narrow credentials, authenticate every management path, and make public sharing read from stored trusted objects only.
Watch for three signals over the next few weeks:
- New Langflow advisories around authorization boundaries, public flows, response endpoints, and multi user data isolation.
- Copycat exploitation against adjacent AI builders, notebook apps, agent dashboards, and MCP servers.
- Miner campaigns using AI workflow RCE as the first hop before credential theft or botnet enrollment.
The bet to make now is simple: treat AI orchestration as middleware. Put it in asset inventory. Add it to patch SLAs. Give it logs worth querying. Build a runbook that starts at exposed endpoint discovery and ends at secret rotation. The teams that do this will avoid learning about their AI attack surface from a cloud bill or a miner process named to look like plumbing.
The useful line to draw
If an AI tool can execute user designed workflows, it can execute attacker designed workflows when the boundary breaks. Langflow RCE is the current example. The durable lesson is that agent builders, flow editors, and low code AI platforms need the same suspicion you already apply to CI runners and production admin panels.
Sources
- GitHub Security Advisory: Unauthenticated Remote Code Execution in Langflow via Public Flow Build Endpoint
- NVD: CVE-2026-33017 Detail
- PyPI: langflow package
- Trend Micro: From Langflow to Monero: Inside CVE-2026-33017 Cryptominer
- The Hacker News: Langflow RCE Exploited to Deploy Monero Miner on Exposed AI App Endpoints
