Description

Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.17.0, the API server trusts structural SQL identifier fields decoded from the base64-encoded JSON page_token parameter before constructing list queries. An attacker who can invoke an affected pipeline or run list API can inject through KeyFieldName or SortByFieldName, including v1beta1 and v2beta1 run-listing metric paths, and read data available to the API server database account across namespaces. Database modification is not established. This issue is fixed in version 2.17.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-11-05T22:18:54.587Z",
  "pubdate": "2026-11-05T22:18:54.587Z",
  "executiveSummary": "A critical SQL injection vulnerability exists in Kubeflow Pipelines prior to version 2.17.0, residing within the API server's handling of paginated list requests.\nThe vulnerability occurs because the API server fails to sanitize structural SQL identifier fields, specifically KeyFieldName and SortByFieldName, derived from base64-encoded JSON within the 'page_token' parameter.\nSuccessful exploitation allows an attacker with access to list API endpoints or pipeline execution functions to inject arbitrary SQL commands. This facilitates unauthorized data exfiltration from the underlying database using the API server's elevated service account privileges.\nThe impact includes cross-namespace data disclosure, as the database account typically maintains broad visibility. While the vulnerability does not inherently support arbitrary database modification, the ability to query unauthorized datasets poses a severe risk to data confidentiality.\nThe vulnerability affects both v1beta1 and v2beta1 run-listing metric paths. Remediation requires upgrading to Kubeflow Pipelines version 2.17.0 or later, where input validation and query construction logic have been hardened.",
  "technicalDetails": "The root cause of this vulnerability is improper neutralization of special elements used in SQL commands within the Kubeflow Pipelines API server. The system relies on a 'page_token' parameter, which is transmitted as a base64-encoded JSON object, to facilitate pagination of list queries.\nWhen processing this token, the API server decodes the JSON and blindly trusts the structural SQL identifier fields, namely 'KeyFieldName' and 'SortByFieldName', to construct dynamic SQL queries. These fields are concatenated directly into the database query structure without adequate parameterized queries or strict allow-listing.\nAn attacker can exploit this by crafting a malicious 'page_token' containing a base64-encoded JSON payload. Within this payload, the attacker modifies the 'KeyFieldName' or 'SortByFieldName' attributes to include SQL injection sequences. By providing a crafted identifier, the attacker influences the query logic, allowing them to manipulate the WHERE or ORDER BY clauses.\nThe attack flow proceeds as follows: 1) The attacker identifies a vulnerable endpoint such as a run-listing API (e.g., v1beta1 or v2beta1 paths). 2) The attacker constructs a malicious JSON object containing SQL injection strings in the sorting or filtering fields. 3) The attacker base64-encodes this object and transmits it as the 'page_token' parameter in an HTTP request. 4) The API server decodes the parameter and incorporates the malicious strings into the SQL query string before execution against the backend database. 5) The backend database executes the injected command, returning unauthorized results to the attacker's response.\nBecause the API server's database account often operates with extensive permissions, this vulnerability permits the attacker to bypass namespace isolation, potentially accessing sensitive metadata or configuration data across all namespaces managed by the Kubeflow deployment. The vulnerability persists across multiple API versions, including v1beta1 and v2beta1, as the internal data processing logic for pagination remained consistent and vulnerable prior to the patch. No authentication is explicitly required if the attacker has network-level access to the affected pipeline or list API endpoints, and there is no evidence of direct database modification (e.g., DELETE or UPDATE) based on current analysis; however, the unauthorized read access is sufficient to compromise the confidentiality of the entire ML workflow environment."
}