Langflow 1.10.0 Remote Code Execution: Public Exploit Available — Detection and Remediation Guide

A critical remote code execution vulnerability in Langflow 1.10.0 has been published on Exploit-DB (ID 52675) with working proof-of-concept code. Langflow — the open-source visual framework for building LangChain-based AI workflows and agents — is increasingly deployed in enterprise environments as organizations operationalize LLM pipelines. A public, weaponizable exploit against it means every internet-facing or internally exposed Langflow instance is now a live target.

Why This Matters Right Now

Langflow occupies a uniquely dangerous position in modern environments:

• It runs with access to secrets. Langflow deployments routinely hold API keys for OpenAI, Anthropic, Azure OpenAI, vector databases, and internal data stores. Code execution on the Langflow host is a direct path to credential theft and downstream compromise of every integrated service.
• It is often deployed hastily. AI teams stand up Langflow via pip install langflow or Docker for prototyping, then leave it running — frequently bound to 0.0.0.0, frequently without authentication hardened, and frequently outside the patch management umbrella of the security team.
• AI infrastructure is an active target class. Throughout 2025 and into 2026 we have tracked escalating attacker interest in AI/ML tooling — model servers, vector stores, and workflow orchestrators — precisely because they are under-monitored and over-privileged.

When exploit code hits Exploit-DB, the window between "published" and "mass-scanned" is measured in hours. If you run Langflow 1.10.0 anywhere reachable, treat this as an active incident response trigger, not a backlog ticket.

Technical Analysis

Affected Product

• Product: Langflow (open-source AI workflow builder, Python/FastAPI-based)
• Affected version: 1.10.0 (per the Exploit-DB publication; earlier versions should be assumed suspect until verified against vendor advisories)
• Deployment models affected: pip-installed instances, Docker containers, and any reverse-proxied deployments where the vulnerable API surface is reachable

