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

> Portkey AI Gateway treats localhost-style hosts as trusted by default, turning an unauthenticated API call into a loopback port reader.

- **Severity:** Medium: Real and reproducible, but needs unusual setup, user help or a narrow audience. Plan a fix.
- **Category:** Vulnerability
- **Published by:** VulnCheck
- **Disclosed:** 2026-10-14
- **CVE:** CVE-2026-110719
- **CVSS:** 6.9
- **Affects:** Portkey AI Gateway
- **Research by:** [hieuPenguinnn](https://github.com/hieuPenguinnn)
- **Primary source:** https://www.vulncheck.com/advisories/portkey-ai-gateway-1.14.0-through-1.15.2-ssrf-via-x-portkey-custom-host-header
- **Page:** https://theinjection.dev/items/portkey-ai-gateway-custom-host-ssrf/

Portkey AI Gateway 1.14.0 through 1.15.2 trusts localhost-style hosts in the x-portkey-custom-host header when TRUSTED_CUSTOM_HOSTS is unset. An unauthenticated request can then make the gateway read loopback services.

## What 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.

## How 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.

## Who 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.

## What 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.

## Quick facts

- **Affected:** Portkey AI Gateway 1.14.0 through 1.15.2
- **CVE:** CVE-2026-110719
- **CVSS:** 6.9, CVSS v4, medium, per VulnCheck and NVD
- **Found By:** hieuPenguinnn
- **Disclosed:** 2026-10-14
- **Fix:** No patched version stated; narrow TRUSTED_CUSTOM_HOSTS and authenticate /v1
- **Attack Type:** Unauthenticated SSRF via the x-portkey-custom-host header

## Questions

### 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

1. [VulnCheck Advisory](https://www.vulncheck.com/advisories/portkey-ai-gateway-1.14.0-through-1.15.2-ssrf-via-x-portkey-custom-host-header)
2. [GitHub Advisory](https://github.com/advisories/GHSA-h36v-27jx-93r3)
3. [Researcher Write-Up](https://hackmd.io/@1ExmmukzRMWN7B4gQ4W-4Q/BJypv-aiMg)