CVE-2026-88981 in Pipelines
Summary
by MITRE • 11/06/2026
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the frontend artifact download path for source=s3 or source=minio accepts providerInfo.Params.endpoint, and the archived pod-log path accepts S3-compatible endpoint metadata from workflow status, without requiring those endpoints to match operator-controlled storage configuration. In the shipped authorization-disabled standalone configuration, an unauthenticated caller can make the shared ml-pipeline-ui pod connect to arbitrary reachable hosts and return response data; requests may also reveal an access-key identifier when signed with configured object-store credentials. Multi-user secret-backed metadata remains restricted to the server namespace. This issue is fixed in version 2.18.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
Kubeflow Pipelines serves as a critical infrastructure for orchestrating machine learning workflows, allowing data scientists and engineers to build portable and scalable ML processes. A significant security vulnerability was identified in versions prior to 2.18.0 regarding the handling of artifact storage configurations within the frontend component. The flaw stems from how the application processes endpoint information provided by users during workflow execution or when downloading artifacts. Specifically, the frontend artifact download mechanism for sources such as Amazon S3 and Minio accepts provider-specific parameters including the endpoint URL directly from user-supplied data. Similarly, the archived pod-log path functionality retrieves S3-compatible endpoint metadata from the workflow status without validating whether these endpoints align with operator-defined storage configurations or allowlists. This lack of strict validation creates a pathway for attackers to manipulate where the application directs its requests and how it handles sensitive operational data.
The technical nature of this vulnerability is classified as an Out-of-Band Interaction leading to potential Server-Side Request Forgery, which maps closely to CWE-918 in common weakness enumerations. In environments running the default standalone configuration with authorization disabled, any unauthenticated user can exploit this flaw by crafting specific requests that force the shared ml-pipeline-ui pod to connect to arbitrary reachable hosts controlled by an attacker. This behavior allows the application server to act as a proxy or relay for malicious traffic, potentially facilitating internal network reconnaissance, access to sensitive services within the cluster's network perimeter, or exfiltration of data through side channels. The vulnerability effectively bypasses intended isolation boundaries because the frontend component trusts user-provided endpoint metadata without sufficient verification against trusted storage backends defined by system administrators.
Beyond the risk of unauthorized outbound connections, this flaw presents a secondary information disclosure threat related to credential exposure. When requests are signed using configured object-store credentials, the interaction with arbitrary endpoints may inadvertently reveal access-key identifiers or other authentication artifacts in error messages, logs, or network traffic patterns observable by the attacker. This leakage can aid further attacks by confirming valid credentials or providing insights into the cloud provider's identity and configuration structure. Although multi-user deployments utilizing secret-backed metadata offer some protection by restricting access to the server namespace, standalone installations remain fully exposed to these risks due to their open authorization model. The operational impact is severe in unsecured environments as it compromises both confidentiality through credential leakage and integrity/availability via potential misuse of internal network resources for malicious purposes such as distributed denial-of-service attacks or probing internal services.
To mitigate this vulnerability, organizations must upgrade Kubeflow Pipelines to version 2.18.0 or later where the issue has been resolved by implementing stricter validation on endpoint parameters. For environments that cannot immediately patch due to dependency constraints, it is imperative to ensure that authorization mechanisms are enabled and properly configured to restrict access to untrusted users. Additionally, network-level controls such as egress filtering should be employed to limit which external hosts the ml-pipeline-ui pod can communicate with, thereby reducing the blast radius of any potential exploitation attempts. Security teams should also audit existing workflows for hardcoded or user-supplied endpoint configurations that deviate from approved storage providers and enforce policy-as-code approaches to prevent unauthorized modifications to workflow metadata. Regular vulnerability scanning and adherence to CIS benchmarks for Kubernetes workloads will further strengthen defenses against similar misconfiguration-based attacks.