Abstract: Before revision 221, the Charmed MySQL K8s operator, designed to manage MySQL deployments on Kubernetes, had a method that could leak database user credentials. Specifically, the operator relied on temporary script files with full URIs, which included user and password information, and these files were created with read permissions (x644). This meant that unprivileged users were capable of accessing the operator's runtime, potentially compromising sensitive information. This issue affects all versions prior to revision 221 for Kubernetes operators and revision 338 for machine operators.

Intro - Charmed MySQL K8s Operator

Charmed MySQL K8s operator is a Charmed Operator that enables the seamless deployment and management of MySQL on Kubernetes. The operator, designed to streamline the MySQL cluster lifecycle, does have a drawback: before revision 221, it could inadvertently reveal database user credentials.

The issue occurs when the Charmed MySQL K8s operator calls the mysql-operator to execute Python-based mysql-shell scripts or SQL DDL commands. In both cases, the method used to handle these commands creates a temporary script file that contains vital information, like the full URI, user, and password. Having this sensitive data stored in a readable temporary file creates a substantial risk for security breaches.

Exploit Details

The following code snippet demonstrates how the Charmed K8s MySQL operator calls the mysql-shell application:

myscript = tempfile.NamedTemporaryFile("w", delete=False)
myscript.write(f'{fulluri}\n')
myscript.write(...)
myscript.close()
shellcmd = f'mysqlsh --py {myscript.name}'

As you can see, this code generates a readable temporary file (x644) that contains the full URI, making crucial information vulnerable to unprivileged users.

Attackers can take advantage of this security gap and exploit the credentials, opening the door for unauthorized access to your MySQL databases. This vulnerability impacts the Kubernetes Charmed MySQL K8s operator on all versions prior to revision 221 and the machine Charmed MySQL operator on all versions prior to revision 338.

Original References

- Charmed MySQL K8s Operator: https://charmhub.io/mysql-k8s
- Kubernetes Charmed Operator: https://juju.is/docs/kubernetes
- Revision 221: [https://github.com/canonical/mysql-operator/commit/dd1ed14f9de9ca2c84fd6ac5c5e10faac44e16][1]
- Revision 338: [https://github.com/canonical/mysql-operator/commit/c5d517fec11a2be948950ad1789a723b400a511c][2]

Mitigation & Solution

To address the risk of a Charmed MySQL K8s operator credential leak, it is crucial to update your deployment to a patched version of the Charmed MySQL operator. For Kubernetes users, make sure to use revision 221 or later, while machine operator users should utilize revision 338 or a more recent release.

It is also highly recommended to periodically review and update your security practices, paying close attention to patching vulnerabilities and safeguarding sensitive information from unauthorized access.

By staying vigilant and keeping your systems up-to-date, you can better protect your MySQL deployment on Kubernetes, ensuring a more robust and secure environment.

[1]: https://github.com/canonical/mysql-operator/commit/dd1ed14f9de9ca2c84fd6ac5c5e10faac44e16
[2]: https://github.com/canonical/mysql-operator/commit/c5d517fec11a2be948950ad1789a723b400a511c

Timeline

Published on: 04/09/2025 23:15:37 UTC
Last modified on: 04/11/2025 15:40:10 UTC