Summary
Portkey AI Gateway contains a server-side request forgery vulnerability in custom-host validation, allowing unauthenticated attackers to make the gateway contact loopback and Docker host services. The issue becomes risky when the trusted custom-host policy is unset and attacker-controlled request headers influence outbound provider requests.
Portkey AI Gateway contains a server-side request forgery vulnerability in custom-host validation, allowing unauthenticated attackers to make the gateway contact loopback and Docker host services. The issue becomes risky when the trusted custom-host policy is unset and attacker-controlled request headers influence outbound provider requests.
Affected context
The vulnerability affects Portkey AI Gateway deployments in the affected release range when custom-host validation relies on localhost-style host acceptance and TRUSTED_CUSTOM_HOSTS is not configured. It can be reached through gateway request paths that process the x-portkey-custom-host header, including provider integrations such as Ollama.
The vulnerability affects Portkey AI Gateway deployments in the affected release range when custom-host validation relies on localhost-style host acceptance and TRUSTED_CUSTOM_HOSTS is not configured. It can be reached through gateway request paths that process the x-portkey-custom-host header, including provider integrations such as Ollama.
Exploit preconditions
- Attack surface: The externally reachable Portkey AI Gateway HTTP API
- Required access: No authentication is required when the affected request path is exposed
- Trigger point: Processing of a request that supplies an attacker-controlled custom-host value
- Why exploitation is possible: Host validation may trust loopback-style destinations when the trusted-host configuration is unset, allowing the gateway to issue server-side requests to internal services
- Attack surface: The externally reachable Portkey AI Gateway HTTP API
- Required access: No authentication is required when the affected request path is exposed
- Trigger point: Processing of a request that supplies an attacker-controlled custom-host value
- Why exploitation is possible: Host validation may trust loopback-style destinations when the trusted-host configuration is unset, allowing the gateway to issue server-side requests to internal services
Why this happens
The underlying bug is insufficient validation of an attacker-influenced destination before the gateway performs an outbound request. When the trusted custom-host policy is absent, localhost-style hosts may be treated as acceptable rather than denied by default. This behavior maps to CWE-918: Server-Side Request Forgery, because an external requester can influence the gateway into accessing resources from its own network position.
The underlying bug is insufficient validation of an attacker-influenced destination before the gateway performs an outbound request. When the trusted custom-host policy is absent, localhost-style hosts may be treated as acceptable rather than denied by default. This behavior maps to CWE-918: Server-Side Request Forgery, because an external requester can influence the gateway into accessing resources from its own network position.
Potential impact
- Attackers may access responses from loopback services
- Internal administrative or metadata endpoints could be exposed
- Docker host services may be queried from the gateway environment
- Internal network topology and service information could be disclosed
- Compromised internal services could enable further actions or lateral movement
- Attackers may access responses from loopback services
- Internal administrative or metadata endpoints could be exposed
- Docker host services may be queried from the gateway environment
- Internal network topology and service information could be disclosed
- Compromised internal services could enable further actions or lateral movement
General mitigation guidance
Mitigation generally focuses on making outbound destination validation deny-by-default and reducing trust in request-supplied host values.
Common defensive patterns include:
- Require an explicit allowlist for permitted custom hosts
- Reject loopback, link-local, private, carrier-grade NAT, and other restricted address ranges unless explicitly required
- Resolve hostnames and validate the resulting addresses before connecting, including protections against DNS rebinding
- Keep trusted-host configuration explicit and fail closed when it is absent or invalid
- Restrict gateway egress with network policies, firewall rules, and separate service identities
- Avoid returning unrestricted upstream responses to untrusted clients
- Run the gateway with only the network and service privileges it needs
Mitigation generally focuses on making outbound destination validation deny-by-default and reducing trust in request-supplied host values.
Common defensive patterns include:
- Require an explicit allowlist for permitted custom hosts
- Reject loopback, link-local, private, carrier-grade NAT, and other restricted address ranges unless explicitly required
- Resolve hostnames and validate the resulting addresses before connecting, including protections against DNS rebinding
- Keep trusted-host configuration explicit and fail closed when it is absent or invalid
- Restrict gateway egress with network policies, firewall rules, and separate service identities
- Avoid returning unrestricted upstream responses to untrusted clients
- Run the gateway with only the network and service privileges it needs
How teams detect issues like this
Detection approaches can include:
- Static analysis for request-derived URLs, hosts, or proxy targets used in outbound HTTP clients
- Code review checks for allowlists that are optional, empty, or fail open
- Tests covering loopback, private, link-local, IPv6 local, and DNS-rebinding destinations
- Gateway logs correlating custom-host headers with outbound requests to restricted address ranges
- Network monitoring for unexpected connections from the gateway to Docker, metadata, and internal administrative services
- Policy enforcement that requires explicit egress controls and trusted-host configuration
Automated security review tools may help identify SSRF-prone URL construction and incomplete destination validation.
Detection approaches can include:
- Static analysis for request-derived URLs, hosts, or proxy targets used in outbound HTTP clients
- Code review checks for allowlists that are optional, empty, or fail open
- Tests covering loopback, private, link-local, IPv6 local, and DNS-rebinding destinations
- Gateway logs correlating custom-host headers with outbound requests to restricted address ranges
- Network monitoring for unexpected connections from the gateway to Docker, metadata, and internal administrative services
- Policy enforcement that requires explicit egress controls and trusted-host configuration
Automated security review tools may help identify SSRF-prone URL construction and incomplete destination validation.
