Enterprises are standing up AI application frameworks like Langflow faster than security teams can review them. These platforms let teams build and automate generative AI workflows in days instead of months, but that speed comes with a cost: many instances go live with default settings, get exposed to the internet, and never make it onto a security team’s radar.
CVE-2026-33017 shows exactly what happens next. It is an unauthenticated remote code execution vulnerability in Langflow, and attackers are already using it to plant Monero cryptominers on exposed AI servers, disable security tools, and quietly spread to other machines over SSH. It is an active campaign, and it is a preview of how AI infrastructure is becoming the next soft target.
What Is CVE-2026-33017: The Langflow RCE Vulnerability
CVE-2026-33017 is an unauthenticated remote code execution vulnerability affecting Langflow versions prior to 1.9.0. It lives in the /api/v1/build_public_tmp/{flow_id}/flow endpoint, which accepts attacker-controlled flow input through the request body and unsafely processes Python expressions during flow execution, resulting in arbitrary code execution within the Langflow server process, with no login required.
The risk is compounded by Langflow’s default configuration. With AUTO_LOGIN enabled out of the box, an unauthenticated visitor can obtain an authenticated session or token, spin up a public flow, and submit that flow’s malicious code without ever presenting valid credentials.
Affected Langflow Versions and Configuration Risks
All Langflow versions prior to 1.9.0 are vulnerable. Langflow shipped the fix in version 1.9.0, and later development builds, including 1.9.0.dev8, introduced additional hardening by preventing public flows from accepting attacker-controlled input and improving logging.
Risk concentrates on self-hosted, internet-facing instances running with default authentication settings. Because the flaw needs no credentials and no user interaction, a single crafted request against an exposed instance is enough to gain code execution.
Technical Root Cause: Unauthenticated Python Code Execution
Two design decisions combine to create this vulnerability. First, the vulnerable endpoint unsafely processes attacker-controlled Python input during flow execution, allowing arbitrary code execution within the Langflow application process. Second, AUTO_LOGIN being enabled by default means that unauthenticated users can obtain an authenticated session or token needed to reach that endpoint in the first place.
In the campaign researchers tracked, the entire initial compromise came down to one line of injected Python that called out to an external server, pulled down a shell script, and executed it. That script did the rest: creating a hidden directory, downloading the main malware binary, and launching it in the background.
Why This Langflow Vulnerability Is Dangerous for AI Infrastructure
Langflow instances are rarely standalone. They typically run inside AI development environments with access to cloud credentials, internal services, SSH keys, and configuration files well beyond the application itself. Compromising one instance can hand an attacker a foothold into everything connected to it, not just the Langflow server.
The observed campaign also shows attackers going well past a quick cryptomining payday. Once inside, the malware disabled host security controls, killed off rival cryptominers already running on the box, and used any available SSH keys to spread laterally to other Linux systems. That combination — persistence plus lateral movement plus evasion — is the profile of an attacker planning to stay.
Inside the Attack Chain: From Exposed Endpoint to Monero Miner
Fingerprint and target exposed instances
Attackers first fingerprinted the internet for exposed Langflow instances, then targeted the vulnerable /api/v1/build_public_tmp/{flow_id}/flow endpoint directly.
Submit malicious Python payload
Once an instance was confirmed vulnerable, attackers submitted a malicious Python payload that reached out to external infrastructure and pulled down a shell script. That script installed a custom malware binary, established persistence, and prepared the host for mining.
Defense evasion and lateral movement
Before launching the miner, the malware ran a defense-evasion routine: disabling host security controls, terminating other cryptominers already competing for the same CPU cycles, and probing for reachable SSH keys to expand the compromise beyond the initial host.
Deploy Monero miner and establish C2
Only then did it deploy a customized XMRig-based Monero miner and begin communicating with attacker-controlled infrastructure.
Active Exploitation Timeline
Langflow patched CVE-2026-33017 in its 1.9.0 release in March 2026. Shortly after public disclosure, researchers observed a sustained exploitation campaign targeting unpatched, internet-facing instances. Attackers scanned for vulnerable deployments and compromised them to deploy the Monero miner described above.
In some reported cases, exploitation began within hours of the vulnerability details going public, underlining how little time defenders had to patch before attackers moved.
Potential Impact of Successful Exploitation
A successful exploit hands the attacker arbitrary code execution on the Langflow server, which becomes a launchpad for further activity. In the observed campaign, that meant Monero mining, degraded application performance, and inflated infrastructure costs from stolen compute.
The bigger exposure sits one layer down. Because Langflow deployments often carry access to cloud services, APIs, and internal development environments, a compromised instance can leak credentials or open a path into other business-critical systems well beyond the AI workflow it was meant to run.
Indicators of Compromise to Monitor
Organizations should review systems running vulnerable Langflow versions for:
- Requests to
/api/v1/build_public_tmp/{flow_id}/flowcontaining unexpected Python code or command execution attempts - Unfamiliar binaries such as
lambsys, unexpected shell scripts, or unexplained XMRig processes - Newly created persistence mechanisms or unexplained changes to security or firewall configurations
- Unusually high CPU utilization or outbound connections to cryptocurrency mining pools
- Unauthorized SSH activity, particularly reuse of existing SSH keys to reach other internal hosts
Mitigation Guidance for CVE-2026-33017
Upgrade immediately
Move every Langflow instance to version 1.9.0 or later, and apply subsequent releases for the additional hardening introduced after the initial fix.
Turn off AUTO_LOGIN and restrict exposure
Disable default auto-login, and keep Langflow instances off the public internet unless external access is a genuine requirement. Where it is, place the service behind proper access controls rather than exposing it directly.
Assume compromise until proven otherwise
Because active exploitation is already underway, patching alone is not enough. Review application logs, running processes, scheduled tasks, and SSH keys on any instance that was exposed, and rotate any credentials that instance had access to.
Treat AI infrastructure like production infrastructure
Bring internet-facing AI frameworks into the same review cadence as any other public-facing service: inventory what is exposed, remove access that isn’t needed, and patch on the same urgency as customer-facing applications.
How AppTrana Protects Against CVE-2026-33017 Exploitation
AppTrana provides default protection against observed exploit attempts targeting CVE-2026-33017 out of the box. When a crafted POST request targets the /api/v1/build_public_tmp/{flow_id}/flow endpoint carrying a malicious Python command execution payload, AppTrana rejects the request before it ever reaches the Langflow application, returning a 406 Not Acceptable response. This protection is live from day zero for onboarded applications, with no rule tuning or manual configuration required on the customer’s part.
Here is what that blocked exploit attempt looks like in practice: a crafted POST to the flow endpoint met with a 406 Not Acceptable response instead of code execution.
