CVE-2026-18620: Data Science Pipelines Auth Bypass Flaw

CVE-2026-18620 Overview

CVE-2026-18620 is an improper authorization vulnerability [CWE-639] in Data Science Pipelines. The flaw resides in the setDefaultServiceAccount function, which fails to validate whether a tenant is permitted to use a specified ServiceAccount during a CreateRun request. A restricted tenant can specify a more privileged ServiceAccount and execute pipeline containers under that identity. Successful exploitation grants access to secrets and allows command execution inside other users' pods. The vulnerability affects Red Hat OpenShift AI deployments that ship Data Science Pipelines.

Critical Impact
An authenticated low-privileged tenant can escalate privileges within a shared Kubernetes cluster, disclose secrets across tenants, and execute arbitrary commands in other users' pods.

Affected Products

Red Hat OpenShift AI (Data Science Pipelines component)
Products covered by Red Hat Security Advisories RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263
Kubeflow Pipelines-based deployments incorporating the vulnerable setDefaultServiceAccount logic

Discovery Timeline

2026-08-10 - CVE-2026-18620 published to the National Vulnerability Database
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-18620

Vulnerability Analysis

Data Science Pipelines orchestrates machine learning workflows on Kubernetes, executing user-defined containers as pods under a designated ServiceAccount. Each pipeline run should execute using a ServiceAccount that the requesting tenant is authorized to assume. The setDefaultServiceAccount function assigns a ServiceAccount to a new run when the client submits a CreateRun API request. That function does not verify that the requesting user has permission to run workloads under the ServiceAccount supplied in the request body.

An authenticated tenant with permission to create runs can name any ServiceAccount that exists in the target namespace, including a ServiceAccount with elevated Kubernetes RoleBindings. The resulting pod inherits the tokens, secrets, and RBAC permissions bound to that identity. This crosses the tenant isolation boundary that shared OpenShift AI clusters rely on.

Root Cause

The root cause is a missing authorization check on a user-controlled object reference [CWE-639]. setDefaultServiceAccount treats the ServiceAccount name in the CreateRun payload as trusted input rather than validating it against the caller's identity and RBAC context. The function assumes the API layer has already enforced tenant-scoped ServiceAccount usage, which it has not.

Attack Vector

The attack requires network access to the pipelines API and valid tenant credentials permitted to submit runs. The attacker crafts a CreateRun request that references a privileged ServiceAccount, such as one bound to a cluster-admin or dspa-controller role. The pipelines service schedules pods using the specified ServiceAccount, and the attacker's container obtains its projected tokens and mounted secrets. From that pod, the attacker can call the Kubernetes API, read cross-tenant Secret objects, and use kubectl exec equivalents to run commands inside other tenants' pods.

No verified proof-of-concept code is publicly available. Refer to the Red Hat CVE Analysis for CVE-2026-18620 and Red Hat Bug Report #2510320 for further technical detail.

Detection Methods for CVE-2026-18620

Indicators of Compromise

CreateRun API requests where the service_account field references a ServiceAccount outside the caller's tenant namespace or bound to elevated roles.
Pipeline pods running with ServiceAccount tokens whose RBAC scope exceeds the submitting tenant's normal permissions.
Unexpected reads of cross-namespace Secret objects originating from pipeline-run pods.
Kubernetes audit events showing pods/exec or secrets/get calls sourced from pipeline workload identities.

Detection Strategies

Enable and monitor Kubernetes audit logs for CreateRun API calls and correlate the requested ServiceAccount against the caller's tenant.
Baseline the ServiceAccounts each tenant historically uses for pipeline runs and alert on deviations.
Inspect ML pipeline pod specifications at admission time and reject those referencing ServiceAccounts outside the tenant namespace.

Monitoring Recommendations

Forward OpenShift and Kubernetes audit events to a centralized data lake and retain CreateRun, pods/exec, and secrets/* verbs for analysis.
Alert on pipeline pods that mount tokens for ServiceAccounts bound to cluster-admin, edit, or controller-tier roles.
Track pod-to-Kubernetes-API traffic volumes per tenant to surface anomalous cross-tenant enumeration.

How to Mitigate CVE-2026-18620

Immediate Actions Required

Apply the fixed Data Science Pipelines packages delivered through RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263.
Audit existing pipeline runs and ServiceAccount bindings for signs of prior abuse before patching completes.
Rotate any tokens or Secrets that could have been exposed to untrusted tenants.

Patch Information

Red Hat has released fixed builds under Red Hat Security Advisories RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263. Consult the Red Hat CVE Analysis for CVE-2026-18620 for the affected package versions and mapped OpenShift AI releases. Apply updates through the OpenShift AI Operator so that the DataSciencePipelinesApplication (DSPA) controller receives the patched image.

Workarounds

Restrict pipeline CreateRun permissions to tenants that operate in isolated namespaces with no elevated ServiceAccounts present.
Remove or scope down privileged ServiceAccounts in namespaces shared with untrusted tenants.
Enforce an admission policy (OPA Gatekeeper or Kyverno) that rejects pipeline runs whose service_account field does not match an allow-listed identity for the requesting user.

bash

# Example Kyverno policy fragment restricting pipeline ServiceAccount selection
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-dsp-serviceaccount
spec:
  validationFailureAction: enforce
  rules:
    - name: allow-only-tenant-sa
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - "tenant-*"
      validate:
        message: "Pipeline pods must use the tenant-scoped ServiceAccount."
        pattern:
          spec:
            serviceAccountName: "pipeline-runner"