CVE-2026-107822: 
MariaDB Server Analyse et atténuation des vulnérabilités

CVE-2026-107822 is an ACL cache key collision vulnerability in MariaDB Server that allows an authenticated attacker with the CREATE USER privilege to impersonate another principal's database-level privileges. The flaw affects MariaDB versions 10.6.1–10.6.27, 10.11.1–10.11.18, 11.4.1–11.4.12, 11.8.1–11.8.8, 12.3.1–12.3.2, and 13.0.1. It was published on October 9, 2026, with fixes available in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. The vulnerability carries a CVSS v3.1 base score of 6.4 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is an incorrect cache key generation in MariaDB's acl_get() function within sql/sql_acl.cc (CWE-706: Use of Incorrectly-Resolved Name or Reference; CWE-863: Incorrect Authorization; CWE-694: Use of Multiple Resources with Duplicate Identifier). Both localhost user connections (which have ip=0, host="localhost") and roles (which have ip="", host="") produced an empty IP component when building the ACL cache key, causing the cache to treat them as the same principal. The fix changes the key construction from safe_str(ip) to safe_str(ip ? ip : host), ensuring localhost connections use "localhost" rather than an empty string in the cache key, thereby disambiguating roles from localhost users (GitHub Commit, GitHub Advisory). Exploitation requires high privileges (CREATE USER), high attack complexity, and user interaction, limiting the practical attack surface (Red Hat CVE).

A successful exploit allows an authenticated attacker with CREATE USER privilege to exercise database-level privileges belonging to another account — either by creating a localhost user whose name matches an existing privileged role, or a role whose name matches an existing privileged localhost user. When the original principal's database privileges are cached, the attacker can execute queries or operations with those elevated permissions, leading to unauthorized data access (confidentiality), unauthorized data modification (integrity), and potential disruption of database operations (availability). The scope is limited to the affected MariaDB instance, but lateral movement within the database is possible if the impersonated account holds broad schema-level grants (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is 0.0, reflecting a very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to already hold the CREATE USER privilege, which is a high-privilege administrative operation, and also requires user interaction (the original principal must trigger a cache population), making opportunistic exploitation unlikely (GitHub Advisory).

1. Reconnaissance: Identify a target MariaDB instance running a vulnerable version (10.6.1–10.6.27, 10.11.1–10.11.18, 11.4.1–11.4.12, 11.8.1–11.8.8, 12.3.1–12.3.2, or 13.0.1) and enumerate existing privileged roles or localhost users with database-level grants.
2. Obtain CREATE USER privilege: Authenticate to the MariaDB server using an account that already holds the CREATE USER privilege.
3. Create colliding principal: If a privileged role named r1 exists, create a localhost user with the same name: CREATE USER 'r1'@'localhost' IDENTIFIED BY 'password';. Alternatively, if a privileged localhost user admin@localhost exists, create a role named admin.
4. Trigger cache population: Wait for or induce the original privileged principal (e.g., r1 role or admin@localhost) to connect and execute a database-level query, causing their privileges to be stored in the ACL cache under the colliding key.
5. Exercise impersonated privileges: Connect as the newly created colliding principal and access databases or execute operations that were only authorized for the original account, leveraging the cached privilege entry (GitHub Advisory, GitHub Commit).

• Logs: MariaDB general query log entries showing CREATE USER statements creating accounts whose names exactly match existing role names or localhost user names; unexpected SELECT or INSERT/UPDATE/DELETE statements executed by a newly created user account against databases they were not explicitly granted access to.
• Database Audit: Presence of user accounts in mysql.user that share names with entries in mysql.roles_mapping or existing @localhost accounts; accounts created shortly before suspicious privilege-escalated queries.
• Process/Session: Database sessions from a low-privilege account successfully accessing schemas beyond their explicit grants, particularly after another privileged session has recently connected and queried the same database.

Upgrade MariaDB Server to a patched version: 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2, depending on the active version branch (GitHub Advisory). As a workaround, restrict the CREATE USER privilege exclusively to highly trusted administrators — in most standard deployments this is already the case, which limits the exploitable population. Additionally, audit existing user accounts for names that collide with role names or other @localhost accounts and remove or rename any suspicious entries (Feedly).