CVE-2026-75092 in Red Hat
Summary
by MITRE • 09/15/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in the leapp-upgrade-el9toel10 package represents a critical privilege escalation flaw within the RHEL 9 to RHEL 10 upgrade process. This issue stems from the scan_mysql actor executing the mysqld binary with root privileges directly, thereby bypassing the standard systemd unit configuration that restricts MySQL daemon execution to the mysql user identity. By running as root without proper confinement or sandboxing mechanisms typically enforced by system services, the Leapp actor creates a high-value target for attackers who have already achieved code execution under the mysql OS account. This architectural deviation from secure defaults significantly expands the attack surface during the critical upgrade phase, allowing an attacker to leverage their existing foothold in the MySQL service context to escalate privileges to root level with full capabilities and unrestricted SELinux permissions.
The technical mechanism of this exploitation relies on a combination of file system write access within the mysql-owned directory /var/lib/mysql and specific configuration parsing behaviors in MySQL. An adversary possessing OS-level execution rights as the mysql user can craft a version-2 persisted configuration file, specifically mysqld-auto.cnf, which contains malicious directives such as plugin_dir set to /var/lib/mysql along with early_plugin_load or related loader options like plugin_load_add. When the Leapp actor subsequently invokes mysqld --validate-config, MySQL processes this persisted state before performing its standard runtime-user checks and plugin-symbol validations. Consequently, the database engine loads a shared object controlled by the attacker via dlopen() during the configuration validation phase. This sequence allows arbitrary code execution to occur while the process still holds root privileges, effectively bypassing security controls that would normally prevent such actions if executed under normal operational conditions or after user switching has occurred.
The operational impact of this vulnerability is severe, as successful exploitation results in full system compromise with UID 0 and a complete capability set within an unconfined SELinux domain known as unconfined_t. This level of access grants the attacker unrestricted control over the host operating system, enabling them to install backdoors, exfiltrate sensitive data, pivot to other networked systems, or modify critical system configurations without detection by standard security monitoring tools that rely on confined domains for integrity assurance. The attack chain requires two distinct conditions: first, OS-level execution as the mysql service identity, which implies a prior compromise of the database server itself; and second, the invocation of the Leapp preupgrade or upgrade workflow by an administrator. Notably, ordinary SQL privileges are insufficient to initiate this specific privilege escalation path because they do not grant access to write files in /var/lib/mysql at the OS level, highlighting that this is a multi-stage attack requiring both database compromise and administrative interaction with the system update tooling.
Mitigation strategies must address both the immediate configuration flaw and the broader security posture of the upgrade process. Administrators should ensure they are running patched versions of leapp-repository where the scan_mysql actor has been modified to avoid executing mysqld as root or to enforce stricter SELinux policies during validation steps. In environments where upgrading is not immediately feasible, restricting write access to /var/lib/mysql for the mysql user can hinder the initial stage of exploitation by preventing the creation of malicious persisted configuration files and shared objects. Additionally, enforcing mandatory access control policies that prevent MySQL processes from loading plugins from non-standard directories like /var/lib/mysql during validation phases would mitigate the core technical flaw. Organizations should also review their SELinux configurations to ensure that even if a process runs as root, it is confined within an appropriate domain rather than unconfined_t, thereby limiting the blast radius of any potential compromise. Regular auditing of systemd unit files for services like MySQL ensures they adhere to least-privilege principles and do not inadvertently expose privileged execution paths during administrative tasks such as system upgrades.
This vulnerability aligns with CWE-269 Improper Privilege Management due to the incorrect assignment of root privileges to a process that should operate under restricted permissions, and CWE-78 Improper Neutralization of Special Elements used in an OS Command if command injection vectors are considered alongside the plugin loading mechanism. From a tactical perspective, this scenario exemplifies ATT&CK technique T1068 Exploitation for Privilege Escalation, where attackers leverage specific software vulnerabilities to gain higher-level access on compromised hosts. It also relates to T1543.002 Create or Modify System Process: systemd Service Daemon in the context of bypassing service configurations, and potentially T1059 Command and Scripting Interpreter if shell commands are executed via loaded plugins. Understanding these mappings helps security teams prioritize remediation efforts based on established threat intelligence frameworks and industry best practices for securing database infrastructure during major operating system transitions.