Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "10.0",
  "pubDate": "2026-08-28T20:18:17.240Z",
  "pubdate": "2026-08-28T20:18:17.240Z",
  "executiveSummary": "This vulnerability is an unauthenticated Server-Side Request Forgery (SSRF) flaw residing within the Kubeflow Pipelines frontend. It affects versions prior to 2.17.0, posing a critical security risk to the integrity and confidentiality of Kubernetes clusters.\nThe vulnerability occurs because the /_proxy/ route fails to implement necessary request validation, allowing unauthenticated attackers to force the server to proxy requests to arbitrary internal destinations. By bypassing authorization middleware, the attacker gains the ability to interact with sensitive internal services that are otherwise unreachable from the public internet.\nThe potential impact includes the unauthorized extraction of cloud metadata credentials, interaction with internal Kubernetes service APIs, and the unauthorized modification or exfiltration of data from internal network endpoints. This vulnerability permits an attacker to pivot from an unauthenticated external position into the internal cluster network, essentially weaponizing the frontend service as a proxy agent. No specific authentication is required to trigger this vulnerability, making it highly accessible for exploitation in exposed Kubeflow deployments.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the proxy-middleware within the Kubeflow Pipelines frontend. Specifically, the function _routePathWithReferer() inside frontend/server/proxy-middleware.ts fails to perform any input sanitization or validation on target URLs passed to the createProxyMiddleware function.\nThe proxy mechanism lacks an allowlist for destination hosts and fails to enforce filtering against loopback (127.0.0.1/::1), link-local (169.254.169.254), RFC1918, or cluster-local IP addresses. Furthermore, these proxy routes—accessible via paths such as /apis/v1beta1/_proxy/, /apis/v2beta1/_proxy/, /pipeline/apis/v1beta1/_proxy/, and /pipeline/apis/v2beta1/_proxy/—are explicitly excluded from the ENABLE_AUTHZ=true authorization middleware, rendering them accessible to any unauthenticated client.\nThe attack flow begins with an attacker crafting a request directed at any of the identified /_proxy/ endpoints. By manipulating the Referer header or the request parameters, the attacker forces the frontend service to forward a request to an attacker-specified target. Because the proxy middleware forwards sensitive request headers—including Authorization, Cookie, and X-Forwarded-For—as well as arbitrary POST bodies, the attacker can impersonate the frontend service's identity to internal APIs.\nOnce the request is successfully forwarded, the frontend service retrieves the response from the internal service and relays it back to the unauthorized client. This allows for the systematic discovery and exploitation of internal infrastructure. For example, an attacker could target the cloud provider's Instance Metadata Service (IMDS) at 169.254.169.254 to extract temporary security credentials (IAM roles) associated with the Kubernetes worker nodes. Additionally, they could interact with the Kubernetes API server or other internal microservices to conduct privilege escalation or lateral movement within the cluster.\nThe vulnerability is explicitly version-dependent, impacting all Kubeflow Pipelines releases prior to 2.17.0. Because the proxy logic operates at the application level within the frontend container, the exploit payload is processed server-side, and the internal service perceives the request as originating from a legitimate, trusted internal cluster component, effectively bypassing network perimeter security controls."
}