Bug 2510320 (CVE-2026-18620)
| Summary: | CVE-2026-18620 data-sciences-pipeline: User-controlled ServiceAccount for workflow pods without authorization check — confused deputy | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | security-response-team |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Finding setDefaultServiceAccount honours, in priority order: (1) modelRun.ServiceAccount from the API request body, (2) the serviceAccountName already embedded in the uploaded Workflow, (3) the configured default. There is no SubjectAccessReview verifying the caller can use serviceaccounts/<name> or impersonate it. A tenant can set service_account in their CreateRun request to any SA in the namespace – including ds-pipeline-<dspa> (the API server's own SA, which can create workflows and delete pods) or pipeline-runner (which has secrets:get, pods/exec:*). This affects both V1 and V2 paths. Files: backend/src/apiserver/template/template.go:309-319 — setDefaultServiceAccount backend/src/apiserver/template/argo_template.go:60 backend/src/v2/template/v2_template.go:152-153,393 backend/src/common/util/workflow.go:163-165 Framework: OWASP K8s K02; ASVS V4.1.3 CWE: CWE-269 (Improper Privilege Management) / CWE-441 (Confused Deputy) CVSS v3.1: 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N) – High Exploitation POST /apis/v2beta1/runs with body {"experiment_id":"...","pipeline_version_reference":{...},"service_account":"ds-pipeline-<dspa>"} (the API server's own SA). The user container then has that token mounted. Impact A restricted tenant can run their container under a more-privileged SA simply by setting one field in the API call. Combined with the overprivileged pipeline-runner Role (secrets:get, pods/exec:*, kubeflow.org /), a tenant can read every Secret in the namespace and exec into co-tenant pods. The DSP namespace also contains the ml-pipeline (apiserver), mariadb/minio, and operator-managed SAs. Remediation Before setting serviceAccount, perform SAR {verb: "use", resource: "serviceaccounts", name: serviceAccount, namespace: ns} against the calling user. Or restrict to an allow-list configured by the operator (default pipeline-runner only).