CVE-2023-46741 is a medium severity (CVSS 4.8) flaw in CubeFS before 3.3.1 that leaks configuration keys, including a secret key, into logs in plain text. Anyone who can read the logs could act on blobs they should not touch. Upgrade to 3.3.1, then rotate keys and clean up logs.
What's affected
The record says CubeFS before 3.3.1 is affected, and the GitHub advisory GHSA-8h2x-gr2c-c275 says the same and names v3.3.1 as patched. The advisory says the Blobstore access service writes configuration keys, including a secret key, to its logs in plaintext when it starts.
Severity differs between sources. NVD scores it 4.8 Medium. The GitHub advisory scores it 6.5 Moderate with a vector that rates impact higher. We report both. The advisory says upgrading is the only mitigation. The weakness is CWE-200.
The NVD record scores it 4.8 (Medium) with the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L. The weakness class is CWE-200 (exposure of sensitive information). The record does not list this CVE in the CISA Known Exploited Vulnerabilities catalog, and nothing we read says it is exploited in the wild.
How to check if you're exposed
Check each CubeFS component version, and compare with 3.3.1. For Go module users:
go list -m all | grep cubefs
Then search your Blobstore access service logs and any log archive for the configuration keys. Also check who has read access to those logs, including central logging systems.
What to do now
- Upgrade CubeFS to 3.3.1 or later.
- Rotate the Blobstore secret keys that were written to logs, since they should be treated as exposed.
- Remove or redact old log files and archived copies that hold the keys.
- Limit who can read service logs, including centralised logging.
- Record versions and key rotation dates.
Why it matters
Keys in logs are a common leak. Logs are copied to central stores, shared with support and kept for months, so a secret written once spreads. The advisory notes the person reading the log could be an internal user with limited rights, or an outsider who has gained log access.
Patching stops new leaks. Keys that already reached logs stay valid until you rotate them, which is the step people forget.
Quick check
Why rotate keys after patching?
Keys already written to logs remain valid and may have been copied.
Do the sources agree on severity?
No. NVD says 4.8 Medium and the GitHub advisory says 6.5 Moderate.
Sources
Last reviewed: 19 October 2026.
