Langflow RCE Is Back on the Menu — This Time for a Monero Miner
Attackers are still pillaging exposed Langflow instances through CVE-2026-33017, turning forgotten AI workflow servers into XMR mining rigs.
Key points
- Threat actors are actively exploiting CVE-2026-33017, a 9.3-rated unauthenticated remote code execution flaw in Langflow, to deliver a Monero miner.
- Exposed instances reachable on the public internet are the target, consistent with automated scanning campaigns.
- Crypto miners are a leading indicator: initial access brokers follow the same path once a foothold is established.
- Langflow's design lets users define and run Python components, making an unauthenticated RCE effectively a shell-on-demand.
- Patch, restrict network access, and audit for unexpected outbound connections to mining pools.
What is CVE-2026-33017 and why is it serious?
CVE-2026-33017 is an unauthenticated RCE in Langflow, the open-source visual builder teams use to prototype LangChain pipelines, rated 9.3 on the CVSS scale. No credentials required. Langflow's code execution surface has always been thin on sandboxing by design, since it lets users define and run Python components. An unauthenticated RCE in that context is a shell-as-a-service. We first covered this CVE on 30 June 2026; the current campaign shows exploitation has not slowed.
Why is this happening again?
This is the same pattern we've watched with Ray, with Ollama, with every AI framework that ships with auth disabled or optional. A platform engineer spins up a workflow server on an EC2 instance or a GKE node to demo something to the AI team. The demo works. Nobody tears it down. The security group stays wide open on the API port and the binary drifts behind on patches.
Drop an XMRig binary, wire it to a pool, set a low CPU cap so the EC2 bill doesn't spike loud enough to alert FinOps, and you're resident until someone notices. This isn't the first round of mass exploitation against Langflow either. As we reported on 15 June 2026, earlier campaigns used a separate pre-auth flaw to drop malware on exposed servers. Scan, exploit, deploy, persist: the playbook hasn't changed.
Should you worry if you're running Langflow?
Yes, especially if it was stood up for a proof of concept. Crypto miners are the canary. Where a miner lands today, an initial access broker lands tomorrow.
A few operational checks worth running now:
- Find your instances.
kubectl get svc -A | grep langflowis a start, but check ALB target groups and standalone VMs too. Shodan will find them before your security team does. - Patch to the current release. Running anything older than the advisory cutoff is the bug.
- Put it behind an access control layer. IAP on GCP, an ALB with Cognito on AWS, a Tailscale ACL: anything that isn't a public listener.
- Check for unexpected outbound traffic to known mining pools and for XMRig-shaped processes. CPU steal time on neighboring workloads is a useful secondary signal.
What should teams take from this?
The post-mortem will say the Langflow box was never supposed to be production. It was a demo that outlived its usefulness and kept its public IP.
If your AI tooling has a web UI and a code execution primitive, treat it like a Jenkins server from 2017. That's the threat model. Inventory your AI dev tools the same way you inventory your CI runners, because attackers already have.
