SSRF Vulnerability in @ucp/http via OpenAPI servers URL (CVE-2026-4468)

Vulnerability Overview Vulnerability Name: SSRF via attacker-controlled OpenAPI servers[0].url in HTTP communication protocol Vulnerability Description: This vulnerability exists in the package, leading to blind Server-Side Request Forgery (SSRF). The root cause is an inconsistent trust boundary: validates the discovered URL, but reuses the unvalidated between manual discovery and tool invocation. An attacker can host a malicious OpenAPI specification and declare or on a legitimate HTTPS endpoint, causing the converter to generate URLs pointing to internal services on the proxy host. A prefix bypass also affects the discovery-time check: the previous guard allowed URLs such as to pass. Scope of Impact Affected Versions: (npm) <= 1.1.1 Fixed Version: 1.1.2 Severity: 4.7 / 10 CVSS v3 Base Metrics: - Attack Vector: Network - Attack Complexity: High - Privileges Required: None - User Interaction: Required - Scope: Changed - Confidentiality: Low - Integrity: Low - Availability: None Remediation Patch: - Committed in - A new helper module exposes , , and . Host-based validation closes the prefix bypass (e.g., is rejected). - All protocol implementations of now call . uses to immediately re-validate the resolved URL. - rejects remote specifications containing loopback redirect variants. Workarounds For users unable to upgrade immediately: - Reject calls to for any URL controlled by an untrusted page, even if served over HTTPS. - Restrict outbound network access from the proxy-running host to internal addresses (RFC1918, 169.254.0.0/16, loopback). Credits Discovered and reported by YLChen-007, targeting the Python sibling implementation ( ). The TypeScript port shares the same code structure and the same vulnerability. Related Advisories This is the same vulnerability present in the corresponding version (GHSA-c396-4b67-gg9v / CVE-2026-4468), now present in the Python package, with the same code structure and reporter. Version and Patch Status - Vulnerable. Both loopback redirect ( ) and non-loopback internal IP variants (e.g., , ) are successful. Note: and paths are TODO placeholders in 1.1.1 and do not actually fetch the URL; therefore, the SSRF surface in the current protocol is limited to discovery for now - future implementations must also call before issuing requests. - Fully fixed. Runtime re-validation in closes the non-loopback variant; rejects, at conversion time, any specification fetched from a non-loopback source that declares a loopback , closing the loopback redirect variant. Impact A remote attacker can persuade the proxy (via LLM context, prompt injection, or tool discovery surface) to register their HTTPS OpenAPI URL, enabling them to: - Map the internal network behind the proxy. - Read AWS/GCP IAM credentials from cloud metadata endpoints ( , ). - Access unauthenticated internal services exposed to loopback (Elasticsearch, Redis HTTP, internal admin panels, the proxy's own HTTP server). - Receive responses returned to the LLM, which, combined with prompt injection, allows the attacker to extract data. Patch Committed in A new helper module exposes , , and . Host-based validation closes the prefix bypass (e.g., is rejected). All protocol implementations of now call . uses to immediately re-validate the resolved URL. rejects remote specifications containing loopback redirect variants. Workarounds For users unable to upgrade immediately: - Reject calls to for any URL controlled by an untrusted page, even if served over HTTPS. - Restrict outbound network access from the proxy-running host to internal addresses (RFC1918, 169.254.0.0/16, loopback). Credits Discovered and reported by YLChen-007, targeting the Python sibling implementation ( ). The TypeScript port shares the same code structure and the same vulnerability. Related Advisories This is the same vulnerability present in the corresponding version (GHSA-c396-4b67-gg9v / CVE-2026-4468), now present in the Python package, with the same code structure and reporter. Version and Patch Status - Vulnerable. Both loopback redirect ( ) and non-loopback internal IP variants (e.g., , ) are successful. Note: and paths are TODO placeholders in 1.1.1 and do not actually fetch the URL; therefore, the SSRF surface in the current protocol is limited to discovery for now - future implementations must also call before issuing requests. - Fully fixed. Runtime re-validation in closes the non-loopback variant; rejects, at conversion time, any specification fetched from a non-loopback source that declares a loopback , closing the loopback redirect variant. Impact A remote attacker can persuade the proxy (via LLM context, prompt injection, or tool discovery surface) to register their HTTPS OpenAPI URL, enabling them to: - Map the internal network behind the proxy. - Read AWS/GCP IAM credentials from cloud metadata endpoints ( , ). - Access unauthenticated internal services exposed to loopback (Elasticsearch, Redis HTTP, internal admin panels, the proxy's own HTTP serv

Goal Reached Thanks to every supporter — we hit 100%!

SSRF Vulnerability in @ucp/http via OpenAPI servers URL (CVE-2026-4468)

More from this source