CVE-2026-107822: MariaDB: database privilege escalation via user / role name collision in the acl cache
MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, MariaDB's ACL cache could generate the same database-privilege cache key for role and localhost user names that matched because both used an empty IP component. An attacker with CREATE USER could create the colliding principal and, when the original principal's database privileges were cached, exercise privileges assigned to the other account. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
MariaDBto a version that resolves this vulnerability.Fixed in 10.6.28 - Upgrade
Upgrade
MariaDBto a version that resolves this vulnerability.Fixed in 10.11.19 - Upgrade
Upgrade
MariaDBto a version that resolves this vulnerability.Fixed in 11.4.13 - Upgrade
Upgrade
MariaDBto a version that resolves this vulnerability.Fixed in 11.8.9 - Upgrade
Upgrade
MariaDBto a version that resolves this vulnerability.Fixed in 12.3.3 - Upgrade
Upgrade
MariaDBto a version that resolves this vulnerability.Fixed in 13.0.2
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
MariaDB Server versions from 10.6.1 through the fixed releases are affected: before 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2, depending on the release series. Exploitation depends on the presence of a localhost user and a role with matching names.
What access does an attacker need to exploit it?
The attacker needs CREATE USER privilege and must be able to create a principal whose name collides with an existing role or localhost user name. They also rely on the original principal's database privileges being present in the ACL cache.
How can I determine whether my server is at risk before patching?
Check the MariaDB version against the fixed versions and review whether roles and localhost user accounts share the same name. Also identify users granted CREATE USER, since that privilege is required to create the colliding principal.
What can be done if upgrading is not immediately possible?
Restrict CREATE USER to only highly trusted administrators and avoid or remediate matching names between roles and localhost user accounts. Upgrade to the applicable fixed release as soon as possible.