CVE-2026-33017: Langflow RCE Exploited in Under a Day
Just saw the report on CVE-2026-33017 regarding Langflow, and the timeline is concerning. Threat actors managed to weaponize this vulnerability within 20 hours of public disclosure. For those running AI/LLM pipelines, this is a critical patch-now moment.
The Vulnerability
- CVE ID: CVE-2026-33017
- CVSS Score: 9.3 (Critical)
- Vector: Missing Authentication + Code Injection leading to Remote Code Execution (RCE)
- Affected Endpoint:
POST /api/v1
The flaw allows attackers to inject malicious code via the API without requiring authentication. Given that Langflow is often used to prototype AI workflows, it's frequently exposed on development servers that might not have strict ingress controls.
Detection
If you are monitoring these endpoints, look for suspicious POST requests that result in process execution. You can use a simple KQL query to hunt for anomalies in your logs:
Syslog
| where ProcessName contains "langflow"
| where HttpMethod == "POST"
| where Url contains "/api/v1"
| project TimeGenerated, SrcIp, UserAgent, Url, StatusCode
| where StatusCode != 401 and StatusCode != 403
Mitigation
The immediate fix is to update to the latest patched version. If you cannot update immediately, ensure the instance is not accessible from the public internet and restrict access via IP whitelisting.
Is anyone else seeing active scanning attempts for this in their environment yet?
We saw probes hitting our honeypot almost immediately after the PoC dropped. The requests are targeting the flow component endpoints specifically. The payload tries to spawn a reverse shell using standard Python libraries. If you're exposing Langflow directly, put it behind an auth proxy like Nginx or Authelia immediately.
This highlights the risk of 'shadow AI' deployments. We discovered three instances of Langflow running in our dev subnet that Ops didn't even know about. I'm pushing for a mandatory inventory sweep of all LLM tooling. Has anyone successfully implemented a WAF rule to block the specific injection pattern without breaking valid workflow JSON?
From a pentester perspective, this is a classic case of functionality over security. The API assumes trusted input. If you need to verify if you're vulnerable before patching, you can check for the lack of auth on the endpoint using curl:
curl -X POST http://:/api/v1/components/execute \
-H "Content-Type: application/" \
-d '{"id": "test"}' \
-v
If you get a 200 OK without sending an Authorization header, you are exposed. Patch ASAP.
To supplement Frank's observation on probes, you can hunt for this behavior in your SIEM immediately. I’ve deployed a simple KQL rule to look for suspicious POST requests to the vulnerable endpoint containing common shell binaries.
Urls contains "/api/v1" and RequestMethod == "POST" and HttpRequestBody has_any ("sh", "bash", "curl", "wget")
This catches most basic PoCs while you verify your inventory.
Building on the inventory concern, here's a quick one-liner to hunt for active Langflow processes on Linux endpoints. We used this internally to clear our dev environment quickly.
pgrep -af "langflow" || echo "No running instances found"
Don't forget to check for containerized instances too, as they might slip past standard process checks.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access