Kubeflow Pipelines CVE-2026-118759

Exploitation requires network reachability to the Kubeflow Pipelines API server backend AND knowledge of a valid victim run ID plus a usable pod or node identifier; the vulnerable GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log handler then returns logs without authorizing the caller against that run. For live logs, the caller-controlled node ID is accepted as a pod name in the run's namespace with no check that the pod's pipeline/runid label matches, so a known run ID lets an attacker read the main container logs of unrelated pods in that namespace, bounded by the API server's own pod-log RBAC. Limiting factors explicitly stated by the vendor: the handler performs no authentication itself, so an external authentication gate or network policy can restrict reachability; public ingress exposure and unauthenticated run-ID enumeration are not assumed. Deployments that independently enforce authentication have materially more restricted exposure.

This is a genuine, actionable information-disclosure flaw rather than a CVSS-inflated non-issue, but its real-world severity is strongly deployment-dependent. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5) reflects network-reachable access to the API server with no application-layer authentication: the GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log handler never authorized the caller against the run (CWE-862 per the GHSA advisory, recorded as CWE-200 in the CVE). The vuln.today decision label is 'this_week', indicating prompt but not emergency remediation. No EPSS score and no CISA KEV status were provided in the input, and there is no public exploit identified at time of analysis - only fix artifacts (advisory, PR #13684, commit, release) are referenced, not weaponized exploit code; the advisory mentions a privately reported synthetic two-tenant reproduction, not a published PoC. The key tension is that the raw PR:N score assumes no independent authentication gate: the advisory explicitly states that the handler does not authenticate requests itself and that an external authentication gate or network policy can restrict reachability, and that public ingress exposure and unauthenticated run-ID enumeration are NOT assumed. Therefore clusters that front the API server with authn (e.g. via Istio/oauth2-proxy) or network policy face materially lower real exposure than the headline 7.5 suggests, while flat-network or weakly-gated deployments are fully exposed. Treat as a prioritized patch for ML platform operators, weighted by whether the backend is independently gated.

An attacker who can reach the Kubeflow Pipelines backend (e.g. a low-privilege tenant on the cluster network or anyone past a missing auth gate) learns a victim's run ID and a pod or node identifier, then calls GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log. Because the handler never checks that the caller owns the run - and, for live logs, never verifies the pod actually belongs to that run - the attacker reads the main container logs with the API server's own permissions, harvesting workload data or credentials. No public exploit code is identified at time of analysis; exploitation requires only standard HTTP requests with the right identifiers.