Description

Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.17.0, the API server's pipeline and pipeline-version creation paths fetch a caller-supplied pipelineURL without restricting the destination. An authenticated caller with permission to create a pipeline or pipeline version can make requests from the API server to internal services and observe a limited status-code oracle. Arbitrary response-body disclosure, credential theft, and integrity or availability impact are not established. This issue is fixed in version 2.17.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-11-05T22:18:54.417Z",
  "pubdate": "2026-11-05T22:18:54.417Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in Kubeflow Pipelines prior to version 2.17.0. The vulnerability resides within the API server's pipeline and pipeline-version creation endpoints, where the system fails to adequately validate or restrict the destination of user-supplied pipelineURL parameters.\nThe vulnerability allows an authenticated attacker with permissions to create pipelines or pipeline versions to coerce the Kubeflow API server into initiating outbound network requests to arbitrary internal infrastructure. This enables the attacker to probe internal services and network segments that are otherwise inaccessible from outside the cluster.\nWhile the current exploitability is limited to a status-code oracle, which restricts the ability to exfiltrate arbitrary response bodies, the risk remains significant due to the potential for reconnaissance, service disruption, and identification of internal API endpoints.\nThe impact is constrained by the lack of direct data exfiltration in this specific vector, but the ability to perform blind SSRF presents a critical information disclosure risk regarding internal network topology. Exploitation requires existing authenticated access to the Kubeflow API.",
  "technicalDetails": "The vulnerability originates from insufficient input sanitization within the Kubeflow Pipelines API server, specifically during the handling of pipeline definition requests. The affected code paths, responsible for processing pipeline and pipeline-version creation, accept a caller-supplied 'pipelineURL' parameter which is subsequently fetched by the backend API server process.\nBecause the server-side implementation lacks a restrictive allowlist or an egress filtering mechanism, it performs an unvalidated GET request to the URI provided in the 'pipelineURL' field. This behavior transforms the API server into a proxy for arbitrary network requests, effectively bypassing network security perimeters such as firewalls or network policies that typically segregate the internal control plane from the public-facing API.\nThe attack flow proceeds as follows: 1) An attacker with authenticated access to the Kubeflow Pipelines API identifies the pipeline creation or versioning endpoint. 2) The attacker crafts a request containing a 'pipelineURL' pointing to an internal resource (e.g., internal metadata services, Kubernetes cluster services, or private cloud-provider metadata endpoints). 3) The API server, acting as the initiator of the request, attempts to resolve and connect to the specified internal target. 4) The API server receives a response from the internal service and returns the status code of the interaction to the caller.\nBy observing these status codes, the attacker can conduct port scanning and service discovery. For instance, receiving a '200 OK' versus a 'Connection Refused' or '404 Not Found' allows the attacker to determine the presence or absence of specific internal services or identify which ports are open. This 'status-code oracle' enables systematic mapping of the internal infrastructure.\nThe vulnerable component is the API server processing logic which fails to implement egress controls or restrict the scheme and host components of the 'pipelineURL'. This issue is present in all versions of Kubeflow Pipelines prior to 2.17.0. Because the API server is already a trusted identity within the Kubernetes environment, the requests originating from it may have elevated visibility or implied access to internal REST APIs that do not require additional authentication headers beyond cluster membership, depending on the internal service's configuration. Although the vulnerability does not currently facilitate arbitrary body disclosure or remote code execution, it establishes the primary vehicle for deeper internal reconnaissance."
}