CVE-2026-107822: MariaDB Privilege Escalation Vulnerability

CVE-2026-107822 Overview

CVE-2026-107822 is a privilege confusion vulnerability in MariaDB server, a community-developed fork of MySQL. The flaw resides in the Access Control List (ACL) cache, where database-privilege cache keys collide between role names and localhost user names that share identifiers. Both principals produced an empty IP component, allowing the cache lookup to return the wrong privilege set. An attacker holding the CREATE USER privilege can register a colliding principal and, once the original principal's privileges are cached, execute operations under the other account's authority. The issue is tracked under [CWE-706: Use of Incorrectly-Resolved Name or Reference] and documented in MariaDB Security Advisory GHSA-2m85-2x26-36rf.

Critical Impact
An authenticated attacker with CREATE USER can impersonate the privileges of a colliding role or user@localhost account, enabling horizontal or vertical privilege escalation inside the database.

Affected Products

MariaDB server versions from 10.6.1 up to (but not including) 10.6.28
MariaDB server 10.11.x prior to 10.11.19, 11.4.x prior to 11.4.13, and 11.8.x prior to 11.8.9
MariaDB server 12.3.x prior to 12.3.3, and 13.0.x prior to 13.0.2

Discovery Timeline

2026-10-09 - CVE-2026-107822 published to NVD
2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-107822

Vulnerability Analysis

MariaDB caches per-database privilege lookups in an in-memory ACL cache keyed by the concatenation of client IP, user name, and database name. Roles do not have an associated IP or host, so the IP component is empty. User accounts defined as user@localhost can also resolve to an empty IP component when the host portion is not folded into the key. When a role and a localhost user share the same name, both principals compute the identical cache key.

The collision becomes exploitable once the original principal's privileges are warmed into the cache. A subsequent authorization check for the colliding principal returns the cached entry belonging to the other account, so the server grants or denies database privileges based on the wrong identity. The resulting confusion crosses the trust boundary between roles and real login accounts.

Root Cause

The root cause is unsafe key construction in acl_get() within sql/sql_acl.cc. The function built the cache key using only the IP string, treating a missing IP as an empty string without substituting an alternate discriminator. As a result, roles (which have no IP) and user@localhost entries (where IP was null) produced indistinguishable keys. The MariaDB fix in commit 67ea07dd falls back to the host string when IP is absent, guaranteeing key uniqueness between the two principal classes. Full engineering context is tracked in MariaDB JIRA Issue MDEV-40541.

Attack Vector

Exploitation requires an authenticated session with CREATE USER privilege. The attacker creates a role or user@localhost whose name collides with an existing principal, waits for or triggers caching of the victim's privileges, and then issues SQL that relies on the resolved privilege set. The attack vector is network-reachable but requires high privileges, user interaction, and the right ordering of cache state, which is reflected in the medium severity rating.

text

   acl_entry *entry;
   DBUG_ENTER("acl_get");
 
-  tmp_db= strmov(strmov(key, safe_str(ip)) + 1, user) + 1;
+  tmp_db= strmov(strmov(key, safe_str(ip ? ip : host)) + 1, user) + 1;
   end= strnmov(tmp_db, db, key + sizeof(key) - tmp_db);
 
   if (end >= key + sizeof(key)) // db name was truncated

Source: MariaDB commit 67ea07dd. The patch substitutes host when ip is null, eliminating the empty-IP collision between roles and localhost users.

Detection Methods for CVE-2026-107822

Indicators of Compromise

Creation of roles or user@localhost accounts whose names match existing roles, service accounts, or administrative users.
Audit log entries showing a low-privileged principal successfully executing statements that require privileges it was not granted.
CREATE USER or CREATE ROLE activity followed shortly by privilege-sensitive DDL or DML from the newly created principal.

Detection Strategies

Enable the MariaDB audit plugin and query mysql.user and mysql.roles_mapping for name collisions between roles and user@localhost entries.
Correlate CREATE USER/CREATE ROLE events with subsequent authorization decisions on sensitive schemas to spot unexpected privilege use.
Compare the installed MariaDB build against the fixed versions (10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, 13.0.2) during vulnerability scans.

Monitoring Recommendations

Forward MariaDB general and audit logs into a central analytics platform and alert on new principals whose names overlap existing accounts.
Baseline normal use of CREATE USER, CREATE ROLE, GRANT, and SET ROLE, and flag deviations from administrative accounts.
Track database privilege changes alongside endpoint and identity telemetry so that database-layer anomalies are visible next to host and user context.

How to Mitigate CVE-2026-107822

Immediate Actions Required

Upgrade MariaDB server to 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2, depending on your release branch.
Audit mysql.user and mysql.roles_mapping for existing name collisions between roles and localhost users and rename or remove collisions.
Restrict the CREATE USER and CREATE ROLE privileges to a minimal set of administrators and rotate credentials for accounts that may have been impersonated.

Patch Information

The fix is included in MariaDB releases 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. The underlying code change is commit 67ea07dd in sql/sql_acl.cc, which replaces an empty IP in the ACL cache key with the host value.

Workarounds

Avoid creating roles whose names match any existing user@localhost account, and vice versa, until all nodes are patched.
Revoke CREATE USER from non-administrative accounts to prevent attacker-controlled creation of colliding principals.
Restart the MariaDB server after suspicious principal creation to flush the ACL cache and force fresh privilege resolution.

bash

# Identify role/user name collisions that could trigger the ACL cache confusion
mariadb -u root -p -e "\
SELECT r.User AS role_name \
FROM mysql.user r \
JOIN mysql.user u \
  ON r.User = u.User \
WHERE r.is_role = 'Y' \
  AND u.is_role = 'N' \
  AND u.Host = 'localhost';"

# Verify the installed version is patched
mariadb -V