Portkey AI Gateway CVE-2026-82270

Exploitation requires network access to the Portkey AI Gateway's /v1/proxy/* route, which is the gateway's standard proxying interface and is expected to be network-accessible in typical deployments. No authentication is required - the CVSS 4.0 vector specifies PR:N (no privileges), confirmed by the description's lack of any authentication gate on this route. The attacker must be able to set custom HTTP headers, specifically x-portkey-custom-host, in requests to this endpoint. The enabling condition is the absence of requestValidator middleware on the /v1/proxy/* route in versions through 1.15.2; with that middleware present, host values would be validated or rejected. Deployments where the gateway is isolated from the internet by network perimeter controls, or where OS-level egress filtering blocks RFC 1918 and link-local addresses, significantly reduce the impact of a successful SSRF attempt, though the header injection vulnerability itself remains present.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) places this in the high-priority tier: the attack is network-reachable, requires no privileges, no user interaction, and no special attack requirements, with high confidentiality impact on the vulnerable system. EPSS data is absent from available intelligence, limiting probabilistic exploitation forecasting. No CISA KEV listing confirms active exploitation, and no public proof-of-concept code has been identified; however, the vulnerability mechanism requires only a single crafted HTTP request with a custom header - well within reach of any competent attacker who discovers it. The most significant real-world risk is LLM provider API key theft: stolen keys enable fraudulent AI API usage billed to the victim, exfiltration of fine-tuning data, and downstream exposure of any data processed through those provider accounts. Unlike many SSRF findings where exploitation is gated by complex chaining, this flaw is self-contained - the SSRF and credential exfiltration occur in a single unauthenticated request. Risk reduction depends entirely on network egress controls and host header validation, not on authentication hardening or user behavior, meaning all internet-exposed deployments regardless of their identity controls are fully exposed.

An unauthenticated attacker sends a single HTTP request to the publicly accessible /v1/proxy/* endpoint with the x-portkey-custom-host header set to an internal address such as a cloud instance metadata endpoint (169.254.169.254) or an internal credential store. The gateway forwards the request - including Authorization headers containing LLM provider API keys - to the specified internal host, returning the response body to the attacker and exposing the credentials. No public proof-of-concept code has been identified, but exploitation requires only standard HTTP tooling capable of setting custom headers.