RHEL Leapp CVE-2026-75092: Patch the MySQL Upgrade Privilege-Escalation Path

By AiCybr Editorial · Published September 17, 2026

Red Hat has patched CVE-2026-75092, an Important privilege-escalation vulnerability in the Leapp upgrade path from RHEL 9 to RHEL 10. The flaw can turn prior OS-level execution as the mysql service identity into root code execution when an administrator later runs Leapp preupgrade or upgrade.

Red Hat assigns CVE-2026-75092 a CVSS 3.1 score of 7.3. Security advisories RHSA-2026:67608 and RHSA-2026:67609, issued September 15, 2026, provide updated leapp-repository packages. Red Hat's security data lists fixed package builds 0.22.0-1.el9_6.2 and 0.24.0-1.el9_8.1 for the applicable RHEL 9 streams.

The vulnerability is specifically relevant to systems that use Leapp to move from RHEL 9 to RHEL 10 and have MySQL installed. Exploitation requires prior OS-level code execution as the mysql user plus a later administrator-triggered Leapp workflow.

CVE-2026-75092 at a glance

How the privilege escalation works

Leapp's scan_mysql actor checks MySQL configuration as part of the RHEL 9-to-10 upgrade assessment. In the vulnerable path, it invokes:

mysqld --validate-config --log-error-verbosity=2

The command executes directly as root inside the Leapp actor context. A normal packaged MySQL service is started through systemd under User=mysql, so this validation path gives the process a different privilege context.

An attacker who already controls the OS-level mysql identity can write files in /var/lib/mysql. Red Hat describes an attack in which the adversary writes a version-2 persisted MySQL configuration (mysqld-auto.cnf) and a malicious shared object into that MySQL-owned directory.

The persisted configuration can redirect plugin_dir to /var/lib/mysql and configure an early plugin-loading option. When an administrator later runs the documented Leapp preupgrade or upgrade process, mysqld --validate-config can load the attacker-controlled shared object while running as root.

Red Hat states that plugin loading can reach dlopen() before MySQL's runtime-user check and plugin-symbol validation. Successful exploitation therefore executes attacker-controlled code as UID 0, with a full capability set in an unconfined SELinux domain (unconfined_t).

The prerequisite matters for exposure assessment

The initial foothold is OS-level execution as the mysql service user. SQL privileges by themselves, including a highly privileged database account, do not satisfy Red Hat's stated starting condition.

The second condition is administrator interaction: an administrator subsequently runs Leapp preupgrade or upgrade. The CVSS vector reflects these boundaries with a local attack vector, low privileges and required user interaction.

This makes CVE-2026-75092 especially relevant during incident response and major-version migration. A compromised MySQL service identity can leave persisted state that becomes substantially more dangerous when a privileged upgrade workflow consumes it later.

Which updates contain the fix

Red Hat's security data associates CVE-2026-75092 with two September 15 advisories and lists these updated leapp-repository builds:

Administrators should use the package supplied for their enabled and supported RHEL repository rather than comparing only the upstream Leapp version. Red Hat routinely backports security fixes, so the distribution package build and applicable RHSA are the authoritative remediation references.

The upstream leapp-repository project also contains the remediation change associated with Red Hat's CVE record, giving administrators and downstream maintainers a code-level reference for the fix.

What RHEL administrators should do

1. Identify RHEL 9 systems that will use Leapp for a RHEL 10 migration. Prioritize hosts that also run MySQL.
2. Apply the applicable Red Hat security advisory before running Leapp. Update leapp-repository through the supported RHEL repositories and confirm the installed package includes the CVE fix.
3. Treat prior mysql OS-user compromise as a high-risk condition before migration. A host where an attacker obtained execution as that service identity meets the critical prerequisite described by Red Hat.
4. Inspect MySQL persisted configuration and plugin-loading settings during incident response. Pay particular attention to unexpected changes involving mysqld-auto.cnf, plugin_dir, early_plugin_load, plugin_load, or plugin_load_add and unexpected shared objects in MySQL-writable paths.
5. Investigate suspicious files under /var/lib/mysql. The published attack path relies on the service identity's ability to place both persisted configuration and attacker-controlled code in a MySQL-owned location.
6. Use the applicable RHSA/package status to assess remediation. Version-only scanners can misclassify backported Red Hat packages; Red Hat recommends evaluating the actual distribution package and advisory state.

Mitigation and patching

Red Hat says an alternative mitigation is either unavailable or does not meet its Product Security criteria for ease of deployment, broad applicability or stability. The operational remediation is therefore to install the corrected leapp-repository package for the relevant supported RHEL stream before performing the RHEL 9-to-10 upgrade workflow.

For systems with evidence of prior compromise under the mysql identity, patching closes the vulnerable Leapp path but incident response should still determine what the attacker changed while that identity was under their control.

Exploitation status

Red Hat's public CVE record documents the attack path, severity and updates. The reviewed primary material does not report active exploitation in the wild. CVE-2026-75092 is therefore best treated as an upgrade-time local privilege-escalation risk with explicit prerequisites, not as evidence of a remote MySQL compromise path.

Bottom line

CVE-2026-75092 creates a privilege boundary failure at an unusually sensitive point: a major RHEL upgrade. An attacker with prior OS-level control of the mysql service account can prepare MySQL-owned state that Leapp's root-level validation later consumes.

RHEL administrators planning a 9-to-10 migration should update leapp-repository through the applicable September 15 security advisory before running Leapp and give additional scrutiny to MySQL hosts with any history or indication of service-account compromise.