CVE-2026-10561: Unauthenticated Remote Code Execution in IBM Langflow OSS
| Field | Value |
|---|---|
| CVE ID | CVE-2026-10561 |
| CVSS score | 10.0 (Critical) |
| Attack vector | Remote over network; full CVSS vector string was not exposed in the source material retrieved here |
| Auth required | None, based on vendor description of authentication bypass |
| Patch status | Fix version not explicitly confirmed in the source material retrieved here |
TL;DR - IBM Langflow OSS 1.0.0 through 1.9.3 is affected by unauthenticated RCE. - Internet-exposed instances should be treated as high risk immediately. - No confirmed in-the-wild exploitation or PoC was established here, but urgency is critical.
Vulnerability at a Glance
CVE-2026-10561 is a critical unauthenticated remote code execution vulnerability in IBM Langflow OSS. According to the NVD record, affected versions are 1.0.0 through 1.9.3. IBM’s advisory attributes the issue to improper isolation of Python execution in the PythonREPLComponent combined with an authentication bypass condition. The result is that a remote attacker can execute arbitrary code on the host system and potentially fully compromise the underlying environment.
From a defender’s standpoint, this is not a subtle bug with narrow impact. IBM’s impact statement explicitly describes complete compromise, including arbitrary OS command execution, possible execution as root in the default Docker deployment, theft of LLM provider keys, access to flow definitions, exposure of vector store credentials, and options for persistent compromise. If your Langflow deployment is reachable from untrusted networks, the safe assumption is that compromise could lead to both application and host-level impact.
Technical Notes
The key source statements are:
- Affected versions:
1.0.0 through 1.9.3 - Root cause: improper Python execution isolation in
PythonREPLComponent - Compounding issue: authentication bypass through auto-login behavior
- Impact: arbitrary code execution and complete compromise
Because the exact fixed version was not explicitly confirmed in the source material available for this write-up, defenders should not assume that simply moving to the next minor version is sufficient without checking IBM’s advisory or release notes directly.
What Is This Vulnerability?
The core bug is in how Langflow OSS restricts Python execution within the PythonREPLComponent, also described by IBM as the “Python Interpreter.” IBM states that the component’s get_globals() function tries to build a restricted globals dictionary from a whitelist of imports. However, it does not explicitly set __builtins__ to an empty object. In CPython, when exec() is invoked with globals that do not define __builtins__, Python automatically inserts the full builtins module.
That behavior defeats the intended isolation model. In practical terms, an attacker can regain access to capabilities that the whitelist model was presumably trying to prevent, including builtins such as import, open, and eval. On its own, that is already serious in any system that executes user-controlled Python. In this case, IBM says the exposure becomes unauthenticated because a separate auto-login behavior can issue a superuser JWT without credentials.
The second half of the chain is the authentication bypass. IBM states that when LANGFLOW_AUTO_LOGIN=true, a request to GET /api/v1/auto_login can issue a superuser JWT with no credentials required. If that setting is present by default as described, it means an attacker does not need a prior foothold, a stolen account, or a valid session. They can move directly from unauthenticated access into a privileged application context and then exploit the Python execution weakness.
Technical Notes
A simplified illustration of the risk pattern IBM describes looks like this:
globals_ = get_globals() # intended restricted globals
exec(user_code, globals_)
If globals_ does not define __builtins__, CPython may effectively reintroduce builtins. A defensive pattern would explicitly neutralize them:
globals_["__builtins__"] = {}
exec(user_code, globals_)
That code block is illustrative only. Defenders should rely on the vendor patch rather than attempting ad hoc source edits in production, unless directed by IBM or their own engineering team.
Who Is Affected?
The affected product is IBM Langflow OSS, with the version range explicitly stated by NVD as 1.0.0 through 1.9.3. If you operate Langflow in self-hosted, containerized, or internal AI workflow environments, inventory those deployments first. This is especially important in environments where Langflow has access to API keys, vector databases, file systems, or orchestration components.
Because IBM’s advisory discusses root-level execution in the default Docker deployment, containerized instances deserve special attention. Teams sometimes underestimate container compromise when the service is “only internal,” but Langflow deployments often hold high-value secrets such as OpenAI or Anthropic keys, database credentials, and vector store access tokens. Even if the container is isolated, those secrets can enable lateral movement into other systems.
If you do not know whether you are running an affected version, assume exposure until proven otherwise. There is not enough information in the retrieved source material to name the exact fixed version number, only that 1.0.0 through 1.9.3 are affected. The prudent operational assumption is that anything at or below 1.9.3 should be considered vulnerable unless IBM documentation for your build says otherwise.
Technical Notes
Useful inventory checks:
docker ps --format "table {{.Names}} {{.Image}} {{.Status}}"
docker inspect <container_name> | grep -i '"Image"
|"Env"'
pip show langflow
python -c "import pkg_resources; print(pkg_resources.get_distribution('langflow').version)"
If you are using Docker Compose, check the pinned image tag:
grep -Rin "langflow" docker-compose.yml compose.yaml .
CVSS Score and Severity Context
The NVD record assigns CVSS 10.0 (Critical) to CVE-2026-10561. That is the maximum base score and reflects the combination of remote reachability, lack of authentication, and high-impact code execution. The full vector string was not exposed in the source material retrieved for this article, so defenders who need exact scoring components should verify the live NVD entry directly.
Even without the full vector, the severity is easy to interpret operationally. A network-reachable service that can be driven from unauthenticated access to arbitrary code execution deserves immediate prioritization. In many environments, that places this CVE in the same response bucket as internet-facing VPN bugs, appliance RCEs, and unauthenticated admin-panel compromise.
For security teams, the “so what” is straightforward: this is not just an application bug. IBM’s own impact narrative extends to host compromise, secret exfiltration, and persistence. That means response owners should include not only application admins, but also platform, cloud, identity, and incident response teams if exposure is confirmed.
Technical Notes
Because the full vector string is not confirmed here, document your internal risk assumptions clearly:
- Assume network exposure matters
- Assume no authentication is required
- Assume confidentiality, integrity, and availability impacts are all severe
- Assume secret rotation may be required after suspected compromise
Exploitation Status
At the time of writing, CISA KEV does not list CVE-2026-10561, which means there is no KEV-based confirmation of in-the-wild exploitation in the source set used here. Also, no directly confirmed public PoC for this specific CVE was established from the retrieved primary-source references. That is an important distinction: defenders should not overstate active exploitation without evidence.
At the same time, lack of a KEV listing or publicly confirmed PoC should not be mistaken for low risk. IBM’s advisory provides enough technical detail to make the exploit chain understandable: unauthenticated superuser JWT issuance via GET /api/v1/auto_login, followed by Python execution escaping intended restrictions because __builtins__ is not neutralized. Bugs with this level of vendor-documented exploitability often become reproducible quickly, even if a polished public PoC has not yet been linked in mainstream reporting.
So the accurate status is:
| Question | Status |
|---|---|
| Confirmed exploited in the wild? | Unknown / not confirmed in the sources used here |
| Public PoC exists? | Unknown / not directly confirmed for this CVE |
| Should defenders act urgently anyway? | Yes |
Technical Notes
Defensive assumption in the absence of exploitation data:
- Treat exposed instances as if opportunistic scanning will begin soon.
- Prioritize remediation ahead of lower-severity authenticated flaws.
- Preserve logs before patching in case later IOCs become available.
Bottom Line
CVE-2026-10561 is a critical unauthenticated RCE affecting IBM Langflow OSS 1.0.0 through 1.9.3. The exploit chain described by IBM combines an authentication bypass with a Python execution isolation failure, producing a realistic path to full host compromise. There is no confirmed in-the-wild exploitation or directly confirmed public PoC in the source set used here, but that should not delay action.
For defenders, the priority order is clear: identify exposed Langflow instances, disable auto-login if present, restrict network access, verify the vendor-fixed release, upgrade explicitly, and rotate any secrets the service could access if exposure existed. Where the exact fixed version is still unconfirmed from current source material, assume you need vendor validation before declaring remediation complete.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
How to Detect It
Detection should focus on three areas: version exposure, auto-login abuse, and post-exploitation behavior. Start by identifying any Langflow OSS deployments running 1.0.0 through 1.9.3. Then review access logs, reverse proxy logs, and application logs for requests to /api/v1/auto_login from unusual source IPs, especially from the internet, VPN-less segments, or systems with no operational reason to access Langflow.
Because the end goal is arbitrary code execution, responders should also look for evidence of process spawning, outbound network connections, file modification, or secret access shortly after suspicious auto-login activity. IBM explicitly warns about theft of LLM provider keys, flow tampering, vector store credential access, and persistence via cron or modified files. Those clues should shape your triage. In containerized deployments, inspect both application logs and the container runtime for exec activity or unexpected shell invocations.
If logging is sparse, that itself is a risk. In many self-hosted application stacks, the app may not produce enough detail to reconstruct abuse after the fact. In that case, correlate web server logs, container logs, cloud audit records, EDR telemetry, and outbound proxy records. If you cannot verify whether /api/v1/auto_login was invoked, assume some uncertainty remains and base containment on exposure and versioning, not just log evidence.
Technical Notes
Concrete patterns to review:
HTTP access log pattern
"GET /api/v1/auto_login HTTP/1.1" 200
Nginx grep
grep -R 'GET /api/v1/auto_login' /var/log/nginx /var/log/* 2>/dev/null
Docker logs
docker logs <langflow_container> 2>&1 | grep -E 'auto_login|PythonREPL|exec|traceback'
Process and persistence triage inside a container or host
ps auxf
crontab -l
ls -la /etc/cron* /var/spool/cron 2>/dev/null
find /tmp /var/tmp -type f -mtime -7 2>/dev/null
Example Splunk query
index=web OR index=app
("/api/v1/auto_login" OR "auto_login")
| stats count by src_ip, http_method, uri_path, status
Example Sigma-style idea
title: Langflow Auto Login Endpoint Access
logsource:
category: webserver
detection:
selection:
cs-uri-stem: "/api/v1/auto_login"
cs-method: "GET"
condition: selection
level: high
Mitigation and Patching
The first priority is to remove exposure. If your Langflow instance is internet-accessible, restrict access immediately behind a VPN, reverse proxy allowlist, or private network controls until you can verify remediation. Because the source material used here does not explicitly confirm the fixed version number, do not guess. Check IBM’s advisory and the relevant release notes for the exact remediated build before you schedule upgrade work.
Second, address the authentication bypass condition. IBM’s bulletin states that LANGFLOW_AUTO_LOGIN=true is part of the problem because it allows GET /api/v1/auto_login to issue a superuser JWT without credentials. If operationally possible, disable this behavior immediately and restart the service. Even if that does not fully fix the Python execution flaw, it may reduce unauthenticated reachability to the vulnerable code path and buy time for a controlled upgrade.
Third, plan for post-remediation response. If there is any sign the service was exposed and reachable, rotate secrets that Langflow could access, including API keys, database credentials, vector store credentials, and any tokens stored in environment variables. Patching without credential rotation may leave attackers with durable access to upstream systems.
Technical Notes
Upgrade command examples
If installed via pip and once IBM or upstream release notes confirm the fixed version, use an explicit version pin rather than latest:
pip install --upgrade "langflow==<fixed_version>"
If deployed with Docker, pull and pin the remediated tag explicitly:
docker pull langflowai/langflow:<fixed_version>
docker stop <langflow_container>
docker rm <langflow_container>
docker run -d --name langflow
-p 7860:7860
-e LANGFLOW_AUTO_LOGIN=false
langflowai/langflow:<fixed_version>
Workaround: disable auto-login
For Docker:
docker run -d --name langflow
-p 7860:7860
-e LANGFLOW_AUTO_LOGIN=false
langflowai/langflow:<current_tag>
For Docker Compose:
services:
langflow:
image: langflowai/langflow:<current_tag>
environment:
LANGFLOW_AUTO_LOGIN: "false"
Apply the change:
docker compose up -d
If you cannot patch immediately:
- Set
LANGFLOW_AUTO_LOGIN=false - Block public access at the load balancer, firewall, or ingress
- Restrict access to trusted admin IPs only
- Monitor for any requests to
/api/v1/auto_login - Rotate secrets after remediation if exposure existed
Incident Response Considerations
If you discover an affected instance was exposed to untrusted networks, treat the case as a possible server compromise rather than a routine patch event. IBM’s impact notes make that the right assumption. Review container images, mounted volumes, scheduled tasks, startup scripts, and outbound connections. If the service had access to LLM keys or database credentials, rotate them whether or not you find direct evidence of theft.
Containerized deployments deserve careful scrutiny because “redeploy the container” is not always sufficient. If an attacker used the container’s privileges to alter mounted host paths, credentials, or cloud metadata-backed access, you may need deeper host and cloud control-plane review. Also inspect logs around the time of suspicious /api/v1/auto_login requests for any unusual command execution, package installation, or traffic to external IPs.
Technical Notes
Useful containment steps:
docker network disconnect <network> <langflow_container>
docker pause <langflow_container>
docker commit <langflow_container> langflow-forensics:snapshot
Preserve evidence before destructive cleanup:
docker logs <langflow_container> > langflow-container.log 2>&1
docker inspect <langflow_container> > langflow-container-inspect.json
tar czf langflow-config-backup.tgz /path/to/langflow/config 2>/dev/null
References
- NVD CVE record: CVE-2026-10561
- IBM vendor advisory: IBM Advisory
- IBM advisory title URL: IBM Security Bulletin
- CISA KEV catalog: CISA KEV