AI Threat AlertCVE-2026-104317: Langflow: unsafe deserialization enables RCE via broker
CRITICALIBM Langflow OSS versions 1.0.0 through 1.12.3 deserialize untrusted data (CWE-502) received through the message broker, allowing a remote attacker who can reach that broker to execute arbitrary code on the host. The CVSS score of 8.1 is held down by high attack complexity, but the impact is full compromise of confidentiality, integrity and availability, and Langflow hosts typically store LLM API keys, vector database credentials and connector secrets. There is no EPSS data, no public exploit, no Nuclei template and no CISA KEV listing as of publication, so there is no evidence of active exploitation yet. Exposure depends on whether the broker (for example Redis or a similar queue) is reachable from untrusted networks, which is a common misconfiguration in quickly deployed AI stacks. Upgrade to the fixed release described in the IBM advisory (node/7293015), and until then restrict broker access to the Langflow workers only and require authentication and TLS on it.
What is the risk?
High. The CVSS vector is AV:N/AC:H/PR:N/UI:N, so no authentication or user interaction is needed, but the attacker must be able to reach the message broker and craft a payload that the deserializer accepts, which raises complexity. Impact is complete loss of confidentiality, integrity and availability on the Langflow host. Real-world risk rises sharply where brokers are exposed to flat internal networks or the internet without authentication. The version range is wide (1.0.0 through 1.12.3), so most deployed installations are in scope. EPSS is unavailable and there is no known public exploit or KEV listing, so near-term exploitation likelihood is moderate and should be re-evaluated as data appears. Package risk data (dependents, scorecard) is unknown.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Langflow | pip | — | No patch |
Do you use Langflow? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade IBM Langflow OSS to the fixed version listed in the IBM advisory (https://www.ibm.com/support/pages/node/7293015); versions 1.0.0 through 1.12.3 are affected. 2) Restrict network access to the message broker to Langflow application and worker hosts only, using firewall rules, security groups or private networking. 3) Enable authentication and TLS on the broker and avoid default or empty credentials. 4) Run Langflow with least privilege in a container with a read-only filesystem where possible and no access to unrelated secrets. 5) Rotate LLM provider keys, database credentials and other secrets stored on any host that was exposed. 6) Detect: alert on unexpected connections to broker ports from non-Langflow hosts, unusual messages or large pickled payloads on queues, and unexpected child processes spawned by Langflow worker processes.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-104317?
IBM Langflow OSS versions 1.0.0 through 1.12.3 deserialize untrusted data (CWE-502) received through the message broker, allowing a remote attacker who can reach that broker to execute arbitrary code on the host. The CVSS score of 8.1 is held down by high attack complexity, but the impact is full compromise of confidentiality, integrity and availability, and Langflow hosts typically store LLM API keys, vector database credentials and connector secrets. There is no EPSS data, no public exploit, no Nuclei template and no CISA KEV listing as of publication, so there is no evidence of active exploitation yet. Exposure depends on whether the broker (for example Redis or a similar queue) is reachable from untrusted networks, which is a common misconfiguration in quickly deployed AI stacks. Upgrade to the fixed release described in the IBM advisory (node/7293015), and until then restrict broker access to the Langflow workers only and require authentication and TLS on it.
Is CVE-2026-104317 actively exploited?
No confirmed active exploitation of CVE-2026-104317 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-104317?
1) Upgrade IBM Langflow OSS to the fixed version listed in the IBM advisory (https://www.ibm.com/support/pages/node/7293015); versions 1.0.0 through 1.12.3 are affected. 2) Restrict network access to the message broker to Langflow application and worker hosts only, using firewall rules, security groups or private networking. 3) Enable authentication and TLS on the broker and avoid default or empty credentials. 4) Run Langflow with least privilege in a container with a read-only filesystem where possible and no access to unrelated secrets. 5) Rotate LLM provider keys, database credentials and other secrets stored on any host that was exposed. 6) Detect: alert on unexpected connections to broker ports from non-Langflow hosts, unusual messages or large pickled payloads on queues, and unexpected child processes spawned by Langflow worker processes.
What systems are affected by CVE-2026-104317?
This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, RAG pipelines, LLM orchestration platforms, Distributed task worker pipelines.
What is the CVSS score for CVE-2026-104317?
CVE-2026-104317 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.59%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049Exploit Public-Facing ApplicationAML.T0050Command and Scripting InterpreterAML.T0055Unsecured CredentialsCompliance Controls Affected
What are the technical details?
Original Advisory
IBM Langflow OSS 1.0.0 through 1.12.3 could allow a remote attacker who could reach the message broker to execute arbitrary code on the system due to the deserialization of untrusted data.
Exploitation Scenario
An attacker scans for exposed or internally reachable broker services used by a Langflow deployment, such as an unauthenticated Redis or AMQP endpoint. They publish a crafted serialized object to the queue that Langflow consumes. When a Langflow worker deserializes the message, the payload executes arbitrary code and gives the attacker a shell in the worker context. From there they read environment variables and configuration to harvest LLM API keys and vector database credentials, tamper with flows to exfiltrate data processed by the AI pipelines, and move laterally to connected cloud and data services.
Weaknesses (CWE)
CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
- [Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- [Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
Timeline
Related Vulnerabilities
CVE-2026-1056110.0Langflow: auth bypass + unauthenticated RCE (CVSS 10)
Same package: langflowCVE-2026-1013410.0Langflow: unauthenticated RCE via tool_code injection
Same package: langflowCVE-2026-333099.9langflow: Path Traversal enables file access
Same package: langflowCVE-2026-552559.9Langflow: IDOR allows cross-user flow execution
Same package: langflowCVE-2026-78739.9Langflow: authenticated RCE enables credential theft
Same package: langflow