Kubeflow Pipelines: Run-log endpoint permits unauthorized access to pod logsGHSA-wg5q-x4j9-qm54
HIGHFix: kubeflow/pipelines#13684GHSA-wg5q-x4j9-qm54 is a high-severity (CVSS 7.5) Information Exposure vulnerability in github.com/kubeflow/pipelines. A fix is available for github.com/kubeflow/pipelines — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-wg5q-x4j9-qm54.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-wg5q-x4j9-qm54 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 398,142 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/kubeflow/pipelines🐹github.com/kubeflow/pipelinesReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The Kubeflow Pipelines API server's GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log handler retrieves logs without authorizing the caller against the selected run. A caller who can reach the backend and knows a victim run ID and a suitable pod or node identifier can read live or archived logs using the API server's permissions.
For live logs, the vulnerable handler also accepts the supplied node ID as a pod name in the run's namespace without verifying that the pod belongs to the run. Depending on the API server's pod-log permissions, a known run ID can therefore permit reading the main container logs of an unrelated pod in that namespace. Logs may contain sensitive workload data or credentials.
The affected handler does not authenticate the request itself. An external authentication gate or network policy can restrict reachability; public ingress exposure and unauthenticated enumeration of run IDs are not assumed.
Remediation
Upgrade the API server to Kubeflow Pipelines 2.18.0. Versions through 2.17.3 are affected; the first affected release has not been established.
PR #13684 authorizes the caller with the readLog verb before retrieving live or archived logs. For live logs, it also verifies that the pod's pipeline/runid label matches the requested run. Custom Kubernetes roles must grant readLog on runs in the pipelines.kubeflow.org API group; the bundled viewer and editor roles include it. Shared read access alone does not grant log access.
Until upgrading, restrict access to the backend log endpoint. Focused regression tests cover authorization denial, HTTP identity propagation, pod/run mismatch, archive retrieval, and cancellation; no new deployed-cluster end-to-end test was performed for this assessment.
Credit
bugbunny.ai discovered and reported the issue. Nayyar (@naruto-lgtm) authored the fix in #13684.
@patchmyday, @thesecguy45, @VitoCrl, @Grg0rry, @arpitjain099, and @BrianWillows made later submissions concerning the run-log authorization gap. MUTEDCYBERSECURITY S.L. separately reported a synthetic two-tenant reproduction, including the unrelated-pod log path.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/kubeflow/pipelines | all versions | 0.0.0-20260904182349-be4723e33727go get github.com/kubeflow/pipelines@v0.0.0-20260904182349-be4723e33727 |
| 🐹Go | github.com/kubeflow/pipelines | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/kubeflow/pipelines, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/kubeflow/pipelines to 0.0.0-20260904182349-be4723e33727 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wg5q-x4j9-qm54 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-wg5q-x4j9-qm54 in your dependencies?
Find it across Go, including transitive dependencies.