- NIST's NVD records that Portkey AI Gateway 1.14.0 through 1.15.2 can be made to call internal services by unauthenticated attackers (CVE-2026-110719).
- The record ties the flaw to the TRUSTED_CUSTOM_HOSTS setting being unset, so any deployment that has not configured it is exposed.
- Teams running these versions should check their version, whether that setting is configured, and what internal services sit beside the gateway.
A helper that dials any number it is given
Picture a receptionist who will phone any number a visitor writes on a slip of paper. That includes internal extensions the visitor could never reach alone. The visitor never breaks in. The receptionist makes the call.
That is the shape of CVE-2026-110719, a flaw in Portkey AI Gateway. The lesson here is that a gateway whose destination is chosen by the caller is only as safe as the setting that restricts it.
What NIST recorded
The NIST National Vulnerability Database published the record on October 14, 2026. It says Portkey AI Gateway versions 1.14.0 through 1.15.2 contain a server-side request forgery flaw. The score was assigned by VulnCheck.
Server-side request forgery, or SSRF, means an attacker tricks a server into making a network request for them. The server sits inside the network. It can often reach places an outsider cannot.
How the flaw works
The gateway reads a request header named x-portkey-custom-host. The header tells it which host to call. A function named isValidCustomHost is meant to decide whether that host is acceptable.
According to the record, the function trusts localhost-style hosts when a setting called TRUSTED_CUSTOM_HOSTS is unset. So any instance where that setting has not been configured accepts the machine's own addresses.
An attacker sends a request to a /v1 path with a crafted header. The record gives the ollama provider as one example route. The gateway then calls an internal service and returns what it says.
The record names two targets: loopback services and Docker host services. Loopback is the machine's own internal address. The Docker host is the machine that runs the containers. The attacker needs no login.
What the scores say
VulnCheck scored the flaw under two systems. Both describe an attack over the network, with low complexity, no privileges and no user action. The older system also marks the scope as changed, meaning the harm reaches beyond the gateway itself.
Both vectors rate the impact on confidentiality and integrity as low. Those scores describe the flaw in general. Real exposure depends on what listens beside the gateway on the same host.
Unset is not the same as safe
A gateway exists to forward requests. The design question is who picks the destination. In these versions, the caller supplies it through a header. The record says the check trusts local addresses whenever TRUSTED_CUSTOM_HOSTS is unset.
This shows how a restriction that depends on configuration works. Any deployment that has not configured the setting is exposed. Any team running these versions without setting it carries that exposure.
The record states the condition. It does not say whether the setting ships unset or how the vendor documents it. This is one record about one product, not proof of a wider pattern.
The record also does not say whether attacks have occurred. It does not name a fixed version. It lists the Portkey repository and a VulnCheck advisory as references.
Questions to put to your team
First, do we run Portkey AI Gateway, and is any instance between 1.14.0 and 1.15.2? Include instances that product teams run outside central IT.
Second, is TRUSTED_CUSTOM_HOSTS set on each instance? Third, can the gateway be reached from outside the company network?
Fourth, what runs on the same host or Docker host that the gateway could be made to call? Fifth, do logs show requests carrying an x-portkey-custom-host header from unknown sources? Check the Portkey repository and the VulnCheck advisory listed in the record for remediation details.
A gateway should only call the places you have named. If it will call whatever a stranger names, it is working for the stranger.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
