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.
{
"cna_assigner": "redhat",
"cwe_ids": [
"CWE-250"
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/75xxx/CVE-2026-75092.json",
"unresolved_ranges": [
{
"extracted_events": [
{
"range": [
{
"fixed": "0:0.24.0-1.el9_8.1"
},
{
"fixed": "0:0.22.0-1.el9_6.2"
}
],
"source": "AFFECTED_FIELD",
"strategy": "InverseAffectedRanges"
}
]
}
]
}{
"extracted_events": [
{
"range": [
{
"fixed": "3e4cafffc8de1600a66519b326a407f37b665356"
}
],
"source": "REFERENCES_COMMIT"
}
]
}