CVE-2026-118759 in Pipelines
Summary
by MITRE • 10/29/2026
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the API server's GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log handler retrieved logs without authorizing the caller against the selected run. A caller who can reach the backend and knows a victim run ID and suitable pod or node identifier can read live or archived logs with the API server's permissions. For live logs, the caller-controlled node ID was also accepted as a pod name without verifying that the pod belonged to the requested run, allowing a known run ID to select the namespace of an unrelated pod and read its main container logs. The handler does not authenticate requests itself, although an external authentication gate or network policy can limit reachability. Exposed logs can contain sensitive workload data or credentials. This issue is fixed in version 2.18.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
Kubeflow Pipelines serves as a critical infrastructure component for orchestrating machine learning workflows, allowing users to define, execute, and manage complex data science processes at scale. The system relies on an API server that handles various requests related to pipeline runs, nodes, and associated metadata or logs. A significant security flaw was identified in the handling of log retrieval operations prior version 2.18.0. Specifically, the endpoint designated for retrieving logs via a GET request against the path /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log exhibited insufficient authorization controls. This vulnerability stems from a failure to validate whether the requesting user or service account possesses the necessary permissions associated with the specific run identified in the URL, creating an opportunity for unauthorized data access.
The technical core of this flaw lies in the API server's logic when processing log requests. When a caller provides a valid run ID and a node identifier, the system retrieves logs without verifying that the requester is authorized to view content related to that particular run. This lack of authorization check means that any entity capable of reaching the backend service can potentially access sensitive information if they possess knowledge of a victim's run ID. Furthermore, for live log streams, the handler accepts caller-controlled node IDs as pod names without performing verification to ensure that the specified pod actually belongs to the requested run context. This design oversight allows an attacker who knows a valid run ID to manipulate the request and select the namespace of an unrelated pod, thereby gaining access to its main container logs despite having no legitimate association with that workload.
The operational impact of this vulnerability is severe due to the nature of data processed within machine learning pipelines. Logs often contain sensitive workload details, including configuration parameters, intermediate results, and potentially hardcoded credentials or API keys used by the pipeline components. An attacker exploiting this flaw can exfiltrate these logs, leading to a breach of confidentiality for proprietary algorithms, training datasets, or infrastructure secrets. Since the handler does not perform authentication itself, relying instead on external mechanisms such as network policies or upstream authentication gates, the risk is amplified in environments where perimeter defenses are weak or misconfigured. Even if an attacker cannot directly authenticate against the API server, bypassing these controls through known run IDs and node identifiers allows them to read live or archived logs with the elevated permissions of the API server process itself.
To mitigate this vulnerability, organizations must upgrade Kubeflow Pipelines to version 2.18.0 or later, where the authorization logic has been corrected to properly validate caller permissions against the selected run before serving log data. In addition to upgrading, it is advisable to implement strict network policies that restrict access to the API server only from trusted sources and IP ranges. Utilizing an external authentication gate ensures that all requests are authenticated prior to reaching the application layer, adding a necessary defense-in-depth measure. Security teams should also audit their current deployments for exposure of this endpoint and monitor logs for unusual patterns of log retrieval activity involving known run IDs but unexpected node identifiers. This incident highlights the importance of enforcing granular access controls at every level of an API, ensuring that resource ownership is verified before any sensitive data is disclosed.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-732 Incorrect Permission Assignment for Critical Resource within the Common Weakness Enumeration framework. The exploitation technique corresponds to ATT&CK T1078 Valid Accounts or T1530 Data from Cloud Storage depending on whether credentials were stolen, but primarily represents an unauthorized data access scenario where lateral movement is not required if network reachability exists. By addressing these authorization gaps and adhering to the principle of least privilege during API design, organizations can prevent similar information disclosure issues in future versions or other components of their machine learning infrastructure.