CVE-2026-118759: Kubeflow Pipelines: Run log streaming endpoint bypasses namespace authorization, exposing pod execution logs cross-tenant

Published Oct 29, 2026

Updated

Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the API server's GET /apis/v1alpha1/runs/{runid}/nodes/{nodeid}/log handler retrieved logs without authorizing the caller against the selected run. A caller who can reach the backend and knows a victim run ID and suitable pod or node identifier can read live or archived logs with the API server's permissions. For live logs, the caller-controlled node ID was also accepted as a pod name without verifying that the pod belonged to the requested run, allowing a known run ID to select the namespace of an unrelated pod and read its main container logs. The handler does not authenticate requests itself, although an external authentication gate or network policy can limit reachability. Exposed logs can contain sensitive workload data or credentials. This issue is fixed in version 2.18.0.

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Kubeflow Pipelines to a version that resolves this vulnerability.
Fixed in 2.18.0
Compensating control
Place the API server behind an external authentication gate or network policy to limit reachability to the run log streaming endpoint.

Frequently Asked Questions

Who can exploit this issue in practice?

Any caller that can reach the Kubeflow Pipelines API backend may exploit it because the affected log handler does not authenticate requests itself. External authentication gateways or network policies can limit who can reach the backend.

What information does an attacker need to retrieve logs?

The attacker needs a victim run ID and a suitable pod or node identifier. For live logs, the node ID can be supplied as a pod name, enabling access to the main-container logs of an unrelated pod in the namespace selected by a known run ID.

Are deployments protected by default?

The handler itself performs no authentication or authorization for the selected run. Protection depends on whether an external authentication gate or network policy prevents untrusted callers from reaching the backend.

What should be done if an immediate upgrade is not possible?

Restrict network access to the Kubeflow Pipelines API backend and enforce authentication through an external gate. Limit backend reachability to trusted users and services until the deployment can be updated to version 2.18.0.