CVE-2026-18620 in OpenShift AI
Summary
by MITRE • 08/10/2026
A flaw was found in Data Science Pipelines. A restricted user, or tenant, can exploit an improper authorization vulnerability in the setDefaultServiceAccount function. By specifying a more privileged ServiceAccount (SA) during a CreateRun request, an attacker can bypass authorization checks. This allows the tenant to run their containers with elevated privileges, potentially leading to the disclosure of sensitive information (secrets) and the ability to execute commands within other users' pods.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability resides within the Data Science Pipelines framework where improper authorization controls create a critical security gap in multi-tenant environments. The flaw specifically manifests in the setDefaultServiceAccount function which fails to properly validate tenant permissions when processing CreateRun requests. A malicious user operating within a restricted tenant context can manipulate the service account specification during pipeline execution, effectively bypassing intended authorization boundaries that should prevent cross-tenant privilege escalation.
The technical implementation of this vulnerability stems from insufficient access control validation mechanisms within the pipeline orchestration system. When a tenant submits a CreateRun request containing a ServiceAccount reference, the system does not adequately verify whether the requesting user possesses sufficient privileges to utilize the specified service account. This authorization bypass allows attackers to specify high-privilege service accounts that should only be accessible to administrators or privileged system components, thereby elevating their execution context within the containerized environment.
The operational impact of this vulnerability extends beyond simple privilege escalation to encompass potential data breaches and system compromise. Attackers can leverage elevated privileges to access secrets stored in the cluster, including API keys, database credentials, and other sensitive information that may be mounted within the containers. Additionally, the ability to execute commands within other users' pods creates a vector for lateral movement and persistent access within the multi-tenant environment. This represents a significant risk in shared compute environments where isolation between tenants is critical for maintaining security boundaries.
This vulnerability maps directly to CWE-285: Improper Authorization and aligns with ATT&CK techniques including T1078 Valid Accounts for privilege escalation and T1566 Phishing for credential access. The flaw represents a classic case of insufficient privilege validation where the system fails to enforce mandatory access controls that should prevent users from assuming roles beyond their designated permissions. Organizations implementing Data Science Pipelines should immediately implement strict service account validation mechanisms, enforce principle of least privilege for all pipeline operations, and consider implementing additional monitoring for anomalous service account usage patterns that could indicate exploitation attempts. The vulnerability highlights the critical importance of proper authorization controls in containerized environments where multiple tenants share common infrastructure resources.
The remediation approach must focus on strengthening authorization checks within the setDefaultServiceAccount function to ensure all service account references undergo rigorous validation against the requesting user's permissions. Implementing role-based access control policies that explicitly define which users can reference specific service accounts will prevent unauthorized privilege escalation. Additionally, organizations should consider implementing audit logging for all CreateRun operations involving service account specifications to detect potential exploitation attempts. The fix should also include validation of service account ownership and ensure that only authorized entities within the system can grant elevated privileges to tenant workloads, thereby maintaining proper isolation between multi-tenant compute environments.