Attack Mechanics (Defender's View)

The flaw is classified as a critical code execution vulnerability in the Langflow web application. Langflow's core value proposition — dynamically executing user-defined Python components and validating custom code through its API — is also its structural attack surface. Code execution flaws in this class of application typically manifest through the application's API endpoints that accept, validate, or execute user-supplied code (the /api/v1/validate/ and component-building code paths are the architectural hotspots in Langflow's design).

From a defender's perspective, the observable exploitation chain looks like this:

1. Reconnaissance: The attacker identifies Langflow by its default port (7860), banner, or API responses such as /api/v1/version.
2. Delivery: A crafted HTTP request — typically a POST to a Langflow API endpoint — delivers attacker-controlled Python code embedded in the request body. Telltale payloads include references to os.system, subprocess, __import__, eval, exec, or base64-encoded stagers.
3. Execution: The Langflow server process (Python) executes the payload in its own context. Post-exploitation observables are the langflow/Python parent process spawning child shells (/bin/sh, bash, cmd.exe, powershell.exe), downloading second-stage tooling with curl/wget, or initiating reverse-shell network connections.
4. Post-exploitation: Credential harvesting (.env files, Langflow's SQLite/Postgres backend containing stored API keys), lateral movement, and persistence via cron, systemd units, or container escape attempts.

Exploitation Status

• Public PoC: Yes — published on Exploit-DB (ID 52675) with exploit code. This lowers the bar to zero: any low-skill actor can weaponize it immediately.
• Mass scanning: Assume it. Public PoCs against web applications are integrated into scanners and botnets within days of publication.
• No CVE identifier is referenced in the source publication at time of writing. Track the Langflow GitHub security advisories and NVD for a formal assignment — but do not wait for one to act. Absence of a CVE number is not absence of risk.

The Critical Caveat: Version Lineage

Langflow has a documented history of code-execution-class vulnerabilities in its validation and component APIs, and maintainers have shipped fixes across multiple releases. The safe assumption is that 1.10.0 and any version not explicitly listed as fixed should be treated as vulnerable. Verify your exact deployed version — many teams don't know what's running because Langflow was stood up outside standard IT processes.

Detection & Response

The highest-fidelity detection strategy for this class of flaw has two layers: (1) web-layer telemetry catching exploit delivery, and (2) process-layer telemetry catching successful execution. The process layer is your most reliable signal — a Python web application spawning shells or download utilities is almost never legitimate.

Sigma Rules

---
title: Langflow Web Process Spawning Shell or Script Interpreter
description: Detects the Langflow server process (Python) spawning command shells or script interpreters, consistent with successful exploitation of a code execution flaw in the Langflow web application.
references:
  - https://www.exploit-db.com/exploits/52675
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'langflow'
      - 'uvicorn'
  selection_child:
    CommandLine|contains:
      - '/bin/sh'
      - '/bin/bash'
      - 'python -c'
      - 'curl '
      - 'wget '
      - 'nc '
      - 'ncat '
      - 'base64'
  condition: selection_parent and selection_child
falsepositives:
  - Langflow custom components intentionally invoking subprocesses (review component code; these should be rare and identifiable)
level: critical
---
title: Langflow Server Child Process Execution (Windows)
description: Detects a Python/Langflow server process spawning cmd.exe or PowerShell on Windows-hosted Langflow deployments, indicating code execution through the web application.
references:
  - https://www.exploit-db.com/exploits/52675
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\python.exe'
      - '\pythonw.exe'
      - '\uvicorn.exe'
  selection_parent_cli:
    ParentCommandLine|contains: 'langflow'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\certutil.exe'
      - '\curl.exe'
  condition: selection_parent and selection_parent_cli and selection_child
falsepositives:
  - Developer workstations running Langflow locally with components that shell out
level: critical
---
title: Suspicious Code Execution Payload in Langflow API Requests
description: Detects HTTP requests to Langflow API endpoints containing Python code execution primitives in the request, consistent with exploit delivery attempts against Langflow code validation/execution APIs.
references:
  - https://www.exploit-db.com/exploits/52675
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/api/v1/validate'
      - '/api/v1/build'
      - '/api/v1/custom_component'
  selection_payload:
    cs-body|contains:
      - '__import__'
      - 'os.system'
      - 'subprocess'
      - 'eval('
      - 'exec('
      - 'os.popen'
      - '/bin/sh'
      - 'bash -c'
  condition: selection_uri and selection_payload
falsepositives:
  - Developers legitimately testing code-execution components (these should only occur from known internal source IPs — alert on anything else)
level: high

A note on tuning: Rule 3 requires your proxy/WAF/web logs to capture request bodies. Most don't by default. If you can't log bodies, drop the selection_payload clause and alert on requests to those endpoints from any source IP outside your known developer range — volume will be low and the signal is strong.

KQL — Microsoft Sentinel / Defender

This query hunts the process-execution layer — the highest-fidelity signal — across both Defender-onboarded endpoints and Syslog/CEF-ingested Linux hosts:

// Hunt 1: Langflow/Python server processes spawning shells or download tools (Defender)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("python", "python3", "python.exe", "uvicorn")
   or InitiatingProcessCommandLine has_any ("langflow", "uvicorn")
| where FileName in~ ("sh", "bash", "dash", "cmd.exe", "powershell.exe", "pwsh.exe", "curl", "wget", "nc", "ncat", "base64", "certutil.exe")
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, RemoteIP
| order by TimeGenerated desc;

// Hunt 2: Exploit delivery — requests to Langflow code-handling API endpoints (proxy/WAF/firewall via CEF)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any ("/api/v1/validate", "/api/v1/build", "custom_component")
   or RequestURL has "langflow"
| extend SuspiciousPayload = RequestURL has_any ("__import__", "os.system", "subprocess", "eval", "exec", "%2fbin%2f", "/bin/sh")
| summarize Requests = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by SourceIP, DestinationHostName, RequestURL, RequestMethod, SuspiciousPayload
| order by Requests desc;

// Hunt 3: Outbound connections from Langflow hosts to rare external destinations (post-exploitation C2/beaconing)
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("python", "python3", "uvicorn")
| where RemoteIPType == "Public"
| summarize ConnectionCount = count(), DistinctPorts = dcount(RemotePort), Ports = make_set(RemotePort)
  by DeviceName, RemoteIP, RemoteUrl
| where ConnectionCount < 5 or DistinctPorts > 3
| order by ConnectionCount asc;

Hunt 3 catches reverse shells and beaconing: a Python process that normally talks to OpenAI and your vector DB suddenly holding a long-lived connection to an unknown IP on an unusual port is exactly what post-exploitation looks like.

Velociraptor VQL

Deploy this hunt across suspected Langflow hosts to identify exploitation artifacts — suspicious child processes, outbound connections, and recently dropped files in the application's working directories:

-- Langflow RCE post-exploitation hunt: child processes and network connections
-- from Python/Langflow server processes

LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)langflow|uvicorn'

LET suspicious_children = SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)^(sh|bash|dash|curl|wget|nc|ncat|cmd\.exe|powershell\.exe|pwsh\.exe)$'
   OR CommandLine =~ '(?i)(/bin/sh|bash -c|base64 -d|invoke-webrequest)'

SELECT 'server_process' AS Artifact, Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM procs
UNION ALL
SELECT 'suspicious_process' AS Artifact, Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM suspicious_children

// Correlate with live network connections
SELECT Pid, Name, LocalAddr, RemoteAddr, Status
FROM netstat()
WHERE Name =~ '(?i)python|uvicorn|sh|bash'
   AND Status =~ 'ESTABLISHED'

// Check for dropped artifacts in common Langflow/temp locations
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
  '/tmp/*.py',
  '/tmp/*.sh',
  '/dev/shm/*',
  '/home/*/.langflow/**',
  '/var/tmp/*'
])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Files written to /tmp, /dev/shm, or /var/tmp in the last 7 days by a service account that runs Langflow are prime staging artifacts. On confirmed compromise, acquire Langflow's database (default SQLite at ~/.langflow/langflow.db, or your configured Postgres instance) — it contains flow definitions and, critically, stored credentials that must be rotated.

