Summary
Kubeflow Pipelines contains a path traversal vulnerability in its volume artifact handler, allowing an authorized caller to read files outside a selected mounted volume. The issue becomes risky when the artifact-serving process can access those files and a caller can reach the artifact route with a valid or discoverable volume reference.
Kubeflow Pipelines contains a path traversal vulnerability in its volume artifact handler, allowing an authorized caller to read files outside a selected mounted volume. The issue becomes risky when the artifact-serving process can access those files and a caller can reach the artifact route with a valid or discoverable volume reference.
Affected context
The vulnerability affects Kubeflow Pipelines deployments before 2.18.0 when the volume artifact endpoint accepts a caller-controlled file path without constraining it to the selected volume. Requests may be served by the frontend pod when artifact proxying is disabled or by the selected namespace's artifact-service pod when proxying is enabled. Exposure depends on endpoint reachability, authentication configuration, namespace authorization, and the files readable by the serving process.
The vulnerability affects Kubeflow Pipelines deployments before 2.18.0 when the volume artifact endpoint accepts a caller-controlled file path without constraining it to the selected volume. Requests may be served by the frontend pod when artifact proxying is disabled or by the selected namespace's artifact-service pod when proxying is enabled. Exposure depends on endpoint reachability, authentication configuration, namespace authorization, and the files readable by the serving process.
Exploit preconditions
- Attack surface: The volume artifact retrieval route - Required access: Network access to the route and, in multi-user
deployments, authorization for the supplied namespace; deployments with
authentication disabled may not require application credentials
- Required knowledge: An existing mounted volume must be identifiable - Trigger point: Processing a file path supplied to the volume artifact
handler
- Why exploitation is possible: The supplied path is not sufficiently
confined to the selected volume before file access occurs
- Attack surface: The volume artifact retrieval route - Required access: Network access to the route and, in multi-user
deployments, authorization for the supplied namespace; deployments with
authentication disabled may not require application credentials
- Required knowledge: An existing mounted volume must be identifiable - Trigger point: Processing a file path supplied to the volume artifact
handler
- Why exploitation is possible: The supplied path is not sufficiently
confined to the selected volume before file access occurs
Why this happens
The underlying bug is failure to enforce a canonical path boundary when resolving a caller-supplied file path against a selected volume. Without validating that the resolved path remains within the intended directory, traversal elements or equivalent path representations can redirect file access elsewhere in the process-visible filesystem. This behavior maps to CWE-22, Improper Limitation of a Pathname to a Restricted Directory.
The underlying bug is failure to enforce a canonical path boundary when resolving a caller-supplied file path against a selected volume. Without validating that the resolved path remains within the intended directory, traversal elements or equivalent path representations can redirect file access elsewhere in the process-visible filesystem. This behavior maps to CWE-22, Improper Limitation of a Pathname to a Restricted Directory.
Potential impact
- An attacker may read sensitive application or system files
- Credentials, tokens, configuration data, or model-related artifacts could be exposed
- The confidentiality of other workloads or namespaces may be reduced
- Disclosed secrets could enable follow-on access or privilege escalation
- An attacker may read sensitive application or system files
- Credentials, tokens, configuration data, or model-related artifacts could be exposed
- The confidentiality of other workloads or namespaces may be reduced
- Disclosed secrets could enable follow-on access or privilege escalation
General mitigation guidance
Mitigation generally focuses on enforcing a strict filesystem boundary for every artifact request. Secure-by-default designs should resolve paths canonically, verify that the result remains beneath the selected volume root, reject ambiguous or malformed path representations, and avoid deriving access decisions from untrusted path strings alone. Artifact-serving processes should use dedicated read-only directories, minimize mounted content, reduce input trust through namespace and artifact authorization, and run with only the filesystem and platform privileges required for serving artifacts.
Mitigation generally focuses on enforcing a strict filesystem boundary for every artifact request. Secure-by-default designs should resolve paths canonically, verify that the result remains beneath the selected volume root, reject ambiguous or malformed path representations, and avoid deriving access decisions from untrusted path strings alone. Artifact-serving processes should use dedicated read-only directories, minimize mounted content, reduce input trust through namespace and artifact authorization, and run with only the filesystem and platform privileges required for serving artifacts.
How teams detect issues like this
Detection approaches include static analysis for file operations that combine user-controlled paths with volume or directory roots without canonicalization and boundary checks. Code review should examine path normalization, symlink handling, authorization-to-filesystem mapping, and behavior when proxying is enabled or disabled. Runtime monitoring can flag unusual artifact requests, access to paths outside expected artifact roots, and reads of sensitive filesystem locations. Policy enforcement may require approved path-handling utilities and security tests for directory-boundary violations; automated code-review tools can help identify related patterns.
Detection approaches include static analysis for file operations that combine user-controlled paths with volume or directory roots without canonicalization and boundary checks. Code review should examine path normalization, symlink handling, authorization-to-filesystem mapping, and behavior when proxying is enabled or disabled. Runtime monitoring can flag unusual artifact requests, access to paths outside expected artifact roots, and reads of sensitive filesystem locations. Policy enforcement may require approved path-handling utilities and security tests for directory-boundary violations; automated code-review tools can help identify related patterns.
