Description

Rucio is a scientific data management framework. From 1.16.1 until 35.9.0, 38.6.0, and 41.0.0rc1, the /credentials/signurl endpoint reads X-Rucio-Account instead of the account stored in request.environ['issuer'] by token authentication. Any authenticated low-privilege user can supply root as the header value and pass the root-only get_signed_url permission check. The server then returns a presigned read, write, or delete URL for an attacker-selected object using stored S3, GCS, or Swift credentials, and X-Rucio-VO can select another tenant in multi-VO deployments. This permits data disclosure, modification, deletion, and cross-tenant access on cloud-backed RSEs. This issue is fixed in versions 35.9.0, 38.6.0, and 41.0.0rc1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-11-05T22:18:49.230Z",
  "pubdate": "2026-11-05T22:18:49.230Z",
  "executiveSummary": "Rucio is susceptible to an improper authorization vulnerability within the /credentials/signurl endpoint. This flaw arises from the application's reliance on a user-controllable HTTP header, 'X-Rucio-Account', to determine identity, rather than utilizing the verified 'issuer' attribute stored in 'request.environ' obtained through secure token authentication.\nThe vulnerability allows any authenticated low-privilege user to perform an account impersonation attack. By supplying a malicious value (e.g., 'root') in the 'X-Rucio-Account' header, an attacker can bypass authorization checks intended to restrict access to sensitive operations, such as generating presigned URLs for read, write, or delete actions on cloud-backed RSEs.\nIn multi-VO deployments, the 'X-Rucio-VO' header can be further manipulated to facilitate cross-tenant access. This effectively grants an attacker unauthorized control over storage resources, leading to potential data exposure, unauthorized modification, or data deletion across the scientific data management infrastructure. Given the ability to generate URLs using stored S3, GCS, or Swift credentials, the risk impact is critical, as it bypasses core logical access controls within the Rucio framework.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of identity validation within the /credentials/signurl endpoint. The Rucio framework incorrectly trusts the 'X-Rucio-Account' HTTP header for account identity verification. In a secure architecture, the application should derive the account context exclusively from the verified 'issuer' attribute located in 'request.environ', which is populated following successful token-based authentication.\nThe attack flow proceeds as follows: An authenticated low-privilege user initiates a request to the /credentials/signurl endpoint. Instead of the system evaluating the user's actual permissions based on their cryptographically verified token, the application logic parses the attacker-provided 'X-Rucio-Account' header. By setting this header to 'root', the attacker tricks the internal authorization check into believing the requester possesses administrative privileges.\nUpon successful bypass of the permission check, the server proceeds to generate a presigned URL. This URL provides the attacker with direct access to cloud storage resources (S3, GCS, or Swift) defined by the RSE configuration. Furthermore, the vulnerability extends to the 'X-Rucio-VO' header, which allows an attacker to specify a target tenant. In multi-VO environments, this enables cross-tenant unauthorized data access, effectively breaking the multi-tenancy isolation model.\nVulnerable versions include Rucio from 1.16.1 until 35.9.0, 38.6.0, and 41.0.0rc1. The flaw is fundamentally a failure to enforce the Principle of Least Privilege by trusting client-side input for security-critical authorization decisions. Once the presigned URL is acquired, the attacker no longer requires the Rucio application to interact with the underlying cloud storage, as the URL carries the necessary authorization to perform operations directly against the cloud service provider's APIs. This permits the attacker to bypass audit logging and access control mechanisms otherwise enforced by Rucio, leading to a high-severity impact on data integrity and confidentiality."
}