CVE-2025-3248: the Langflow endpoint that 'validates' your code by running it

CVE-2025-3248 lets anyone who can merely reach a Langflow server execute code on it with no credentials. The bug lives in POST /api/v1/validate/code -- an endpoint whose entire job is to check whether a user's Python snippet is valid before it becomes a flow component. The cruel twist is in the name: to validate the code, Langflow parses it and then compiles and executes it. So 'validating' the code is the same as running it. Because Langflow often sits on developer or MLOps infrastructure holding model API keys and cloud credentials, code execution there is an unusually rich foothold.

What the flaw actually is

The vulnerable endpoint takes a JSON body of the form {"code": "..."}, parses it with Python's ast module, and then compiles and exec()s the parsed definitions to surface syntax errors. There is no sandbox around that execution. The result is classic code injection (CWE-94) stacked on top of missing authentication (CWE-306): the endpoint is reachable pre-auth in versions before 1.3.0.

The clever part -- discovered and disclosed by Horizon3.ai -- is why parsing runs the payload. In Python, two things are evaluated the instant a function is defined, not when it is called: its decorator expressions (@something) and its default-argument expressions (def f(x=something)). So an attacker never has to invoke anything. They submit code that merely defines a function whose decorator or default argument is a call like exec(...), and the validator runs it the moment it compiles the definition. Output comes back in-band -- wrapping the payload in raise Exception(<command output>) surfaces the result inside the error message the endpoint returns, so no separate callback server is needed. AST parsing gives no protection here because defining code is not free of side effects.

The exploitation chain

From a single unauthenticated request to code execution, and then to one of two documented outcomes -- a DDoS botnet or a fully automated ransomware intrusion. Each stage has a cheap chokepoint, and the most effective one is simply never exposing the Langflow API to an untrusted network.

Am I affected?

Every Langflow release before 1.3.0 is vulnerable -- Horizon3 notes the flawed pattern dated back roughly two years, so this is the whole pre-1.3.0 line, not a recent regression. The fix is 1.3.0 or later. The critical scoping fact is exposure: the endpoint is reachable pre-auth, and Langflow's typical default is to bind 0.0.0.0:7860 with auto-login enabled. Read a server's version safely with a GET to /api/v1/version (that is read-only and does not touch the vulnerable endpoint) and compare against 1.3.0.

Exploited in the wild -- carefully stated

Exploitation began roughly two days after the public proof-of-concept and never really stopped. Trend Micro documented a campaign that chains the flaw to deploy Flodrix, a DDoS botnet in the LeetHozer/Mirai lineage: after gaining a shell, attackers run recon commands, exfiltrate the results, and pull a downloader script (named docker, also seen as deez) that fetches an architecture-specific Flodrix binary. The malware opens Tor and TCP/UDP command-and-control channels to a hardcoded IP, deletes itself from disk and memory, and uses a hidden .system_idle file for persistence. Censys later mapped that C2 and observed roughly 745 infected hosts -- about half internet-connected cameras -- so the botnet spreads well beyond Langflow, which is simply a lucrative entry point.

Detection & hunting

The single most useful fact for defenders: /api/v1/validate/code is essentially never called by a legitimate external client. So an unauthenticated POST to it from outside your network is high-signal on its own -- you do not need to match the exact payload. Watch the endpoint, then watch the host.

• Request-side: any external-sourced POST /api/v1/validate/code is the anomaly. Payload tells include @exec(, __import__, and subprocess inside the body, but the endpoint plus an external source is already enough to alert.
• Safe exposure check: GET /api/v1/version (read-only) and flag anything below 1.3.0; fingerprint port 7860 or search html:"Langflow" on Shodan/Censys for your external surface. Prefer this over the Nuclei template, which confirms the bug by actively reading /etc/passwd.
• Post-exploit on the host: the Langflow app runs under uvicorn/python -- hunt that process spawning /bin/sh, curl, wget, or an unknown ELF from /tmp or /dev/shm, correlated to a preceding /validate/code request.
• Flodrix artifacts: outbound to 80.66.75.121 (the XOR-decrypted C2), a hidden .system_idle file, and downloader scripts named docker/deez. Validate IOCs before blocking -- the published Flodrix ELF hashes are ARM/IoT samples, not necessarily the dropper on a typical Langflow host.

# PROPOSED, NOT OFFICIAL - flags a POST to the Langflow validate endpoint from a
# non-internal source. Replace the CIDRs with your real internal ranges and tune
# the field names to your proxy/web log schema.
title: Langflow CVE-2025-3248 validate/code attempt from external source
status: experimental
logsource:
  category: proxy
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains: '/api/v1/validate/code'
  internal_src:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not internal_src
fields: [src_ip, dst_ip, cs-uri-stem, sc-status]
level: high

What to do now

1. Patch to Langflow 1.3.0 or later (the fix adds the authentication gate from PR #6911). Later releases are fine; the CISA KEV federal due date was 2025-05-26, but exposure -- not the KEV date -- is your trigger.
2. If you cannot patch today: take the service off the internet (bind to localhost or a private subnet and firewall it), front it with an authenticating reverse proxy, and block /api/v1/validate/code from untrusted networks.
3. Disable auto-login and set a real admin: LANGFLOW_AUTO_LOGIN=false plus a configured superuser. Because the fix is auth-only, auto-login can re-open the hole even on a patched build.
4. Assume attempted compromise if you were exposed and unpatched after ~2025-04-09: hunt for the Flodrix artifacts and anomalous outbound connections above before you close the ticket.
5. Prioritise: internet-reachable instances below 1.3.0 first (hours), internal-but-reachable next, isolated dev instances on normal cadence -- and verify that 'isolated' really is.

FAQ

Sources

• NVD -- CVE-2025-3248
• Horizon3.ai -- Unsafe at Any Speed: abusing Python exec for unauth RCE in Langflow
• Langflow -- GitHub Security Advisory GHSA-vwmf-pq79-vjvx
• Langflow -- fix PR #6911 (auth on code validation)
• Langflow -- 1.3.0 release notes
• Keysight -- CVE-2025-3248 code-validation analysis
• Rapid7 -- Metasploit module langflow_unauth_rce_cve_2025_3248
• Exploit-DB 52364 -- Langflow 1.2.x RCE
• ProjectDiscovery -- Nuclei template CVE-2025-3248.yaml
• The Hacker News -- Langflow flaw added to CISA KEV
• SecurityWeek -- Langflow vulnerability exploited by Flodrix botnet
• SOCRadar -- CVE-2025-3248 in Langflow deploys Flodrix botnet
• Censys -- Poking at the Flodrix Botnet
• Recorded Future -- Langflow CVE-2025-3248
• Help Net Security -- Langflow CVE-2025-3248 exploited
• Sysdig -- JADEPUFFER: agentic ransomware for automated database extortion