Ceph RGW (STS session tokens): Any tenant holding one ordinary STS session token can edit it into RGW superuser. RGW

Impact

Any tenant holding one ordinary STS session token can edit it into RGW superuser. RGW STS tokens ride the same unauthenticated AES-128-CBC handler as CephX, so the ciphertext carries no integrity protection. The attacker bit-flips the acct_type, perm_type and is_admin fields inside a token they already legitimately hold; a forged is_admin trips the global override in rgw_process_authenticated(), which short-circuits every check_caps() decision. The result is full RGW administrative access: read and write on every bucket belonging to every other tenant on the object store, plus the ability to mint and manage users. Unlike the CephX flaw this needs no encryption oracle and no packet capture — it is offline arithmetic on a token the attacker was legitimately issued, then a normal S3 request. For a neocloud selling shared object storage next to GPU capacity, this collapses the tenant boundary on the data plane customers stage their training corpora in.

Who can reach it

Network, reachable from the ordinary RGW S3 endpoint. Requires STS to be enabled on the cluster and one valid STS token of any privilege level. The token does not need to carry elevated rights and no network observation is needed.

What to do

Upgrade to Ceph 20.2.4 or 19.2.6 and restart radosgw. If STS is not used, disable it to remove the surface. After patching, invalidate outstanding STS sessions and review RGW admin-level operations in the logs for the exposure window, since forged tokens verify cleanly and leave no distinguishing trace.

References