Summary
Kubeflow Pipelines can skip a permission check on pipeline upload endpoints when the target namespace is empty and namespace enforcement is disabled. A low-privilege tenant may then create shared pipelines or add versions without the required write permission; in certain deployments, an unauthenticated caller may also reach the bypass.
Kubeflow Pipelines can skip a permission check on pipeline upload endpoints when the target namespace is empty and namespace enforcement is disabled. A low-privilege tenant may then create shared pipelines or add versions without the required write permission; in certain deployments, an unauthenticated caller may also reach the bypass.
Affected context
The issue occurs in the multi-user POST /apis/v2beta1/pipelines/upload and POST /apis/v2beta1/pipelines/upload_version endpoints when canUploadVersionedPipeline skips SubjectAccessReview for an empty target namespace and REQUIRE_NAMESPACE_FOR_PIPELINES is false. Anonymous access is a concern only when the API server is directly reachable without an authenticating proxy. A recurring run that follows the latest pipeline version may execute an injected specification in another tenant's namespace under that workload's service account; pinned versions and runs with embedded specifications are not automatically substituted.
The issue occurs in the multi-user POST /apis/v2beta1/pipelines/upload and POST /apis/v2beta1/pipelines/upload_version endpoints when canUploadVersionedPipeline skips SubjectAccessReview for an empty target namespace and REQUIRE_NAMESPACE_FOR_PIPELINES is false. Anonymous access is a concern only when the API server is directly reachable without an authenticating proxy. A recurring run that follows the latest pipeline version may execute an injected specification in another tenant's namespace under that workload's service account; pinned versions and runs with embedded specifications are not automatically substituted.
Exploit preconditions
- Attack surface: The multi-user pipeline upload and upload-version HTTP endpoints.
- Required access: A low-privilege tenant able to call the endpoints; an unauthenticated caller may be sufficient if the API server is reachable without an authenticating proxy.
- Trigger point: The upload authorization check encounters an empty target namespace while namespace enforcement is disabled.
- Why exploitation is possible: The code path returns without performing the required SubjectAccessReview, allowing a pipeline or version change without the caller's write permission.
- Further execution condition: A recurring run must be enabled and configured to follow the latest version for an injected specification to be selected automatically.
- Attack surface: The multi-user pipeline upload and upload-version HTTP endpoints.
- Required access: A low-privilege tenant able to call the endpoints; an unauthenticated caller may be sufficient if the API server is reachable without an authenticating proxy.
- Trigger point: The upload authorization check encounters an empty target namespace while namespace enforcement is disabled.
- Why exploitation is possible: The code path returns without performing the required SubjectAccessReview, allowing a pipeline or version change without the caller's write permission.
- Further execution condition: A recurring run must be enabled and configured to follow the latest version for an injected specification to be selected automatically.
Why this happens
The authorization logic conditionally omits a SubjectAccessReview when the target namespace is empty. This is a missing authorization check, mapping to CWE-862. The resulting ability to affect shared pipeline objects without the appropriate permission also relates to CWE-639, authorization bypass through a user-controlled key or identifier. The insecure pattern is allowing a missing or ambiguous resource scope to bypass authorization rather than rejecting the request or checking access explicitly.
The authorization logic conditionally omits a SubjectAccessReview when the target namespace is empty. This is a missing authorization check, mapping to CWE-862. The resulting ability to affect shared pipeline objects without the appropriate permission also relates to CWE-639, authorization bypass through a user-controlled key or identifier. The insecure pattern is allowing a missing or ambiguous resource scope to bypass authorization rather than rejecting the request or checking access explicitly.
Potential impact
- A tenant may create shared pipelines or add attacker-controlled versions without the required write permission.
- An enabled recurring run that tracks the latest version could execute an injected workflow specification in another tenant's namespace.
- The workflow may act with the permissions of its service account, potentially exposing or modifying resources available to that account.
- If the API server is reachable without an authenticating proxy, an unauthenticated caller may be able to make unauthorized changes.
- A tenant may create shared pipelines or add attacker-controlled versions without the required write permission.
- An enabled recurring run that tracks the latest version could execute an injected workflow specification in another tenant's namespace.
- The workflow may act with the permissions of its service account, potentially exposing or modifying resources available to that account.
- If the API server is reachable without an authenticating proxy, an unauthenticated caller may be able to make unauthorized changes.
General mitigation guidance
Defensive patterns include:
- Require an explicit, validated namespace for operations that create or modify pipeline resources.
- Ensure every upload path performs authorization checks, including when namespace or resource identifiers are absent or malformed.
- Default to denying requests when the authorization scope cannot be determined.
- Enforce tenant isolation and least-privilege permissions for pipeline and recurring-run service accounts.
- Place API endpoints behind an authenticating proxy where appropriate, while retaining authorization checks within the application.
- Consider pinning recurring runs to reviewed versions rather than implicitly following the latest version.
Defensive patterns include:
- Require an explicit, validated namespace for operations that create or modify pipeline resources.
- Ensure every upload path performs authorization checks, including when namespace or resource identifiers are absent or malformed.
- Default to denying requests when the authorization scope cannot be determined.
- Enforce tenant isolation and least-privilege permissions for pipeline and recurring-run service accounts.
- Place API endpoints behind an authenticating proxy where appropriate, while retaining authorization checks within the application.
- Consider pinning recurring runs to reviewed versions rather than implicitly following the latest version.
How teams detect issues like this
Review authorization code paths for early returns that skip SubjectAccessReview or equivalent checks when namespace values are empty, null, or invalid. Use static analysis and code review to identify pipeline upload handlers that mutate shared resources without consistently checking the caller's permissions. Policy checks can require explicit namespace validation and authorization on every mutation path. Monitor audit logs for unexpected pipeline creation or version uploads, especially changes to shared pipelines and activity associated with recurring runs.
Review authorization code paths for early returns that skip SubjectAccessReview or equivalent checks when namespace values are empty, null, or invalid. Use static analysis and code review to identify pipeline upload handlers that mutate shared resources without consistently checking the caller's permissions. Policy checks can require explicit namespace validation and authorization on every mutation path. Monitor audit logs for unexpected pipeline creation or version uploads, especially changes to shared pipelines and activity associated with recurring runs.
