CVE-2026-54745 in Pipelines
Summary
by MITRE • 08/28/2026
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 ENABLE_AUTHZ=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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2026
Kubeflow Pipelines serves as a critical infrastructure for orchestrating machine learning workflows, yet prior to version 2.17.0, it contained a severe server-side request forgery vulnerability within its frontend proxy middleware. The flaw resides in the /_proxy/ route located at frontend/server/proxy-middleware.ts and is triggered by the _routePathWithReferer() function. This component was designed to facilitate proxied requests but failed to implement adequate security controls, specifically lacking a host allowlist or filtering mechanisms for loopback, link-local, RFC1918 private addresses, or cluster-internal endpoints. Consequently, an attacker could supply arbitrary HTTP or HTTPS targets in the request origin, allowing them to direct internal traffic toward sensitive backend services that are not intended for external access.
The operational impact of this vulnerability is significant because the affected proxy routes remain outside the authorization middleware even when authentication and authorization features are enabled via ENABLE_AUTHZ=true. This architectural oversight means that unauthenticated users can interact with endpoints such as /apis/v1beta1/_proxy/, /apis/v2beta1/_proxy/, /pipeline/apis/v1beta1/_proxy/, and /pipeline/apis/v2beta1/_proxy/. By crafting specific requests, often leveraging the Referer header to manipulate the target origin, attackers can forward arbitrary HTTP methods, headers including Authorization, Cookie, and X-Forwarded-For, as well as POST request bodies. The proxy then executes these requests against internal services and returns the upstream response directly to the unauthenticated client, effectively bypassing all access controls.
This misconfiguration exposes critical cloud metadata credentials, Kubernetes API endpoints, service APIs, and other cluster-internal resources to unauthorized parties. Attackers can perform both read and modification operations on sensitive data within the cluster environment. From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) due to the server making requests on behalf of an unauthenticated user to arbitrary destinations without proper validation. Furthermore, it relates to CWE-200 Information Exposure and CWE-749 Exposed Dangerous Method or Function because internal APIs are made accessible through a public-facing interface. In terms of adversary tactics, this aligns with MITRE ATT&CK technique T1557 Adversary-in-the-Middle as the proxy acts as an intermediary for unauthorized access to backend services, and potentially T1098 Account Manipulation if credentials obtained via SSRF are used to escalate privileges within the cluster.
To mitigate this risk, organizations must upgrade Kubeflow Pipelines to version 2.17.0 or later where these security controls have been implemented. Until an upgrade is feasible, administrators should ensure that the frontend service is not directly exposed to untrusted networks and rely on network-level policies such as Kubernetes NetworkPolicies to restrict egress traffic from the proxy pods to only necessary internal services. Additionally, implementing a Web Application Firewall with strict SSRF protection rules can help block requests containing suspicious target origins or private IP ranges before they reach the vulnerable application logic.