Database/Control plane, storage & DevOps

Ceph RGW: unauthenticated STS token encryption lets any token holder bit-flip themselves to RGW admin

CVE-2026-39944Control plane, storage & DevOpscurated

Impact

RGW protects STS session tokens with AES-128-CBC and no message authentication, so a holder of any valid STS token can flip bits in the acct_type, perm_type and is_admin fields of their own token and have RGW accept the result. A forged is_admin triggers a global administrative override that bypasses all capability checks. On a GPU cluster where RGW is the S3 endpoint serving training data, checkpoints and model artifacts across tenants, one unprivileged tenant token becomes full administrative control of the object store: read, modify or delete every other tenant's buckets, including the model weights a serving fleet pulls at start-up. The attack is self-contained - no encryption oracle, no traffic observation, just the token the attacker already has.

Who can reach it

Anyone who can reach the RGW S3 endpoint and holds one valid STS session token, with STS enabled. The token needs no elevated privileges; no network position or passive capture is required.

What to do

Upgrade to Ceph 20.2.4 or 19.2.6 and restart the RGW daemons - a rolling restart behind the load balancer, no GPU node drain. If you cannot upgrade immediately, disabling STS removes the reachable path. Consider outstanding STS tokens untrustworthy and review RGW admin-level actions in the logs for the exposure window.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-39944 https://github.com/ceph/ceph/security/advisories/GHSA-j73r-qrgx-jvq2 https://github.com/ceph/ceph/releases/tag/v20.2.4 https://github.com/ceph/ceph/releases/tag/v19.2.6

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.