CVE-2026-77596

In Kubeflow Pipelines prior to 2.16.1, the multi-user API server treats the empty namespace used by shared or global pipelines as an authorization exception for modification and deletion operations. An authenticated user can modify or delete shared pipeline definitions and versions without the required Kubernetes RBAC permissions, compromising their integrity and availability.

In Kubeflow Pipelines prior to 2.18.0, the frontend artifact download path for source=s3 or source=minio accepts providerInfo.Params.endpoint, and the archived pod-log path accepts S3-compatible endpoint metadata from workflow status, without requiring those endpoints to match operator-controlled storage configuration. In the shipped authorization-disabled standalone configuration, an unauthenticated caller can make the shared ml-pipeline-ui pod connect to arbitrary reachable hosts and return response data; requests may also reveal an access-key identifier when signed with configured object-store credentials.

In Kubeflow Pipelines prior to 2.18.0, the frontend GET /artifacts/get route accepts source=http or source=https with caller-controlled bucket and key values, and isAllowedResourceName permits an all-digit decimal host that the URL parser converts to an IPv4 address. The default ALLOWED_ARTIFACT_DOMAIN_REGEX and authorization-disabled standalone configuration allow an unauthenticated caller to fetch internal HTTP resources and receive their response body.

Kubeflow Pipelines before version 2.17.0 has an unauthenticated SSRF vulnerability in the /_proxy/ route in frontend/server/proxy-middleware.ts. The _routePathWithReferer() function accepts an arbitrary attacker-controlled HTTP or HTTPS target and passes its origin to createProxyMiddleware without a host allowlist or filtering for loopback, link-local, RFC1918, or cluster-local addresses. The route is accessible without authorization, allowing requests to be forwarded to internal services and responses returned to the attacker. This issue is fixed in version 2.17.0.

In Kubeflow Pipelines prior to 2.18.0, the API server decompressed uploaded pipeline archives without adequately bounding expanded data while locating or reading the pipeline file. A small ZIP or gzip-compressed tar archive can consume disproportionately large memory and exhaust API-server resources. Multipart pipeline and pipeline-version upload processing performs decompression before namespace authorization, so a reachable caller does not need a successful pipeline-create authorization decision. This is fixed in version 2.18.0.

In Kubeflow Pipelines from 0.5.1 until 2.17.0, frontend artifact routes did not check whether an authenticated user was authorized to access the requested namespace. A user knowing an artifact location could select another tenant's namespace or omit the namespace to read artifact contents such as datasets, models, or pipeline outputs.

In Kubeflow Pipelines prior to 2.18.0, the GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log handler retrieved logs without authorizing the caller against the selected run. A caller knowing a run ID and pod or node identifier could read logs with the API server's permissions, and for live logs the node ID was accepted as a pod name without verifying pod membership in the run.

In Kubeflow Pipelines prior to 2.18.0, the volume artifact handler GET /artifacts/get?source=volume did not confine a caller-supplied file path to the selected volume. A caller knowing an existing mounted volume could use path traversal to read files outside it when the artifact-serving process could read them.