CVE-2025-54064 in helm-charts
Summary
by MITRE • 07/17/2025
Rucio is a software framework that provides functionality to organize, manage, and access large volumes of scientific data using customizable policies. The common Rucio helm-charts for the `rucio-server`, `rucio-ui`, and `rucio-webui` define the log format for the apache access log of these components. The `X-Rucio-Auth-Token`, which is part of each request header sent to Rucio, is part of this log format. Thus, each access log line potentially exposes the credentials (Internal Rucio token, or JWT in case of OIDC authentication) of the user. Due to the length of the token (Especially for a JWT) the tokens are often truncated, and thus not usable as credential; nevertheless, the (partial) credential should not be part of the logfile. The impact of this issue is amplified if the access logs are made available to a larger group of people than the instance administrators themselves. An updated release has been supplied for the `rucio-server`, `rucio-ui` and `rucio-webui` helm-chart. The change was also retrofitted for the currently supported Rucio LTS releases. The patched versions are rucio-server 37.0.2, 35.0.1, and 32.0.1; rucio-ui 37.0.4, 35.0.1, and 32.0.2; and rucio-webui 37.0.2, 35.1.1, and 32.0.1. As a workaround, one may update the `logFormat` variable and remove the `X-Rucio-Auth-Token`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/17/2025
The vulnerability described in CVE-2025-54064 affects the Rucio software framework, a critical component in scientific data management systems that handles large-scale data organization and access through customizable policies. This framework consists of multiple helm-chart components including rucio-server, rucio-ui, and rucio-webui, each of which generates apache access logs for monitoring and operational purposes. The core technical flaw lies in the default log configuration where the X-Rucio-Auth-Token header, containing either internal Rucio tokens or JWT tokens used for OIDC authentication, is included in the access log format. This represents a significant security oversight as authentication tokens are inherently sensitive credentials that should never be exposed in log files under any circumstances.
The operational impact of this vulnerability extends beyond simple credential exposure, as the inclusion of authentication tokens in access logs creates potential attack vectors for unauthorized parties who might gain access to these log files. Even though the tokens are often truncated in the logs due to their length, particularly JWT tokens, this truncation does not eliminate the security risk since partial tokens can still be exploited by attackers to compromise user sessions or escalate privileges. The vulnerability is particularly concerning when access logs are shared with groups beyond just instance administrators, as this broadens the potential attack surface significantly. This issue directly violates security best practices and standards such as those outlined in CWE-532, which addresses information exposure through log files, and aligns with ATT&CK technique T1562.006 for credential access through log file collection.
The affected versions include multiple releases of the Rucio framework, with patched versions available for rucio-server 37.0.2, 35.0.1, and 32.0.1; rucio-ui 37.0.4, 35.0.1, and 32.0.2; and rucio-webui 37.0.2, 35.1.1, and 32.0.1. These patches represent a direct fix to the log configuration that removes the X-Rucio-Auth-Token from the apache access log format, thereby preventing credential exposure. Organizations using Rucio should immediately update to these patched versions to mitigate the risk. As a temporary workaround, administrators can manually modify the logFormat variable in the helm charts to exclude the X-Rucio-Auth-Token header from log entries, though this requires careful configuration management and validation to ensure proper logging continues while eliminating the credential exposure risk. The vulnerability demonstrates the critical importance of proper log sanitization and access control in distributed systems handling sensitive authentication data.