CVE-2025-62879
Sensitive S3 Token Exposure in Rancher Backup Operator Logs
Publication date: 2026-03-04
Last updated on: 2026-03-05
Assigner: SUSE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| suse | rancher_backup_and_restore_operator | From 6.0.0 (inc) to 6.0.3 (exc) |
| suse | rancher_backup_and_restore_operator | From 7.0.0 (inc) to 7.0.5 (exc) |
| suse | rancher_backup_and_restore_operator | From 8.0.0 (inc) to 8.1.2 (exc) |
| suse | rancher_backup_and_restore_operator | From 9.0.0 (inc) to 9.0.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-532 | The product writes sensitive information to a log file. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability impact me? :
The vulnerability can lead to unauthorized access to your S3 storage credentials if an attacker gains access to the rancher-backup-operator pod logs.
Since the accessKey is exposed even at default logging levels, and the secretKey can be exposed if debug or trace logging is enabled, sensitive information can be compromised.
This exposure can result in confidentiality breaches, allowing attackers to misuse your S3 tokens for unauthorized operations.
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2025-62879 is a moderate severity vulnerability in the Rancher Backup Operator that causes sensitive S3 tokens, specifically the accessKey and secretKey, to be leaked into the operator's pod logs."}, {'type': 'paragraph', 'content': 'The accessKey is exposed in the logs at default logging levels (when trace and debug are false), while the secretKey is exposed only when trace or debug logging levels are enabled.'}, {'type': 'paragraph', 'content': 'This leakage allows unauthorized parties to access sensitive credentials, posing a confidentiality risk.'}] [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by inspecting the logs of the rancher-backup-operator pod for the presence of S3 tokens, specifically the accessKey and secretKey.'}, {'type': 'paragraph', 'content': 'The S3 accessKey is exposed in the pod logs at default logging levels (when trace and debug are false), while the secretKey is exposed only when trace or debug logging levels are enabled.'}, {'type': 'paragraph', 'content': 'To detect the vulnerability, you can search the logs for patterns matching S3 accessKey and secretKey values.'}, {'type': 'list_item', 'content': 'Use kubectl to access the logs of the rancher-backup-operator pod, for example: kubectl logs <rancher-backup-operator-pod-name>'}, {'type': 'list_item', 'content': "Search the logs for keywords like 'accessKey' or 'secretKey' using grep: kubectl logs <pod-name> | grep -i 'accessKey'"}, {'type': 'list_item', 'content': "If debug or trace logging is enabled, also search for 'secretKey': kubectl logs <pod-name> | grep -i 'secretKey'"}] [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include ensuring that both debug and trace logging levels are set to false (which is the default) to prevent leakage of S3 tokens in logs.
Upgrading to patched versions of the Rancher Backup Operator is strongly recommended. The patched versions are 9.0.1, 8.1.2, 7.0.5, and 6.0.3, which implement redaction of sensitive information in logs.
After upgrading, rotate the S3 accessKey and secretKey credentials, especially if logs containing these tokens have been exported or accessed.
If a full Rancher upgrade is not possible immediately, update the Rancher Backup chart alone as a temporary measure, except in air-gapped environments where Rancher must be updated first.
In air-gapped environments, sync new images to your image mirrors before upgrading.