MariaDB Server EUVD-2026-95899

Affects only RPM-based MariaDB server installs (versions 10.6.1 up to the fixed releases) where the mysql service account was created with the database data directory as its home; Debian/Ubuntu packages are NOT affected because they use /nonexistent as the home. The attacker must hold a database account with the FILE privilege, which is required to write startup dot-files such as .bash_profile into that home directory. Exploitation is further gated by a required local administrator action: someone must open an interactive login shell for the mysql account (e.g. su - mysql, sudo -u mysql -i), explicitly overriding the account's /sbin/nologin shell - this is non-default and is the key limiting factor, alongside the PR:H requirement of a FILE-privileged DB user.

CVSS base score is 8.4 (High) with vector AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H, but the raw score overstates the realistic likelihood of exploitation. No EPSS probability, CISA KEV listing, or public exploit was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Multiple strong mitigating conditions gate this flaw: the attacker must already hold a DB account with the FILE privilege (reflected as PR:H - a high-privilege, trusted database user), the deployment must be an RPM-based install (Debian/Ubuntu packages are explicitly unaffected), and crucially an administrator must manually open an interactive login shell for the mysql account (UI:R), which is non-default behavior because the account's login shell is /sbin/nologin. There is also a notable tension in the signals: the vector is marked AV:N (the malicious dot-file can be written remotely via the DB connection using FILE privilege), yet the payload only executes through a subsequent LOCAL administrator action - so the network attack vector covers the file-write stage only, not the code-execution trigger. S:C and C/I/A:H are justified because a database-layer privilege is escalated into OS-level code execution as the mysql user (a different security authority). Net assessment: this is a legitimate privilege-escalation / sandbox-escape hardening fix, best treated as a targeted or insider-abuse escalation path rather than a mass-exploitable remote vulnerability; prioritize patching on RPM-based MariaDB hosts but it is not an emergency drop-everything issue absent any exploitation signal.

A malicious or compromised database user holding the FILE privilege uses a statement such as SELECT ... INTO OUTFILE to write a crafted .bash_profile into the mysql account's home directory, which on affected RPM installs is the database data directory. Later, when an administrator opens an interactive login shell for the mysql account (e.g. su - mysql or sudo -u mysql -i), the planted dot-file executes arbitrary commands as the mysql user. No public exploit identified at time of analysis, but the technique is straightforward given FILE access.