CVE-2026-73284

CVE-2026-73284 is being treated as a straightforward authorization bypass, but the severity is understated. The vulnerability isn't just that AddServiceAccount accepts a target_user parameter after insufficient validation — it's that the is_owner flag, when set during prepare_service_account_auth, transforms a CreateServiceAccountAdminAction holder into someone who can grant themselves ownership over arbitrary users' entire resource hierarchies. This is a resource takeover vector, not merely a privilege escalation within a single namespace. The critical architectural failure is the conflation of action-based authorization with semantic authorization. The code checks for CreateServiceAccountAdminAction — a coarse-grained gate — then accepts target_user as a free parameter that effectively delegates fine-grained scoping to runtime. This is the confused deputy problem in practice: the action says 'you can create service accounts,' while the parameter determines 'whose namespace,' and these orthogonal decisions are collapsed into a single check. The pattern has produced SSRF, path traversal, and IDOR vulnerabilities repeatedly across three decades of security history. Three factors push the real-world risk well above what EPSS (0.00283) predicts. First, RustFS is object storage — a trust anchor that other microservices depend on implicitly. A compromised service account with is_owner on a root-parent account doesn't just access one bucket; it can invalidate, redirect, or corrupt object paths that downstream services trust without re-verification. Second, CreateServiceAccountAdminAction is almost certainly delegated to CI pipelines, automation frameworks, and delegated operator accounts in production deployments. The EPSS model assumes a rare insider threat, but the actual attack surface includes credential-stuffing and supply-chain compromises against automation contexts that legitimately hold this action. Third, this is 1.0.0-beta.11 — pre-stable software running in production, where the assumption that 'beta users will update' never holds, and where the permission model likely evolved from legacy design artifacts never audited for cross-tenant implications. Verify whether is_owner on a root-parent service account grants cross-tenant or cross-namespace privileges in your deployment. If RustFS is in production despite beta versioning, treat the permission surface as broader than intended: audit which principals hold CreateServiceAccountAdminAction, restrict target_user parameters to caller's own scope, and assume any leaked automation credentials can perform cross-user resource creation.

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