Rucio CVE-2026-58273

Requires the attacker to hold any valid Rucio auth token for an account they legitimately own (PR:L - authenticated), plus a target RSE that is cloud-backed with server-stored S3/GCS/Swift credentials; the exploit is the single header X-Rucio-Account: root sent to /credentials/signurl, with no user interaction. In multi-VO deployments the X-Rucio-VO header additionally enables cross-tenant targeting. Limiting factors: a valid token is mandatory (not fully anonymous), the RSE must be configured with cloud storage credentials, and the deployment must run a vulnerable version (>=1.16.1 and <35.9.0, >=36.0.0rc1 and <38.6.0, or >=39.0.0rc1 and <41.0.0rc1). Fixed releases derive the account from the token-authenticated request.environ issuer instead of the header; updating to 35.9.0, 38.6.0, or 41.0.0rc1 is the vendor remedy.

This is a genuine high-priority issue, not a CVSS-inflated one. The vendor CVSS3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8) is well-supported by the described mechanism: the /credentials/signurl endpoint reads the authorization principal from the attacker-controlled X-Rucio-Account header rather than the token-authenticated identity, so any holder of a valid low-privilege token can assert 'root' and pass the root-only permission check. PR:L is correct because a valid token is required; AC:L is correct because the trigger is a single crafted GET with a spoofed header and needs no special timing or grooming. C:H/I:H/A:H reflect read/write/delete of arbitrary objects via the RSE's stored S3/GCS/Swift credentials. The decision label is 'this_week' and a patch is available across three release branches. No CISA KEV entry and no EPSS score are present in the input, so there is no signal of active or widespread exploitation - exploitation status is therefore driven by the advisory's own proof-of-concept rather than observed attacks. The one metric worth scrutiny is scope: the signed URL acts on cloud storage governed by credentials outside the Rucio server's own authority, which could arguably justify S:C; the vendor kept S:U and this assessment follows that, but defenders should note the real-world blast radius reaches the storage backend itself.

An attacker who legitimately owns any low-privilege Rucio account obtains a normal auth token, then sends a single GET to /credentials/signurl for a cloud-backed RSE while setting the header X-Rucio-Account: root. The server mints a presigned S3/GCS/Swift read, write, or delete URL for an arbitrary bucket/object and returns it, which the attacker replays directly against the storage backend to exfiltrate, overwrite, or destroy data. The advisory includes a concrete PoC request demonstrating a presigned DELETE URL, and the attack is low-complexity and unauthenticated-looking at the application layer beyond needing any valid token.