Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows

Why it is Yellow

• CVSS 9.6 critical

References

• https://github.com/kubeflow/pipelines/commit/62516d8c525f146b754cb515cf441dd0290ad841
• https://github.com/kubeflow/pipelines/pull/14352
• https://github.com/kubeflow/pipelines/releases/tag/2.18.0
• https://github.com/kubeflow/pipelines/security/advisories/GHSA-rjr3-43j3-4q8g

Original 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.