Remediation / Verification Script

Run this on Linux Langflow hosts to inventory the deployment, confirm the version, check for signs of active exploitation, and upgrade:

#!/bin/bash
# langflow_rce_triage.sh — Inventory, verify, and remediate Langflow RCE exposure
# Run as root or with sudo on Langflow hosts

echo "=== [1] Identify running Langflow instances ==="
ps aux | grep -iE 'langflow|uvicorn' | grep -v grep

echo ""
echo "=== [2] Identify listening ports (default 7860) ==="
ss -tlnp | grep -iE 'python|uvicorn|7860'

echo ""
echo "=== [3] Check installed Langflow version ==="
pip3 show langflow 2>/dev/null | grep -iE 'Name|Version|Location' || echo "Not found via pip3 — check virtualenvs and containers"
# If running in Docker:
docker ps --format '{{.Names}} {{.Image}}' | grep -i langflow

echo ""
echo "=== [4] Triage: suspicious child processes spawned by the server (last boot) ==="
ps -eo pid,ppid,user,comm,args --forest | grep -iE 'python|uvicorn' -A 2 | grep -iE 'sh|bash|curl|wget|nc |base64'

echo ""
echo "=== [5] Triage: recent files in staging directories ==="
find /tmp /var/tmp /dev/shm -type f -mtime -7 -user $(ps aux | grep -i langflow | grep -v grep | awk '{print $1}' | head -1) 2>/dev/null

echo ""
echo "=== [6] Triage: outbound connections from server process ==="
ss -tnp | grep -iE 'python|uvicorn' | grep -v '127.0.0.1'

echo ""
echo "=== [7] Upgrade Langflow to the latest release ==="
echo "Review https://github.com/langflow-ai/langflow/security/advisories BEFORE upgrading"
read -p "Proceed with pip upgrade? (y/n): " confirm
if [ "$confirm" = "y" ]; then
    pip3 install --upgrade langflow
    systemctl restart langflow 2>/dev/null || echo "Restart the Langflow service/container manually"
fi

echo ""
echo "=== [8] Harden: bind to localhost and place behind an authenticated reverse proxy ==="
echo "Start Langflow with: langflow run --host 127.0.0.1 --port 7860"
echo "Enforce authentication; never expose the API unauthenticated to untrusted networks"

If any step in [4]–[6] returns unexpected results, stop patching and start incident response: preserve the host, acquire memory and disk images, and pull Langflow's database and logs before remediation destroys evidence.

Remediation

1. Upgrade immediately. Move off Langflow 1.10.0 to the latest stable release from the official Langflow repository. Review the Langflow security advisories to confirm the version you deploy carries the fix. Given Langflow's history of code-execution-class flaws, pin and track versions going forward — do not run latest tags unmanaged.
2. Assume compromise on exposed instances. Any Langflow 1.10.0 instance reachable from the internet — or from broadly accessible internal segments — since the exploit publication date must be treated as potentially compromised. Rotate every credential stored in or accessible to it: LLM provider API keys, database credentials, vector store tokens, and any service account the host can reach.
3. Remove unauthenticated network exposure. Bind Langflow to localhost or an internal interface and place it behind a reverse proxy enforcing SSO/MFA. Langflow's authentication configuration should be explicitly enabled and verified — do not rely on defaults.
4. Segment AI infrastructure. Langflow hosts should sit in a dedicated segment with egress filtering. A workflow builder has no business initiating outbound connections to arbitrary internet IPs — allowlist only required endpoints (LLM APIs, internal data sources).
5. Apply least privilege at the process level. Run Langflow as a dedicated, unprivileged service account — never root, never a domain-joined user with broad access. Container deployments should run read-only where possible with dropped capabilities.
6. Onboard telemetry. AI tooling is chronically under-monitored. Ensure Langflow hosts forward process and network telemetry to your SIEM, and that your reverse proxy/WAF logs capture the API request patterns described above.

Deadline guidance: With public exploit code available, treat remediation as a 24–72 hour priority for any exposed instance, consistent with emergency-patch handling under NIST CSF Respond and CIS Control 7 (Continuous Vulnerability Management). Internal-only instances should be remediated within your standard critical-vulnerability SLA — but verify "internal-only" with actual network path testing, not assumption.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub