CVE-2026-77596 in Pipelines
Summary
by MITRE • 11/06/2026
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the multi-user HTTP endpoints POST /apis/v2beta1/pipelines/upload and POST /apis/v2beta1/pipelines/upload_version call canUploadVersionedPipeline, which returns without SubjectAccessReview when the target namespace is empty while REQUIRE_NAMESPACE_FOR_PIPELINES defaults to false. A low-privilege tenant can create shared pipelines or inject attacker-controlled versions into existing shared pipelines without the required write permission; if the API server is directly reachable without an authenticating proxy, an unauthenticated caller can exploit the same bypass, while deployments protected by such a proxy do not expose anonymous access. An enabled unpinned recurring run that follows the latest version can then execute the injected specification in another tenant's namespace under that workload's service account, while pinned or embedded-specification runs are not automatically substituted. This issue is fixed in version 2.18.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/06/2026
Kubeflow Pipelines serves as a critical infrastructure for orchestrating machine learning workflows, allowing organizations to build and deploy scalable data science processes. Within multi-user deployments of this platform, strict access control mechanisms are essential to prevent tenants from interfering with each other's resources or executing code under elevated privileges belonging to other users or system components. The vulnerability identified in versions prior to 2.18.0 represents a significant flaw in the authorization logic governing pipeline uploads and versioning operations. Specifically, the HTTP endpoints POST /apis/v2beta1/pipelines/upload and POST /apis/v2beta1/pipelines/upload_version invoke an internal function called canUploadVersionedPipeline to determine if a user has permission to perform these actions. This check relies on Kubernetes SubjectAccessReview resources to validate permissions against specific namespaces. However, the implementation contains a logic error where this security check is bypassed when the target namespace field in the request payload is left empty or null, provided that the global configuration flag REQUIRE_NAMESPACE_FOR_PIPELINES is set to its default value of false.
This architectural oversight allows low-privilege tenants to circumvent standard authorization controls. By omitting the namespace identifier during pipeline upload operations, an attacker can create shared pipelines in namespaces where they do not possess write permissions or inject maliciously crafted versions into existing shared pipelines owned by other users. The severity of this vulnerability is compounded when the API server is exposed directly without a preceding authenticating proxy that enforces strict access policies. In such configurations, unauthenticated callers may also exploit this bypass to upload arbitrary pipeline specifications. Conversely, deployments protected by an authenticating proxy typically mitigate anonymous access risks, though they do not fully resolve the underlying logic flaw if authenticated users with low privileges can still leverage the empty namespace condition. The core issue lies in the failure of the authorization handler to enforce namespace isolation when no explicit namespace is provided, effectively treating the request as valid for any target context rather than rejecting it or defaulting to a restricted scope.
The operational impact of this vulnerability extends beyond simple unauthorized resource creation; it facilitates privilege escalation and potential remote code execution within the cluster. Once an attacker successfully injects a malicious pipeline version into a shared namespace, they can exploit recurring runs that are configured to follow the latest version of a pipeline. If such a run is enabled and unpinned, it will automatically execute the newly injected specification under the service account associated with that workflow's namespace. This means the attacker’s code executes with the permissions granted to the target tenant’s workload identity, potentially leading to data exfiltration, lateral movement within the Kubernetes cluster, or compromise of downstream ML models and datasets. It is important to note that this exploitation path specifically targets unpinned recurring runs; pinned versions or embedded specifications are not automatically substituted by new uploads, which limits the attack surface but does not eliminate the risk for active workflows relying on dynamic version updates.
To mitigate this vulnerability, organizations must upgrade Kubeflow Pipelines to version 2.18.0 or later, where the authorization logic has been corrected to properly validate namespace requirements even when the field is empty. For environments that cannot immediately patch due to operational constraints, administrators should ensure that REQUIRE_NAMESPACE_FOR_PIPELINES is explicitly set to true in the configuration, forcing all pipeline uploads to specify a target namespace and thereby triggering the standard SubjectAccessReview checks. Additionally, deploying an authenticating proxy such as OPA Gatekeeper or a dedicated API gateway before the Kubeflow endpoint can enforce stricter access controls and prevent unauthenticated requests from reaching the vulnerable endpoints. Monitoring for anomalous pipeline upload patterns, particularly those involving empty namespaces or unexpected version updates in shared pipelines, provides an additional layer of defense-in-depth. This incident highlights the importance of rigorous input validation and explicit namespace enforcement in multi-tenant cloud-native applications to maintain strict isolation boundaries between users.