This CVE exposes a subtle but significant IAM permission mapping failure in RustFS: when a client explicitly requests a specific object version via the versionId parameter, the system authorizes the request using s3:GetObject rather than s3:GetObjectVersion. This is a semantic mismatch—the operation is reading a known historical object snapshot, not the current version, yet the authorization decision treats it as a standard object read. The vulnerability affects not only GetObject but also CopyObject and UploadPartCopy operations when source objects include a versionId, meaning the same flawed logic likely exists across multiple code paths that share a templated permission check.
The CVSS 6.5 and low EPSS (0.00304) are misleading metrics for this class of issue. The CVE description notes the attacker needs a 'known historical object version'—but versionIds leak aggressively through CloudTrail logs, S3 inventory exports, error messages, backup metadata, and CI/CD pipeline artifacts. Any principal with ListBucket access or read access to logging infrastructure can harvest versionIds at scale. The 'known' qualifier is practically a non-constraint in mature deployments.
The real blast radius extends beyond reading historical files. A versioned object might contain credentials, API keys, or configuration data that was subsequently deleted or rotated but remains accessible through the versioned snapshot. This means successful exploitation could yield credential recovery, sensitive data resurrection, or access to decommissioned configurations that still have privileges. What you store in versioned objects determines actual impact, not the vulnerability's technical severity.
The beta status (1.0.0-beta.11) compounds the exposure in ways CVSS doesn't capture. Pre-1.0 software typically operates under implicit operational contracts where documented behavior IS the contract. If operators built Terraform modules, runbooks, or CI configurations around the assumption that s3:GetObject authorizes all version reads, that documentation gets inherited as tribal knowledge even after the code is fixed. The patch resolves the code but not the knowledge debt—operators who granted overly broad s3:GetObject permissions as a work-around may now face silent authorization failures instead of silent access.
Audit your IAM policies: any principal granted s3:GetObject for objects in versioned buckets may now have unintended access to historical versions they shouldn't see. Review Terraform, CloudFormation, and policy documents that codified the incorrect permission model during beta operation. This bug class has a documented recurrence pattern across S3-compatible systems—not because developers are negligent, but because the abstraction pressure of implementing multiple version-aware operations pushes teams toward templated permission checks that collapse the semantic distinction between current-version and historical-version access. Audit all code paths accepting versionId parameters against the formal S3 IAM permission model rather than assuming this was an isolated fix.