Description

A privilege escalation flaw was found in the scan_mysql actor of leapp-upgrade-el9toel10 (provided by leapp-repository). During RHEL 9 to RHEL 10 upgrades, the actor runs: mysqld --validate-config --log-error-verbosity=2 directly as root in the Leapp actor context, bypassing the packaged MySQL systemd unit that normally starts the daemon as User=mysql. A process compromised as the mysql OS identity can write a version-2 persisted configuration (mysqld-auto.cnf) and a malicious shared object into /var/lib/mysql (a directory owned by mysql). That persisted map can set plugin_dir to /var/lib/mysql and early_plugin_load (or related loader options such as plugin_load / plugin_load_add) so MySQL loads the attacker-controlled object during configuration validation. Plugin loading can reach dlopen() before MySQL’s runtime-user check and before plugin-symbol validation. When an administrator subsequently runs the documented Leapp preupgrade or upgrade workflow, attacker-controlled code can execute as UID 0 with a full capability set in an unconfined SELinux domain (unconfined_t). The attack does not require write access to the default system plugin path under /usr; redirecting plugin_dir via mysql-owned persisted state is sufficient. Ordinary SQL privileges alone (including highly privileged SQL accounts) are not a sufficient startpoint — OS-level execution as the mysql service identity is required, plus later administrator invocation of Leapp.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-09-15T09:16:43.727Z",
  "pubdate": "2026-09-15T09:16:43.727Z",
  "executiveSummary": "A privilege escalation vulnerability exists in the scan_mysql actor within leapp-repository, specifically affecting the upgrade process from RHEL 9 to RHEL 10. The vulnerability arises because the scan_mysql actor executes the mysqld binary with root privileges outside of the standard systemd service environment.\nBy manipulating the mysqld-auto.cnf persisted configuration file, an attacker who has already compromised the mysql OS identity can force the mysqld process to load a malicious shared object during the configuration validation phase. When an administrator subsequently executes the Leapp upgrade workflow, the malicious code executes with root privileges and full capabilities within an unconfined_t SELinux domain.\nThis vulnerability represents a significant security risk, as it allows for arbitrary code execution as UID 0. Successful exploitation requires prior compromise of the mysql OS user and the subsequent execution of the Leapp upgrade tool by a system administrator. The vulnerability highlights a failure to adhere to the principle of least privilege when executing database configuration validation tasks during system migration.",
  "technicalDetails": "The root cause of this vulnerability is the improper execution of the mysqld binary by the scan_mysql actor within the leapp-upgrade-el9toel10 package. While standard database operations are handled by a systemd unit that drops privileges to the mysql OS user, the scan_mysql actor invokes mysqld directly as root with the command: 'mysqld --validate-config --log-error-verbosity=2'. This execution occurs without the restrictive environment typically enforced by the MySQL service unit.\nThe attack flow relies on the ability of the mysql OS user to control the contents of /var/lib/mysql, which includes the persisted configuration file 'mysqld-auto.cnf'. An attacker with mysql identity access can modify this file to manipulate specific MySQL configuration directives, namely 'plugin_dir', 'early_plugin_load', 'plugin_load', or 'plugin_load_add'. By setting 'plugin_dir' to /var/lib/mysql and pointing the load directives to a malicious shared object located within that directory, the attacker influences the binary's behavior.\nDuring the 'preupgrade' or 'upgrade' phase of the Leapp workflow, the scan_mysql actor triggers the validated 'mysqld' process. Because the process is running as root, the 'dlopen()' call within the MySQL plugin loading mechanism executes the attacker-controlled shared object before any runtime user-checks or plugin-symbol validations are performed. The malicious code is executed with the privileges of the invoking process, which in this context is UID 0.\nThe impact is complete system compromise. The attacker-supplied payload gains full root capabilities and operates within an unconfined_t SELinux domain, bypassing the typical security boundaries that would otherwise contain the MySQL service. This effectively allows an attacker to escalate from a service-level account (mysql) to full administrative control of the host operating system during the RHEL 9 to RHEL 10 transition."
}