Kubeflow: Unauthenticated path traversal to arbitrary file read on ml-pipeline-ui via the volume artifact source
Kubeflow Pipelines 2.17.3 and earlier are affected, in setups where the volume artifact route is reachable by a caller who can identify a mounted volume. Fixed in 2.18.0.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 2.18.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
Kubeflow Pipelines, the machine learning workflow platform, is affected through its ml-pipeline-ui artifact-serving route. An attacker who can reach that route can read arbitrary files that the serving process can access, such as sensitive configuration or credentials, and in deployments with authentication disabled no login is needed.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the volume artifact handler for GET /artifacts/get?source=volume did not confine a caller-supplied file path to the selected volume. A caller who can reach the route and identify an existing mounted volume can use path traversal to read files outside that volume when the artifact-serving process can read them. The frontend pod serves the request when artifact proxying is disabled, while the selected namespace's artifact-service pod serves it when proxying is enabled. A deployment with authentication disabled requires no application credentials; in multi-user deployments, the caller ordinarily must be authorized for the supplied namespace. This issue is fixed in version 2.18.0.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- kubeflow pipelines
fixed in 2.18.0
References 5
Questions about CVE-2026-118758
What does this mean?
Path traversal in the volume artifact route lets a caller read arbitrary files that the artifact-serving process can read. The caller must reach GET /artifacts/get?source=volume and identify an existing mounted volume.Source: github.com
Am I affected, and how do I check?
Kubeflow Pipelines 2.17.3 and earlier are affected. Readable files are limited to what the artifact-serving process (the frontend pod or the namespace artifact-service pod) can read, and in multi-user deployments the caller ordinarily must be authorized for the supplied namespace. To check, compare the installed Kubeflow Pipelines version against 2.17.3 and confirm whether the volume artifact route is reachable.Source: github.com
What should I do about it?
Upgrade every process serving volume artifacts, including namespace artifact receivers where used, to Kubeflow Pipelines 2.18.0.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data