CVE-2026-82270: Portkey AI Gateway SSRF Vulnerability

CVE-2026-82270 Overview

CVE-2026-82270 is a server-side request forgery (SSRF) vulnerability in Portkey AI Gateway through version 1.15.2. The /v1/proxy/* route lacks the requestValidator middleware, allowing attackers to set the x-portkey-custom-host header to internal addresses. The gateway then forwards requests, including Authorization headers, to attacker-controlled internal destinations. This enables adversaries to reach internal services and exfiltrate provider API keys handled by the gateway. The flaw is classified as CWE-918: Server-Side Request Forgery.

Critical Impact
Unauthenticated network attackers can pivot into internal networks and steal upstream AI provider API keys by abusing the unvalidated proxy route.

Affected Products

Portkey AI Gateway versions up to and including 1.15.2
Deployments exposing the /v1/proxy/* route without additional network controls
Self-hosted Portkey Gateway instances forwarding requests to third-party AI providers

Discovery Timeline

2026-08-28 - CVE-2026-82270 published to NVD
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-82270

Vulnerability Analysis

Portkey AI Gateway acts as a routing layer between client applications and upstream AI providers. Requests flow through Express-style middleware defined in src/index.ts, where requestValidator normally enforces input constraints on inbound headers and destinations.

The /v1/proxy/* route omits this validator. As a result, the x-portkey-custom-host header is honored without checks against internal IP ranges, loopback addresses, or metadata services. The gateway propagates client-supplied Authorization headers to the target host, converting the service into a confused deputy.

Exploitation requires no authentication and can be performed with a single HTTP request. Impact scope is confidentiality: attackers read internal HTTP responses and capture credentials in transit. Refer to the VulnCheck advisory and Portkey issue #1718 for reproduction details.

Root Cause

The root cause is a missing middleware binding on the proxy route. Other routes in the Portkey Gateway source attach requestValidator, but /v1/proxy/* does not. This bypass allows client-controlled host headers to determine the outbound request destination.

Attack Vector

An attacker sends a crafted HTTP request to /v1/proxy/<path> with x-portkey-custom-host set to an internal target such as 169.254.169.254, 127.0.0.1, or an internal service hostname. The gateway rewrites the outbound request to that host and appends any provided Authorization header, returning the internal response to the attacker.

See the Portkey-AI Gateway repository for the affected code paths. No verified proof-of-concept code is published beyond the vendor issue and advisory references.

Detection Methods for CVE-2026-82270

Indicators of Compromise

Inbound requests to /v1/proxy/* containing an x-portkey-custom-host header referencing RFC1918 addresses, loopback interfaces, or cloud metadata endpoints such as 169.254.169.254
Outbound connections from the Portkey Gateway process to internal subnets or cloud instance metadata services
Unexpected use of provider API keys from IP addresses associated with the gateway host

Detection Strategies

Inspect HTTP access logs for the /v1/proxy/ path combined with any x-portkey-custom-host header value
Alert on the gateway process initiating TCP connections to link-local, loopback, or private address ranges
Correlate upstream provider API key usage anomalies with gateway request timestamps

Monitoring Recommendations

Forward Portkey Gateway application logs and host network telemetry to a centralized analytics platform for retention and query
Establish a baseline of legitimate outbound destinations from the gateway and alert on deviations
Monitor cloud instance metadata service (IMDS) access originating from the gateway host or container

How to Mitigate CVE-2026-82270

Immediate Actions Required

Restrict network egress from the Portkey Gateway host to only the required upstream AI provider endpoints
Block or strip the x-portkey-custom-host header at an upstream reverse proxy or web application firewall
Rotate any provider API keys that transited the gateway, and audit provider-side access logs for unauthorized use
Enforce IMDSv2 with hop-limit 1 on cloud instances hosting the gateway to prevent metadata exfiltration

Patch Information

No fixed version is listed in the NVD entry at the time of publication. Track the Portkey-AI Gateway repository and issue #1718 for patch availability. Upgrade beyond 1.15.2 once the vendor publishes a release that binds requestValidator to the /v1/proxy/* route.

Workarounds

Disable or firewall the /v1/proxy/* route if not required for production traffic
Deploy a reverse proxy in front of the gateway that rejects requests containing x-portkey-custom-host
Run the gateway in a network segment with strict egress allowlists limited to approved provider domains
Terminate Authorization headers at the edge and re-issue provider credentials server-side rather than trusting client-supplied tokens

bash

# Example NGINX snippet to strip the vulnerable header and block the proxy route
location /v1/proxy/ {
    return 403;
}

proxy_set_header x-portkey-custom-host "";