Kubeflow Pipelines 2.18.0 fixes unauthorized pod-log reads and a pre-authorization decompression bomb (CVE-2026-118759, CVE-2026-118761)
Kubeflow published two advisories on Oct 30 for the Kubeflow Pipelines API server, the ML workflow component many teams run for training and evaluation jobs. Both are fixed in 2.18.0; releases through 2.17.3 are affected.
- CVE-2026-118759 (pod logs, 7.5):
GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/logfetched logs without authorizing the caller against the run. For live logs it also took the node ID as any pod name in the run's namespace, so a known run ID could expose an unrelated pod'smaincontainer logs, depending on the API server's permissions. The fix requires thereadLogverb onrunsand checks the pod'spipeline/runidlabel. Custom roles needreadLogadded. - CVE-2026-118761 (decompression bomb, 7.5): multipart pipeline uploads were decompressed before namespace authorization, so a caller who could reach the endpoint could exhaust API-server memory with a small ZIP or tar.gz without pipeline-create rights.
What to do: upgrade to 2.18.0 and review its new upload limits. Until then, keep the log and upload endpoints behind authentication at the ingress, and treat pipeline logs as sensitive, since they often hold tokens.
Sources: GHSA-wg5q-x4j9-qm54: run-log endpoint (Oct 30) · GHSA-8fmv-6rg5-5924: archive upload (Oct 30) · Kubeflow Pipelines 2.18.0 release