GHSA-j8f7-x8jm-wmm4

### Summary Before **Langflow 1.10.3**, several built-in components sent server-side HTTP requests to URLs the flow author controls, with no SSRF enforcement. An authenticated user who can build or run flows could make the Langflow server reach loopback, RFC 1918 / private networks, link-local addresses and cloud metadata endpoints (for example `http://169.254.169.254/latest/meta-data/`), and in many cases read the response back through the component output. Two things combined to cause this: 1. **Protection disabled / warn-only.** The SSRF guard (`lfx/utils/ssrf_protection.py`, added in 1.7.0 by #10544) shipped with `ssrf_protection_enabled = False`, and its only caller, the **API Request** component, called `validate_url_for_ssrf(url, warn_only=True)`. So even with protection turned on, blocked URLs were only logged. 2. **Inconsistent coverage.** Other components that take a user-supplied URL or base URL did not call the guard at all: RSS Reader, SearXNG, Web Search (fetching result / RSS URLs), Home Assistant, Glean Search and Docling Serve (remote). The problem was fixed across several PRs and is fully fixed in **Langflow 1.10.3** (and 1.11.0+). With the default settings, outbound requests from these components are now validated after DNS resolution, pinned to the validated IP (to prevent DNS rebinding) and **blocked** when they target private, loopback, link-local or metadata addresses, unless the operator allowlists the host. ### Affected versions | Package (PyPI) | Vulnerable | Patched | |---|---|---| | `langflow` | `< 1.10.3` | `1.10.3` | | `langflow-base` | `< 0.10.3` | `0.10.3` | | `lfx` | `< 1.10.3` | `1.10.3` | | `lfx-docling` (Docling Serve component) | `< 0.1.2` | `0.1.2` | How the fix rolled out: | Release | Change | |---|---| | `< 1.7.0` | No SSRF guard. All URL-taking components make unrestricted requests. | | `1.7.0` – `1.9.2` | Guard exists, but `ssrf_protection_enabled=False` by default and API Request uses `warn_only=True`. | | `1.9.3` |