GPU VulnDB

Database/Kernel, userspace & hypervisor

Leapp RHEL 9 to 10 upgrade: scan_mysql runs mysqld as root, letting mysql-owned state load code as UID 0

CVSS 7.3CVE-2026-75092Kernel, userspace & hypervisorcurated

Impact

The scan_mysql actor runs mysqld --validate-config directly as root instead of through the packaged systemd unit that drops to User=mysql. A process already holding the mysql OS identity can drop a malicious shared object plus a version-2 mysqld-auto.cnf into /var/lib/mysql, which it owns, and point plugin_dir and early_plugin_load at them; plugin loading reaches dlopen() before MySQL's runtime-user check. The next time an administrator runs the documented Leapp preupgrade or upgrade workflow, that object executes as UID 0 with a full capability set in unconfined_t. For a fleet this matters where a MySQL instance sits beside the GPU workload on a node or on a management host that is due for a RHEL 9 to 10 upgrade: a service-account compromise becomes host root at the moment of the upgrade, and SQL privileges alone are not enough - OS-level execution as mysql is required.

Who can reach it

Local attacker who already has code execution as the mysql service identity on a host running the RHEL 9 to 10 Leapp upgrade, plus a later administrator invocation of the Leapp preupgrade or upgrade workflow. Highly privileged SQL accounts alone do not suffice.

What to do

Apply the Red Hat errata for leapp-repository (RHSA-2026:67608 / 67609) on any host before running a RHEL 9 to 10 upgrade; it is a package update to the upgrade tooling, so no reboot beyond the one the upgrade itself performs. If an upgrade is imminent and the host runs MySQL, inspect /var/lib/mysql for an unexpected mysqld-auto.cnf or shared objects before starting.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.