Portkey AI Gateway: a header makes the gateway read loopback services

01What happened

VulnCheck published CVE-2026-110719 on October 14, 2026, a server-side request forgery in Portkey AI Gateway versions 1.14.0 through 1.15.2, credited to the researcher hieuPenguinnn. A public write-up locates the flaw at line 289 of the gateway's request validator and dates its source review to October 13, 2026. Neither VulnCheck nor the write-up names a patched version.

02How it works

The gateway uses the caller's x-portkey-custom-host header as the outbound base URL for provider requests. When TRUSTED_CUSTOM_HOSTS is unset, the isValidCustomHost check returns true for localhost, 127.0.0.1, ::1, host.docker.internal and *.localhost before its private-IP and metadata checks run. Because the /v1 routes carry no admin authentication and the ollama provider needs no API key, a POST to /v1/chat/completions naming a loopback host makes the gateway fetch that internal address and relay the response. The check reads the host string rather than the resolved IP, which the write-up notes leaves room for DNS rebinding.

03Who is affected

Self-hosted Portkey AI Gateway deployments on 1.14.0 through 1.15.2 without a narrowed TRUSTED_CUSTOM_HOSTS list are exposed, and most exposed when the /v1 routes are reachable from untrusted networks. The write-up says reach stops at loopback and Docker-host names: other private ranges, cloud metadata addresses and blocked TLDs are rejected, so this is not arbitrary internal-network access.

04What to do

Set TRUSTED_CUSTOM_HOSTS to an explicit, narrow list, since leaving it unset is what grants the loopback trust, and require caller authentication on the /v1 routes. The write-up also recommends resolving hostnames and checking the resolved IP immediately before connecting, and applying the private, reserved and metadata blocks to trusted hosts as well.

Questions people ask

Is there a patched version of Portkey AI Gateway for CVE-2026-110719?

No patched version appears in VulnCheck's advisory, the GitHub advisory entry or the researcher's write-up, which lists configuration changes only. Versions 1.14.0 through 1.15.2 are listed as affected with no fixed build named. Operators should narrow TRUSTED_CUSTOM_HOSTS and require authentication on the /v1 routes rather than waiting for a release.

How far can an attacker reach through this SSRF?

Reach stops at loopback addresses and Docker-host names, according to the researcher's write-up: other private ranges, cloud metadata addresses and blocked TLDs are rejected. An attacker can read responses from services bound to localhost and probe their ports, which the write-up calls a high confidentiality impact. The published CVSS v4 score of 6.9 rates that impact as low.

Does the attacker need a Portkey API key?

No key is needed for the path described. The write-up says the /v1 routes carry no admin authentication and the ollama provider requires no API key, so an unauthenticated POST to /v1/chat/completions with the crafted header is enough. Any gateway on these versions reachable from an untrusted network can therefore be probed by anyone who can send HTTP requests.

Sources 3 links, all fetched

1. 1vulncheck.comVulnCheck Advisory
2. 2github.comGitHub Advisory
3. 3hackmd.ioResearcher Write-Up