CVE-2026-107822 in MariaDB
Summary
by MITRE • 10/09/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
MariaDB is a widely deployed relational database management system that serves as a community-developed fork of MySQL, offering enhanced features and performance optimizations for enterprise environments. The vulnerability described herein affects specific versions including MariaDB server releases from 10.6.1 through 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. This flaw resides within the access control list caching mechanism, which is designed to optimize authentication and authorization checks by storing previously resolved privilege information in memory. The core technical issue stems from a collision in how database-privilege cache keys are generated for different types of principals. Specifically, when comparing role-based privileges against user-specific privileges, MariaDB incorrectly treated accounts with localhost hostnames as having an empty IP component. This normalization logic failed to distinguish between a standard local user account and a role definition that also utilized the localhost designation, resulting in both entities generating identical cache keys despite representing distinct security principals.
The operational impact of this vulnerability allows for privilege escalation through a technique known as cache poisoning or key collision attack. An attacker who possesses the CREATE USER privilege can exploit this flaw by creating a malicious principal with a hostname set to localhost that matches an existing role's identifier in terms of cache key generation. Once this colliding principal is established, any subsequent access control checks for the original legitimate user may incorrectly retrieve cached privileges intended for the newly created account or vice versa. This misalignment enables the attacker to exercise database permissions assigned to other accounts without proper authorization verification. The severity of this issue lies in its potential to bypass authentication boundaries and grant unauthorized access to sensitive data, effectively undermining the integrity of MariaDB's security model by allowing low-privileged users to elevate their rights through cache manipulation rather than direct exploitation of SQL injection or buffer overflow vulnerabilities.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves an incorrect evaluation of user permissions due to flawed logic in the access control mechanism. It also relates to CWE-697 Incorrect Comparison, specifically regarding the failure to properly distinguish between distinct entities during cache key generation. In terms of the MITRE ATT&CK framework for databases, this behavior corresponds to techniques involving privilege escalation and unauthorized access via misconfigured permissions or cached state manipulation. The attack vector requires initial low-level privileges such as CREATE USER, which limits its exploitability but does not eliminate the risk in environments where database creation rights are granted to application service accounts or less privileged administrative users who should not have authority over security principal definitions.
Mitigation strategies primarily involve upgrading MariaDB to patched versions that resolve this cache key generation logic error. Administrators must ensure they upgrade to version 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2 and later releases where the distinction between role-based and user-specific cache keys is correctly enforced based on host components rather than treating localhost as an empty string for both types of principals. In addition to software updates, organizations should enforce strict least-privilege principles by auditing which accounts possess CREATE USER privileges and restricting this capability only to dedicated security administrators who require it for legitimate operational tasks. Regular review of user permissions and roles can help identify any unauthorized principal creations that might have occurred prior to patching. Furthermore, enabling detailed audit logging allows security teams to monitor for unusual patterns in privilege checks or account creation events that could indicate exploitation attempts against this specific vulnerability vector.