CVE Alert: CVE-2026-110719 – Portkey-AI

Portkey AI Gateway 1.14.0 through 1.15.2 contains a server-side request forgery vulnerability that allows unauthenticated attackers to reach loopback and Docker host services because isValidCustomHost trusts localhost-style hosts when TRUSTED_CUSTOM_HOSTS is unset. Attackers can send /v1 requests with a crafted x-portkey-custom-host header, such as via the ollama provider, to make the gateway call internal services and return their responses.

**Risk verdict:** Treat internet-exposed instances as urgent to assess and remediate; no KEV, active SSVC exploitation, or EPSS data is supplied to confirm immediate in-the-wild priority.

**Why this matters:** An unauthenticated attacker may use the service as a bridge to internal endpoints, potentially exposing data or enabling limited changes in reachable services. The stated impact is constrained, but consequences depend on what internal services trust the gateway and what credentials or sensitive data they expose.

**Most likely attack path:** A remote attacker sends a crafted request, with no special privileges or user interaction required, and the gateway makes a request to an attacker-chosen internal destination. The changed scope means effects may extend beyond the gateway host; access to loopback or container-host services increases lateral-movement potential.

**Who is most exposed:** Prioritise internet-facing deployments, especially containerised environments where host or orchestration services are reachable, and installations that leave trusted custom-host restrictions unset.

Review inbound requests for unusual `x-portkey-custom-host` values, especially loopback, private, or link-local destinations.

Correlate gateway outbound connections to internal addresses with the initiating request.

Check access and application logs for unexpected responses from local or container-host services.

Establish whether the affected configuration and request pattern are present; exploitation telemetry and PoC status are not provided.

Mitigation and prioritisation

Upgrade to a vendor-fixed release; confirm the fixed release with the maintainer before scheduling.

Until upgraded, restrict network access to the gateway and block its egress to loopback, private, and host-management ranges where feasible.

Explicitly configure trusted custom hosts; do not rely on unset defaults.

Test provider integrations in staging, then deploy through normal change control; review logs and credentials potentially exposed.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.