MariaDB Server EUVD-2026-95922

Exploitation requires the attacker to already hold the CREATE USER privilege (a high administrative privilege), and requires the coexistence of a role and a localhost user whose names collide into the same ACL database-privilege cache key because both resolve with an empty IP component. It is further gated on the original principal's database privileges having been cached - i.e. that legitimate account must have been used/connected - matching the AC:H complexity. Affected: MariaDB server from 10.6.1 up to (but not including) the fixed releases. Limiting factors: this is not reachable by unauthenticated or low-privilege users; it depends on non-trivial account-naming collisions and ACL-cache timing state, which sharply narrows realistic exploitation to privileged insiders or already-compromised admin accounts.

This is a moderate-severity privilege-confusion flaw (vendor CVSS 6.4) whose real-world risk is constrained primarily by its high privilege prerequisite rather than its CIA impact. The provided CVSS vector (CVSS:3.1/AV:N/AC:H/PR:H/UI:R) already signals a hard-to-reach bug: PR:H means the attacker must already hold the powerful CREATE USER privilege, and AC:H reflects the dependency on a specific name collision plus ACL-cache timing state. No EPSS score, CISA KEV listing, or public POC was supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the signals that would elevate priority are all absent. This is best characterized as a high-CVSS-impact-but-low-likelihood issue: the C:H/I:H/A:H impact is only realized against whatever database privileges the colliding principal holds, and reaching it requires an already-privileged insider or a compromised admin-capable account. Note a signal tension: the vector sets UI:R, yet the described mechanism (the victim principal's privileges merely needing to be cached) reads more like an environmental/timing precondition than classic user interaction - verify the UI metric with the vendor advisory. Overall: patch on normal cadence; it is not an emergency unless CREATE USER is broadly delegated in your environment.

An insider or attacker who has already obtained the CREATE USER privilege on a MariaDB instance creates a new account (e.g. a user whose name collides with an existing role or localhost account) so that both map to the same ACL database-privilege cache key via the empty IP component. Once the legitimate principal's database privileges are cached, the attacker's colliding account exercises those privileges, reading or modifying data it was never granted. No public exploit code exists, and success depends on the high-complexity cache-state and naming conditions described.