CVE-2026-97380: 
MariaDB Server vulnerability analysis and mitigation

CVE-2026-97380 is an authorization bypass vulnerability in MariaDB Server affecting the GRANT PROXY statement. When the statement includes an IDENTIFIED clause with an empty password, the server incorrectly treats it as though no authentication was specified, causing it to check the wrong grantor privileges. This flaw allows a low-privileged authenticated attacker who can name another account to set that account's password without proper authorization. Affected versions span multiple release series: 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. The vulnerability was published on October 16, 2026, and carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Red Hat).

The root cause lies in how MariaDB's SQL parser handles the IDENTIFIED clause within GRANT PROXY statements. When an empty password or empty plugin name is supplied, the has_auth() function in structs.h previously evaluated the condition auth && (auth->plugin.length || auth->auth_str.length || auth->pwtext.length), which returned false for empty values — incorrectly treating the clause as if no authentication was specified at all. The fix simplifies this check to return auth;, ensuring that any explicitly provided IDENTIFIED clause (even with empty values) is recognized as specified authentication. This maps to CWE-620 (Unverified Password Change), CWE-863 (Incorrect Authorization), and CWE-266 (Incorrect Privilege Assignment). The vulnerability requires only low privileges and no user interaction, exploitable over the network by issuing a crafted GRANT PROXY ... IDENTIFIED VIA '' statement (GitHub Advisory, Patch Commit).

Successful exploitation allows a low-privileged attacker to change the password of any named database account, effectively taking over that account regardless of its privilege level. If a high-privileged account (e.g., a DBA or root-equivalent user) is targeted, the attacker could escalate to full database control, enabling unauthorized data access, modification, or deletion. The CVSS v3.1 scores confidentiality, integrity, and availability impacts all as High, reflecting the potential for complete database compromise (GitHub Advisory, Red Hat).

As of the time of publication, no public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation (Feedly). The EPSS score is reported as 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was discovered and reported by researcher Kévin GERVOT (GitHub Advisory). Despite the lack of active exploitation, the low attack complexity and low privilege requirement make this a high-priority patching target.

1. Reconnaissance: Identify MariaDB server instances running vulnerable 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, or 13.0.1) using network scanning tools or by querying SELECT VERSION(); after obtaining any low-privileged database credential.
2. Obtain low-privileged access: Authenticate to the MariaDB server with any valid low-privileged account (e.g., a read-only application user).
3. Identify target account: Enumerate existing database accounts using SELECT user, host FROM mysql.user; or by guessing common account names (e.g., admin, dba, root).
4. Craft malicious GRANT PROXY statement: Issue a GRANT PROXY statement with an empty IDENTIFIED VIA clause targeting the victim account, for example: GRANT PROXY ON victim_user@localhost TO attacker_user@localhost IDENTIFIED VIA '';
5. Exploit authorization bypass: The server incorrectly treats the empty IDENTIFIED clause as unspecified authentication, bypasses proper grantor privilege checks, and sets the target account's password to the empty value.
6. Authenticate as victim: Log in to the MariaDB server as the target account using the newly set empty password, gaining that account's full privileges (GitHub Advisory, Patch Commit).

• Logs: MariaDB general query log entries showing GRANT PROXY ... IDENTIFIED VIA '' or GRANT PROXY ... IDENTIFIED BY '' statements issued by low-privileged accounts; unexpected ALTER USER or password change events in the audit log.
• Logs: Authentication log entries showing a previously password-protected account suddenly authenticating with an empty password or from an unexpected host/user context.
• Database: Unexpected changes to the mysql.user table, particularly authentication_string fields being cleared or modified for high-privileged accounts; review with SELECT user, host, authentication_string, password_last_changed FROM mysql.user;.
• Network: Database connections from unexpected source IPs authenticating as privileged accounts (e.g., root, dba) with no password or a changed credential.

Upgrade MariaDB Server to one of the patched versions: 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2 depending on the release series in use (GitHub Advisory). As a temporary workaround where immediate patching is not possible, the MariaDB advisory notes that an attacker cannot exploit this flaw if database user account names are random and non-guessable, reducing the attack surface by preventing account enumeration. Additionally, restricting network access to the MariaDB port and enforcing the principle of least privilege (limiting which users can issue GRANT PROXY statements) will reduce exposure until patching is complete (GitHub Advisory, Red Hat).

The vulnerability was credited to researcher Kévin GERVOT (GitHub handle: kevin-mizu), who reported it to the MariaDB security team (GitHub Advisory). Red Hat has tracked the issue via Bugzilla (bug #2554198) and published a security advisory page, indicating downstream Linux distribution impact is being assessed (Red Hat). Social media activity on Mastodon and infosec community channels noted the disclosure shortly after publication, though no significant controversy or widespread alarm has been observed given the absence of a public PoC.