Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-11-05T23:17:00.767Z",
  "pubdate": "2026-11-05T23:17:00.767Z",
  "executiveSummary": "A critical authorization bypass vulnerability exists in Kubeflow Pipelines prior to version 2.18.0, stemming from improper validation logic within the multi-user HTTP endpoints responsible for pipeline uploads.\nThe vulnerability allows low-privilege tenants or unauthenticated attackers to bypass SubjectAccessReview checks, enabling unauthorized creation of shared pipelines or the injection of malicious versions into existing workflows.\nThe root cause is a flaw in the canUploadVersionedPipeline function, which fails to enforce access control when the target namespace is empty and the REQUIRE_NAMESPACE_FOR_PIPELINES configuration is disabled.\nExploitation can lead to remote code execution within another tenant's namespace, as unpinned recurring runs may automatically execute the attacker-controlled pipeline specifications using the victim's service account credentials.\nThe risk is significantly elevated in deployments where the API server is directly reachable without an authenticating proxy, as it permits unauthenticated access to the vulnerable endpoints.\nOrganizations using Kubeflow Pipelines are at high risk of lateral movement and cross-tenant resource manipulation until the software is updated to version 2.18.0.",
  "technicalDetails": "The vulnerability resides in the API server's handling of pipeline uploads, specifically within the POST /apis/v2beta1/pipelines/upload and POST /apis/v2beta1/pipelines/upload_version endpoints.\nThe logic failure occurs in the canUploadVersionedPipeline function. When the target namespace is not specified (empty), the function fails to initiate a SubjectAccessReview. This bypass is triggered because the default configuration for REQUIRE_NAMESPACE_FOR_PIPELINES is set to false, resulting in a failure to verify user write permissions during the pipeline upload process.\nIn environments where an authenticating proxy is absent, this bypass allows unauthenticated actors to interact with the API server, treating the request as authorized. Even within authenticated environments, a low-privilege tenant can leverage this logic error to gain unauthorized write access to global or shared pipeline repositories.\nThe attack flow involves an adversary crafting a POST request containing a malicious pipeline specification. By targeting an empty namespace, the attacker circumvents the standard Kubernetes RBAC checks managed by the SubjectAccessReview interface. Once the malicious pipeline or version is successfully injected into the system, the adversary can wait for existing unpinned recurring runs to trigger.\nBecause these recurring runs are configured to track the 'latest' version, the system automatically pulls and executes the attacker-injected specification. Crucially, this execution occurs within the context of the target tenant's namespace and utilizes that workload's service account tokens.\nThe impact is significant, as the attacker effectively gains the ability to execute arbitrary containerized workloads within another tenant's environment, leading to full compromise of the affected ML workflow and potential access to sensitive data or credentials held by the victim's service account. Pinned runs and those using embedded specifications remain unaffected by this automatic substitution, limiting the scope of exploitation to dynamic, version-tracking deployments.\nAffected versions are all releases prior to 2.18.0. The remediation provided in 2.18.0 corrects the authorization flow to ensure that SubjectAccessReview is performed regardless of namespace configuration, effectively closing the bypass mechanism."
}