Where
-Infinity
0

Vendor Risk Score

See how portkey compares to other vendors in security performance

View Risk Score →
Severity
7.5
SSRF
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Portkey AI Gateway through 1.15.2 contains a server-side request forgery vulnerability in the /v1/proxy/ route that lacks requestValidator middleware. Attackers can set the x-portkey-custom-host header to internal addresses and forward requests with Authorization headers to reach internal services and exfiltrate provider API keys.

First published (updated )
Severity
9.8
SSRF
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Summary The gateway determines the destination baseURL by prioritizing the value in the x-portkey-custom-host request header. The proxy route then appends the client-specified path to perform an external fetch. This can be maliciously used by users for SSRF (CWE-918) attack

Impact This vulnerability can be exploited to force the server to make requests to arbitrary hosts on the internal network. This could allow an attacker to exfiltrate sensitive data, for instance, by accessing the AWS metadata service.

Patches The issue is patched in 1.14.0 (https://github.com/Portkey-AI/gateway/pull/1372)

The vulnerability resides within the gateway's request processing function which handles the x-portkey-custom-host header. This parameter was passed directly or with insufficient validation/sanitization to an internal HTTP request function.

The fix (v1.14.0) implements a robust allow-list policy:

1. All custom host inputs are now strictly validated to ensure the resulting URI points only to trusted, expected external services.

2. The implementation now explicitly blocks requests to non-routable IP addresses, loopback addresses, private networks and standard metadata endpoints.

Credit This vulnerability was discovered and reported responsibly by @im-soohyun. We thank them for their adherence to coordinated vulnerability disclosure principles.

References https://cwe.mitre.org/data/definitions/918.html

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203