Live › vulnerability › CVE-2026-118758
Kubeflow Pipelines before 2.18.0 does not confine file paths requested through the GET /artifacts/get volume handler. An attacker who can reach that route and name an existing mounted volume can read files outside that volume, as far as the artifact-serving process can read them.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 17:26 UTC. All times on this page are UTC.
Deployments running Kubeflow Pipelines before 2.18.0 are exposed if the GET /artifacts/get route is reachable by a caller and the artifact-serving process can read files outside the mounted volume. With authentication disabled no credentials are needed; in multi-user deployments the caller must be authorized for the supplied namespace. Teams using a managed service or a version at or above 2.18.0 can skip it.
No product ranges from the sources yet.
2.18.0.2.18.0 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-118758")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.