CVE-2026-82270 in Gateway
Summary
by MITRE • 08/28/2026
Portkey AI Gateway through 1.15.2 contains a server-side request forgery vulnerability in the /v1/proxy/* route that lacks requestValidator middleware. Attackers can set the x-portkey-custom-host header to internal addresses and forward requests with Authorization headers to reach internal services and exfiltrate provider API keys.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The Portkey AI Gateway, a popular infrastructure for managing and securing large language model integrations, suffers from a critical server-side request forgery vulnerability in versions through 1.15.2. This flaw resides within the /v1/proxy/* route handler, which is designed to proxy requests to various external API providers such as OpenAI or Anthropic. The core technical deficiency lies in the absence of a dedicated requestValidator middleware for this specific endpoint group. In secure architectural designs, proxy endpoints must rigorously validate and sanitize all inputs, particularly headers that influence outbound network behavior, to prevent attackers from manipulating where the server sends requests. Without this validation layer, the application blindly trusts user-supplied input regarding the destination host, creating a direct path for exploitation.
An attacker can exploit this vulnerability by crafting malicious HTTP requests that include the x-portkey-custom-host header set to internal IP addresses or domain names not intended for public access. By directing the proxy server to communicate with internal services, such as cloud metadata endpoints like 169.254.169.254 on AWS or Kubernetes service APIs, the attacker can bypass network perimeter defenses that typically restrict external traffic from reaching sensitive internal infrastructure. Furthermore, because this route handles authentication proxies for AI providers, attackers can also inject Authorization headers into these forged requests. This capability allows them to exfiltrate valid API keys and credentials associated with the compromised Portkey instance or its connected provider accounts, effectively turning the gateway into a pivot point for further lateral movement within the organization's network.
The operational impact of this vulnerability is severe, encompassing both data confidentiality breaches and potential service disruption. The ability to access internal services means that attackers can retrieve sensitive configuration data, secrets stored in environment variables or metadata stores, and potentially interact with internal microservices that are not exposed to the internet but are reachable from the server hosting Portkey. Additionally, the exfiltration of provider API keys grants unauthorized access to expensive AI model endpoints, leading to financial loss through malicious usage as well as potential abuse for generating harmful content under the victim's identity. This scenario aligns with CWE-918, which classifies Server-Side Request Forgery (SSRF), and maps directly to MITRE ATT&CK technique T1557, Adversary-in-the-Middle, where an attacker intercepts or manipulates communication between two parties to steal credentials or inject malicious data.
To mitigate this vulnerability, organizations running Portkey AI Gateway versions up to 1.15.2 should immediately upgrade to a patched version that includes the necessary request validation middleware for proxy routes. Until an update is applied, administrators can implement network-level controls such as firewall rules or reverse proxy configurations to block outbound connections from the gateway server to known internal IP ranges and cloud metadata endpoints. It is also critical to enforce strict allow-listing of permitted hostnames in any custom configuration options provided by the application. Security teams should audit access logs for unusual patterns involving the x-portkey-custom-host header and rotate all exposed API keys immediately if an exploit attempt is suspected, as credential compromise appears likely given the nature of the flaw.