CVE-2026-45040: RustFS: Sensitive Information Leakage (SessionToken and SecretAccessKey) in RustFS Logs [Debug Mode]
RustFS is a distributed object storage system built in Rust. Prior to 1.0.0-beta.2, RustFS suffers from sensitive information leakage in log outputs. When the server is run with RUST_LOG=debug sensitive credentials including SessionToken (JWT), SecretAccessKey, and full JWT claims are printed in plaintext to the server logs. This vulnerability is fixed in 1.0.0-beta.2.
Security readout for executives and security teams
Plain-English summary
RustFS versions before 1.0.0-beta.2 can write storage credentials into server logs when debug logging is enabled. Anyone with access to those logs could see session tokens, secret access keys, and JWT claims. This is mainly urgent where debug mode was used in production or logs are centralized or shared.
Executive priority
Treat this as a targeted credential-exposure cleanup, not an emergency internet-wide exploit. Prioritize production RustFS systems that used debug logging and rotate any credentials that may have reached logs.
Technical view
The issue is CWE-312/CWE-532 sensitive data exposure in log output. With RUST_LOG=debug, affected RustFS releases print SessionToken/JWT, SecretAccessKey, and full JWT claims in plaintext. The CVSS v4.0 score is 5.3. Practical impact depends on whether logs are accessible to unauthorized users or broad internal audiences.
Likely exposure
Likely exposed systems are RustFS deployments below 1.0.0-beta.2 that ran with RUST_LOG=debug. Risk increases if logs were forwarded to shared observability systems, retained broadly, or accessible by low-privileged users.
Exploitation context
The source bundle does not identify active exploitation, and KEV status is false. This is not a remote code execution issue; it is credential exposure through logs. Abuse would require access to logs containing the leaked secrets.
Researcher notes
Evidence is limited to the CVE record and GitHub advisory. The affected product is RustFS before 1.0.0-beta.2. The fix version is named, but no separate workaround beyond avoiding debug exposure is documented in the provided sources.
Mitigation direction
Upgrade RustFS to 1.0.0-beta.2 or later.
Disable debug logging in production unless explicitly needed.
Restrict access to RustFS server logs and centralized log stores.
Rotate credentials if affected debug logs may contain secrets.
Follow any additional RustFS vendor guidance.
Validation and detection
Inventory RustFS versions and flag any deployment below 1.0.0-beta.2.
Check whether RUST_LOG=debug was enabled on affected servers.
Review retained logs for SessionToken, SecretAccessKey, or JWT claim exposure.
Confirm log access is limited to authorized operational users.
After upgrading, verify debug logs no longer contain credentials.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-312: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.