CVE-2026-18620

CVE-2026-18620 is a cross-tenant authorization failure in a data science pipeline platform, and understanding what it actually represents matters more than the CVSS 7.1 score suggests. The vulnerability lives in a function called `setDefaultServiceAccount` that accepts a user-supplied service account identifier as an authoritative directive — treating it as a value to be set rather than an identity to be verified against the requesting tenant's allowlist. In plain terms: an authenticated tenant can specify which service account the platform should bind to their workload, and the platform doesn't validate whether that service account belongs to their tenant. This lets an attacker execute commands inside pods belonging to other tenants, exposing the tokens and secrets those service accounts carry. The critical distinction is between a missing authorization check and a design-level assumption that should never have existed. The function naming itself is revealing — a 'default' service account should be a system-enforced fallback applied when no explicit choice is made, not a tenant-controllable parameter. The presence of this flaw suggests the code predates the platform's multi-tenancy requirements, or was retrofitted without re-scoping all entry points to enforce tenant isolation at the identity level. Defenders should audit their environment by examining API access logs for CreateRun or equivalent workload creation endpoints where the serviceAccount field differs from the expected tenant-scoped default. If your logs show cross-tenant service account binding, you're already compromised. The more important question is whether other API functions in this platform accept service account or workload identity parameters without tenant-scoped authorization — if this pattern is systemic, patching one code path creates false confidence while the underlying design assumption persists. The fix will reveal whether this is treated as an implementation error or a design error. A proper fix introduces tenant-scoped service account allowlisting — the platform derives which service accounts are valid for a given tenant from that tenant's namespace or project bindings, rather than accepting any identifier the caller provides. A narrow fix adds a one-line authorization gate to CreateRun while leaving the underlying assumption (service account as settable parameter) intact elsewhere in the API. If the latter, treat this CVE as a marker indicating more cross-tenant vulnerabilities in adjacent functions will surface. Assume a 6-12 month window before the next one in this lineage is discovered.

Reviewed through automated stages and approved by a human before publication.