CVE-2026-104310 in Langflow OSS
Summary
by MITRE • 10/29/2026
IBM Langflow OSS 1.0.0 through 1.12.3 could allow a remote authenticated attacker to obtain sensitive information due to a server-side request forgery (SSRF) vulnerability.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The identified security flaw resides within IBM Langflow, specifically affecting versions ranging from 1.0.0 up to and including 1.12.3. This software component is susceptible to Server-Side Request Forgery, a class of vulnerabilities that allows an attacker to induce the server-side application to make HTTP requests to arbitrary domains or internal resources under the control of the attacker. In this specific instance, the vulnerability permits a remote authenticated user to exploit improper input validation and URL handling mechanisms within the Langflow framework. By crafting malicious payloads that manipulate how the application processes external URLs or data sources, an adversary can trick the server into initiating requests to unintended destinations. This capability is particularly dangerous because it leverages the trust relationship between the web application and its backend infrastructure, effectively bypassing standard network security controls such as firewalls that might otherwise restrict direct access from outside networks.
The operational impact of this vulnerability centers on the unauthorized disclosure of sensitive information stored within internal systems or cloud environments accessible to the Langflow server. Because the attacker is authenticated, they possess a legitimate session and can interact with application features without triggering immediate intrusion detection alerts associated with unauthenticated attacks. Through SSRF, an attacker may access internal metadata services commonly found in cloud computing platforms like AWS EC2 instance metadata service or Azure managed identity endpoints. These services often contain temporary security credentials, API keys, and configuration details that are not intended for public exposure. Additionally, the vulnerability can be used to probe internal network topologies, identify running services on non-public ports, or access sensitive files within the local file system if the application has sufficient privileges to read them via file protocols. This leads directly to a compromise of confidentiality integrity across the broader infrastructure supporting Langflow deployments.
From a classification perspective, this vulnerability aligns with CWE-918, which defines Server-Side Request Forgery as a weakness where web applications retrieve data from remote servers without validating user-supplied input sufficiently. The exploitation technique maps closely to MITRE ATT&CK tactic T1557, specifically the subtechnique Lateral Tool Transfer or Adversary-in-the-Middle scenarios where SSRF is used to pivot through internal networks and steal credentials. It also relates to CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor. The root cause typically involves a failure to enforce strict allowlists for outbound connections, lack of validation against private IP address ranges such as 10.x.x.x or 192.168.x.x, and insufficient sanitization of URL parameters that are passed directly into HTTP client libraries without checking the resolved destination host.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary corrective action is to upgrade IBM Langflow to a version later than 1.12.3 where these input validation checks have been implemented by the vendor. For environments that cannot immediately patch, network-level controls should be enforced using egress filtering rules at the firewall or proxy level to restrict outbound connections from the application server to only known and trusted external endpoints. Internal metadata service IPs must be explicitly blocked in local routing tables or via host-based firewalls like iptables on Linux systems. Application developers should implement strict allowlists for permitted domains, reject requests targeting private IP ranges, and avoid following redirects that could lead to malicious destinations. Additionally, implementing robust logging and monitoring for outbound traffic anomalies can help detect exploitation attempts early before significant data exfiltration occurs.