CVE-2026-75092: Leapp RHEL Upgrade Flaw Lets a Compromised MySQL Account Escalate to Root

Overview

Red Hat has disclosed CVE-2026-75092, a privilege-escalation flaw in leapp-repository, the tooling behind the Leapp in-place upgrade framework used to move Red Hat Enterprise Linux systems from one major release to the next. The specific defect lives in the scan_mysql actor of the leapp-upgrade-el9toel10 package — the component that runs when an administrator upgrades a RHEL 9 host with MySQL installed to RHEL 10.

During that pre-upgrade check, the actor invokes mysqld --validate-config --log-error-verbosity=2 directly as root, inside the Leapp actor context — bypassing the packaged MySQL systemd unit, which normally starts the daemon as the unprivileged mysql user. That single design choice is the root cause of the whole issue: it hands a process that a lower-privileged identity can influence to full root.

The flaw was reported by Christopher Lusk of North Echo Security Research and is tracked in Red Hat Bugzilla as Bug 2517499, rated High severity, matching its CVSS 3.1 base score of 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H).

Technical Details

How the Escalation Works

The attack chain requires two things to line up: prior compromise of the mysql OS identity, and a later, entirely routine administrative action (running the documented RHEL 9-to-10 upgrade path).

1. Foothold as mysql. An attacker who has already compromised a process running as the mysql system user — for example through a separate MySQL/MariaDB vulnerability, a misconfigured plugin, or an exposed credential — can write to /var/lib/mysql, which that account owns.
2. Planting a malicious plugin. From that foothold, the attacker writes a version-2 persisted configuration file (mysqld-auto.cnf) plus a malicious shared object into /var/lib/mysql. The persisted config can set plugin_dir to point at /var/lib/mysql itself and enable early_plugin_load (or related options such as plugin_load / plugin_load_add), so MySQL loads the attacker-controlled object automatically.
3. The trigger. Ordinarily this alone wouldn't matter much — the mysqld systemd unit runs as mysql, and a plugin loaded that way would only ever execute with mysql's limited privileges. But when an administrator later runs the standard Leapp preupgrade or upgrade workflow to move the host to RHEL 10, the scan_mysql actor invokes mysqld --validate-config as root, and plugin loading reaches dlopen() before MySQL's runtime-user check and before plugin-symbol validation run.
4. Root execution. The attacker's shared object executes as UID 0, with a full Linux capability set, inside an unconfined SELinux domain (unconfined_t) — because the Leapp actor itself typically runs unconfined during the upgrade process.

Two details matter for anyone assessing exposure. First, the attacker does not need write access to the default system plugin directory under /usr — redirecting plugin_dir to mysql-owned, writable state under /var/lib/mysql is sufficient. Second, ordinary SQL-level privileges are not a viable starting point on their own, even a highly privileged database account — the attacker needs OS-level execution as the mysql service identity, and the escalation only fires once an administrator separately triggers the Leapp upgrade.

Impact Assessment

Who Is At Risk

This is not a remotely exploitable, pre-auth flaw — it's a local privilege-escalation chain that matters most to:

• RHEL 9 systems running MySQL that are staged, or planned, for an in-place upgrade to RHEL 10 via Leapp.
• Environments where the integrity of the mysql OS account cannot be fully assured — e.g., systems that have previously had a MySQL/MariaDB compromise, run untrusted plugins, or expose the database to less-trusted application tiers.
• Multi-tenant or shared hosting environments where a MySQL compromise is a more plausible starting foothold than a direct root compromise.

Systems that are not running MySQL, or that have no plans to run the RHEL 9→10 Leapp upgrade, are not exposed to this specific chain.

Why It's Rated High, Not Critical

The CVSS vector reflects real preconditions: the attack vector is local (AV:L), it requires low privileges to start (PR:L — the mysql account, not an unauthenticated remote position), and it requires user interaction (UI:R — an administrator has to run the upgrade). Those constraints keep it out of critical territory, but the impact once triggered is total: full confidentiality, integrity, and availability compromise of the host as root.

Mitigation

Immediate Actions

• Update leapp-repository / leapp-upgrade-el9toel10 to a fixed build before running any RHEL 9-to-10 upgrade. Red Hat and downstream rebuilders have shipped fixes (AlmaLinux, for example, released the fix in leapp-upgrade-el9toel10-0.24.0-1.el9_8.1 via ALSA-2026:67608); confirm the equivalent Red Hat advisory/errata for your subscription channel before upgrading.
• Audit /var/lib/mysql before upgrading on any host that will go through Leapp — look specifically for an unexpected mysqld-auto.cnf, unfamiliar shared objects, or a plugin_dir / early_plugin_load / plugin_load setting that doesn't match your baseline configuration.
• Do not run the RHEL 9→10 Leapp upgrade against a MySQL host whose integrity you can't currently attest to. Treat "has this box's mysql account ever been compromised?" as a pre-upgrade checklist item, not an afterthought.

Detection Opportunities

• Monitor for writes to /var/lib/mysql/mysqld-auto.cnf outside of expected SET PERSIST administrative activity.
• Alert on unexpected shared objects (.so files) appearing under MySQL data directories.
• Review Leapp preupgrade/upgrade logs for mysqld --validate-config invocations and correlate the timing against any recent, unexplained changes to MySQL's persisted configuration.

Defence-in-Depth

• Keep MySQL/MariaDB patched independently — this flaw is a privilege-escalation amplifier for an initial mysql-level compromise, not a standalone remote hole, so closing off the initial foothold closes off the chain entirely.
• Where feasible, run pre-upgrade validation in a more restrictive SELinux context rather than unconfined_t, and review whether Leapp actors can be constrained further in your environment.
• Snapshot or image database hosts before running major-version OS upgrades, both for rollback and forensic purposes.

References

• NVD — CVE-2026-75092
• Red Hat Bugzilla — Bug 2517499
• AlmaLinux — leapp-upgrade-el9toel10-0.24.0-1.el9_8.1 (ALSA-2026:67608)
• Red Hat Security Data API