CVE-2026-54745: Kubeflow Pipelines: Unauthenticated SSRF and HTTP smuggling in Kubeflow Pipelines frontend /_proxy/ route, bypasses ENABLE_AUTHZ=true
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.17.0, the Kubeflow Pipelines frontend exposes an unauthenticated server-side request forgery vulnerability through the /proxy/ route in frontend/server/proxy-middleware.ts. The routePathWithReferer() function accepts an arbitrary attacker-controlled HTTP or HTTPS target and passes its origin to createProxyMiddleware without a host allowlist or filtering for loopback, link-local, RFC1918, or cluster-local addresses. The route remains outside the authorization middleware when ENABLEAUTHZ=true and is reachable through /apis/v1beta1/proxy/, /apis/v2beta1/proxy/, /pipeline/apis/v1beta1/proxy/, and /pipeline/apis/v2beta1/proxy/, including through a crafted Referer header. Requests can forward attacker-controlled methods, headers such as Authorization, Cookie, and X-Forwarded-For, and POST bodies to reachable internal services, while returning the upstream response to the unauthenticated client. This can expose cloud metadata credentials, Kubernetes or service APIs, and other cluster-internal endpoints to unauthorized read or modification. This issue is fixed in version 2.17.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Kubeflow Pipelines frontendto a version that resolves this vulnerability.Fixed in 2.17.0
Event History
Frequently Asked Questions
Does enabling authorization protect the affected proxy endpoints?
No. The proxy route remains outside the authorization middleware even when ENABLE_AUTHZ=true, so it can be reached without authentication.
What access does an attacker need to exploit this issue?
An attacker needs network access to the Kubeflow Pipelines frontend route. They do not need credentials, user interaction, or pre-existing privileges, and can direct the frontend to HTTP or HTTPS targets reachable from the server.
Which internal resources can be reached through the vulnerable route?
The route does not restrict loopback, link-local, RFC1918, or cluster-local addresses. This can expose reachable cloud metadata services, Kubernetes or service APIs, and other internal endpoints; attacker-controlled request methods, headers, and POST bodies may be forwarded.
Which paths expose the proxy functionality?
The affected functionality is reachable through /apis/v1beta1/_proxy/, /apis/v2beta1/_proxy/, /pipeline/apis/v1beta1/_proxy/, and /pipeline/apis/v2beta1/_proxy/. A crafted Referer header can also be used to influence the target route.