CVE-2026-58273: 
Python vulnerability analysis and mitigation

CVE-2026-58273 is an authorization bypass vulnerability in the Rucio scientific data management system's /credentials/signurl REST API endpoint. The flaw allows any authenticated user holding a valid (even low-privilege) token to impersonate a privileged account (e.g., root) by supplying a forged X-Rucio-Account HTTP header, thereby obtaining presigned read/write/delete URLs for arbitrary cloud storage objects. Affected pip package versions are >= 1.16.1, < 35.9.0, >= 36.0.0rc1, < 38.6.0, and >= 39.0.0rc1, < 41.0.0rc1. The vulnerability was reported by seankohjs via static analysis and manual verification, published to the GitHub Advisory Database on October 28, 2026. It carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory).

The root cause is classified as CWE-639 (Authorization Bypass Through User-Controlled Key). In lib/rucio/web/rest/flaskapi/v1/credentials.py, the SignURL.get() method reads the authorization principal from the attacker-controlled X-Rucio-Account request header (request.headers.get('X-Rucio-Account', default=None)) rather than from request.environ['issuer'], which is set by the AuthenticatedBlueprint before-request hook after validating the token. The gateway function permission.has_permission() then uses this header value as the issuer, and the permission check perm_get_signed_url simply calls _is_root(issuer), which returns True whenever the supplied string equals 'root' — unconditionally granting access. Additionally, core.credential.get_signed_url does not validate that the requested URL's host/bucket belongs to the target RSE, creating an arbitrary-object signing oracle. In multi-VO deployments, the X-Rucio-VO header is similarly attacker-controlled, enabling cross-tenant targeting (GitHub Advisory, Patch Commit).

A low-privilege Rucio user can read, overwrite, and delete arbitrary objects on any cloud-backed RSE (S3, GCS, or Swift) using the server's stored credentials, since the presigned URLs are cryptographically signed with the RSE's own keys. This enables large-scale data exfiltration, tampering, and destruction of scientific datasets. In multi-VO deployments, the vulnerability extends to cross-tenant access, allowing an attacker in one virtual organization to target storage belonging to another. The confidentiality, integrity, and availability of all cloud-backed storage managed by the Rucio instance are fully compromised (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory (GHSA-5j9r-fx4x-rpvg), consisting of a concrete HTTP GET request with spoofed headers that any authenticated user can replay. The PoC demonstrates obtaining a presigned DELETE URL for an arbitrary S3 object with a single request. As of the advisory publication date, there is no evidence of in-the-wild exploitation or threat actor attribution. The vulnerability is not currently listed in the CISA KEV catalog. No EPSS score is available in the provided data (GitHub Advisory).

1. Obtain a valid Rucio auth token: Authenticate to the target Rucio instance using any legitimate low-privilege account to obtain a valid X-Rucio-Auth-Token.
2. Identify a target RSE and object: Enumerate available cloud-backed RSEs (S3/GCS/Swift) and identify a target object URL (e.g., https://victim-bucket.s3.amazonaws.com/important/dataset.root).
3. Craft the malicious request: Send a GET request to /credentials/signurl with the desired operation (read, write, or delete), the target RSE, and the spoofed X-Rucio-Account: root header:

GET /credentials/signurl?rse=<cloudRSE>&svc=s3&op=delete&url=https://victim-bucket.s3.amazonaws.com/important/dataset.root HTTP/1.1
X-Rucio-Auth-Token: <any_valid_token>
X-Rucio-Account: root
Accept: application/octet-stream

4. Receive presigned URL: The server returns a 200 OK response containing a presigned URL signed with the RSE's stored credentials.
5. Execute the operation: Replay the presigned URL directly against the cloud storage backend (e.g., via curl) to read, overwrite, or delete the target object — no further authentication required.
6. (Optional) Cross-tenant attack: In multi-VO deployments, additionally spoof the X-Rucio-VO header to target storage belonging to a different virtual organization (GitHub Advisory).

• Network: HTTP GET requests to /credentials/signurl with X-Rucio-Account: root (or other privileged account names) in the header from accounts that are not actually root/privileged; outbound presigned URL usage against S3/GCS/Swift endpoints from unexpected source IPs.
• Logs: Rucio access logs showing GET /credentials/signurl requests where the X-Rucio-Account header value does not match the authenticated token's account identity; repeated presigned URL generation requests across multiple RSEs or object paths from a single low-privilege account.
• Logs: Successful 200 OK responses to /credentials/signurl for delete or write operations from accounts that should not have root privileges.
• Cloud Storage: Unexpected deletions, modifications, or access to objects in S3/GCS/Swift buckets managed by Rucio RSEs, particularly if not correlated with legitimate Rucio transfer jobs; CloudTrail or equivalent audit logs showing presigned URL usage for sensitive datasets (GitHub Advisory).

Rucio has released patched versions 35.9.0, 38.6.0, and 41.0.0rc1 that fix the vulnerability by replacing the attacker-controlled header lookup with request.environ.get('issuer') and request.environ.get('vo'), which are set exclusively by the authenticated token validation middleware (GitHub Advisory, Patch Commit). Operators should upgrade immediately to one of the patched releases. As a short-term workaround where immediate patching is not possible, consider restricting network access to the /credentials/signurl endpoint to trusted IP ranges only, and enabling audit logging for all presigned URL generation requests to detect abuse. Review existing audit logs for suspicious X-Rucio-Account header usage inconsistent with authenticated token identities.

The vulnerability was reported by security researcher seankohjs via static analysis and manual verification, and was published to the GitHub Advisory Database on October 28, 2026 (GitHub Advisory). Coverage appeared on threat intelligence aggregators including VulDB and OSV.dev shortly after disclosure. No significant public social media debate or major vendor statements beyond the official advisory and patch commits have been identified.