Langflow CVE-2025-68477

Exploitation requires (1) a valid Langflow API key able to call the flow execution endpoints /api/v1/run or /api/v1/run/advanced, and (2) attacker control over the API Request component's user-supplied URL within a flow (via node input, tweaks, or stored UI value). The specific vulnerable feature is the API Request component's server-side httpx client, which performs only URL normalization and basic format checks and does NOT block loopback (127.0.0.1), RFC1918 private ranges (10/172/192), or the cloud metadata endpoint 169.254.169.254, and returns the raw response body (enabling non-blind SSRF). Limiting factors: this is authenticated (API key needed) and depends on the attacker being able to set/alter the flow's URL, so it is not anonymous internet-wide exploitation; impact is confined to confidentiality (reading internal responses) and is bounded by what internal services are reachable from the Langflow server's network context. Affects deployments prior to the patched release (stated as 1.7.0 in the description / 1.7.1 in package data - confirm).

This is a moderate-priority SSRF (CWE-918) rather than a critical drop-everything issue, but the signals skew it toward the higher end of medium. The vendor-assigned CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5) is internally consistent with the description: network-reachable, low complexity, requires some privilege (an API key to invoke /api/v1/run), no user interaction, and a confidentiality-only impact (I:N/A:N) because the flaw returns response bodies but does not itself modify or deny service. EPSS is notably elevated - 6.30% is in the 93rd percentile - indicating relatively high modeled exploitation likelihood for a non-KEV flaw, and this aligns with the fact that public exploit code / a detailed GitHub Security Advisory with vulnerable-code pointers exists. Exploitation status: publicly available exploit code exists; it is NOT on CISA KEV, so there is no confirmed active exploitation. The main factor that tempers risk is PR:L - an attacker needs a valid API key AND the ability to control the API Request component's URL in a flow, so this is an authenticated/insider or post-credential-compromise scenario, not a fully anonymous internet attack. Note one data conflict to verify: the CVE description states the fix is in version 1.7.0, while the package intelligence states 'vulnerable < 1.7.1, fixed in 1.7.1' - confirm the exact fixed version with the vendor advisory before remediation.

An attacker holding a valid Langflow API key creates or modifies a flow so the API Request component points at an internal target (e.g. the cloud metadata endpoint 169.254.169.254 or an internal admin service), then invokes /api/v1/run or /api/v1/run/advanced. Because the server-side httpx client does not block private ranges or metadata endpoints and returns the response body, the attacker receives internal data directly (non-blind SSRF). Public exploit details exist in the GitHub Security Advisory, lowering the barrier to reproduction.