CVE-2025-33017: Attackers Are Turning Forgotten Langflow Servers Into Monero Mines

Exposed AI Dev Tooling Is Paying Out — for Attackers

Attackers are actively exploiting CVE-2025-33017, a 9.3-severity unauthenticated remote-code-execution vulnerability in Langflow, to deploy Monero mining software on unpatched, internet-facing servers.

Langflow is a popular open-source visual builder that teams use to prototype LangChain pipelines and other large-language-model workflows. It is approachable, fast to spin up, and — critically — historically ships with authentication disabled or set to optional. That combination makes it a recurring target.

The Same Playbook, a Different Framework

This is not Langflow's first brush with mass exploitation. Earlier in 2025, a separate pre-authentication RCE was used to distribute the Flodrix botnet across exposed servers. The current campaign follows an almost identical script: automated scanning identifies listening Langflow ports, the exploit fires, and a payload drops.

This time the payload is XMRig, the open-source Monero miner. Operators configure it with a deliberately low CPU cap — enough to generate revenue, not enough to trigger a FinOps alert on a cloud bill. The miner sits quietly until someone notices anomalous outbound traffic or elevated CPU steal time on neighboring workloads.

Security researchers have observed the same lifecycle play out against Ray, Ollama, and other AI frameworks. As Verizon's 2024 Data Breach Investigations Report noted, exploitation of public-facing applications accounted for a significant share of breach initial-access vectors — and AI tooling is expanding that attack surface faster than most security teams can track.

Why Langflow Is Structurally Risky

Langflow's core value proposition is letting users define and execute arbitrary Python components inside a visual workflow. That is powerful for prototyping. It is also, without sandboxing, close to a shell-as-a-service from an attacker's perspective.

A successful unauthenticated RCE against a Langflow instance is therefore not just a compute theft issue. It is an initial foothold. Crypto miners are the canary. Where XMRig lands today, an initial-access broker or ransomware affiliate can land tomorrow.

"If your AI tooling has a web UI and a code execution primitive, treat it like a Jenkins server from 2017," is how one security engineer framed the threat model in a widely circulated post-mortem. The analogy is apt: Jenkins went through years of mass exploitation for exactly the same structural reasons.

How 'Demo' Infrastructure Becomes Production Risk

The most common path to exposure is mundane. A platform engineer spins up a Langflow instance on an EC2 or GKE node to demonstrate a pipeline to the AI team. The demo lands well. Nobody decommissions the instance. Six months later, the security group still has `0.0.0.0/0` on the API port and the binary is two minor versions behind the patched release.

This pattern — shadow AI infrastructure that outlives its purpose — is increasingly common as organizations race to prototype LLM workflows. Security teams that maintain rigorous asset inventories for CI/CD runners and container registries often have no equivalent process for AI development tooling. Attackers, who scan continuously, fill that gap quickly.

Training platform engineers and data scientists to recognize that any internet-reachable service with a code-execution surface requires the same access controls as production systems is exactly the kind of behavior change that security-awareness training is designed to produce.

What Defenders Should Do Right Now

Step 1: Find Your Instances

Run `kubectl get svc -A | grep langflow` across every cluster. Check ALB target groups and any standalone VMs. Do not assume Shodan will not find them — it will, and it almost certainly already has.

Step 2: Patch Immediately

The Langflow project has shipped fixes addressing CVE-2025-33017. Any installation older than the advisory cutoff is an unmitigated vulnerability. Patch first; ask questions about migration paths later.

Step 3: Put Auth In Front of Everything

Expose Langflow only through an authenticated proxy. On GCP that means Identity-Aware Proxy. On AWS, an ALB with Cognito is a serviceable control. A Tailscale ACL works. A VPN works. A public listener with no auth does not.

Step 4: Hunt for Compromise Indicators

Check for unexpected outbound connections to known mining pool domains and IPs. Look for `xmrig`-shaped processes or unusual CPU utilization patterns. Elevated CPU steal time on workloads neighboring a compromised instance is a reliable secondary signal worth adding to your cloud monitoring ruleset.

The Deeper Control Failure

Two distinct control failures drive this wave of exploitation. The first is configuration hygiene: internet-facing services with no authentication represent a preventable exposure that has existed in the Langflow ecosystem long enough to enable multiple distinct exploitation campaigns. Security baselines — whether mapped to NIST SP 800-53 or CIS Controls — require that publicly reachable services enforce authentication before any privileged function executes. Langflow's design choice to make auth optional, combined with the absence of meaningful sandboxing around user-defined code, created a structural vulnerability that no patch fully resolves without also changing default behavior.

The second failure is asset visibility. CVE-2025-33017 exists in the wild, but the exploitation succeeds because organizations do not know they have exposed instances to patch. The 2024 Verizon DBIR found that the median time from vulnerability publication to exploitation in the wild is now measured in days, not weeks. Inventory gaps that once represented tolerable lag now represent near-certain compromise windows. Organizations that inventory AI development tooling with the same discipline they apply to production databases will close that window. Those that treat AI tools as exempt from standard asset management will keep finding miners — and worse — on forgotten demo servers.

The operational takeaway is straightforward: if a service can execute code and answer on a public port, it is production infrastructure, regardless of what the ticket that created it says.