CVE-2025-24375
📋 TL;DR
The Charmed MySQL K8s operator versions before revision 221 (Kubernetes) and revision 338 (machine operators) create temporary files containing database credentials with overly permissive read permissions (0x644). This allows unprivileged users on the same system to read sensitive database credentials during operator runtime, potentially leading to unauthorized database access.
💻 Affected Systems
- Charmed MySQL K8s Operator
- Charmed MySQL Machine Operator
⚠️ Manual Verification Required
This CVE does not have specific version information in our database, so automatic vulnerability detection cannot determine if your system is affected.
Why? The CVE database entry doesn't specify which versions are vulnerable (no version ranges provided by the vendor/NVD).
🔒 Custom verification scripts are available for registered users. Sign up free to download automated test scripts.
- Review the CVE details at NVD
- Check vendor security advisories for your specific version
- Test if the vulnerability is exploitable in your environment
- Consider updating to the latest version as a precaution
⚠️ Risk & Real-World Impact
Worst Case
Attackers gain database administrator credentials, leading to complete database compromise, data theft, data manipulation, or service disruption.
Likely Case
Malicious users or compromised containers within the Kubernetes cluster read temporary credential files to gain unauthorized database access at the privilege level of leaked credentials.
If Mitigated
With proper network segmentation and least privilege access controls, impact is limited to the specific Kubernetes namespace or node where the operator runs.
🎯 Exploit Status
Exploitation requires local access to the Kubernetes node or container where the operator runs and ability to read temporary files during credential exposure windows.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Revision 221 for Kubernetes operators, Revision 338 for machine operators
Vendor Advisory: https://github.com/canonical/mysql-k8s-operator/security/advisories/GHSA-g83v-7694-2hf7
Restart Required: Yes
Instructions:
1. Update to revision 221+ for Kubernetes operators or revision 338+ for machine operators. 2. Apply the operator update via your Kubernetes management tool (kubectl, Helm, etc.). 3. Restart the MySQL operator pods to ensure the fix is active.
🔧 Temporary Workarounds
Restrict file permissions on operator containers
linuxApply stricter file permission controls to prevent unauthorized users from reading temporary files
chmod 600 /tmp/mysql-operator-*
umask 077
🧯 If You Can't Patch
- Implement strict network segmentation to isolate MySQL operator containers from other workloads
- Apply Kubernetes Pod Security Standards to restrict container capabilities and filesystem access
🔍 How to Verify
Check if Vulnerable:
Check operator version: kubectl describe pod <mysql-operator-pod> | grep Image. If version is before revision 221 (K8s) or 338 (machine), you are vulnerable.Check Version:
kubectl describe pod <mysql-operator-pod> | grep ImageVerify Fix Applied:
Verify operator is running revision 221+ (K8s) or 338+ (machine) and check that temporary files created by mysql-shell have restrictive permissions (0x600).📡 Detection & Monitoring
Log Indicators:
- Failed authentication attempts using database credentials
- Unexpected database connections from Kubernetes nodes
Network Indicators:
- Database connections from unexpected IPs within the Kubernetes cluster
SIEM Query:
source="kubernetes" AND ("mysql-operator" OR "mysql-shell") AND ("temporary file" OR "permission 644")🔗 References
- https://github.com/canonical/mysql-k8s-operator/commit/7c6b1206fcbc7324b72f413c5e63216e742a71a1
- https://github.com/canonical/mysql-k8s-operator/pull/553
- https://github.com/canonical/mysql-k8s-operator/security/advisories/GHSA-g83v-7694-2hf7
- https://github.com/canonical/mysql-operator/commit/1fb61c1ee3e396cdce13d5e8155f2f32a860f89e
- https://github.com/canonical/mysql-operator/pull/579
