Closing the MariaDB CVE-2026-97380 Exception Queue
Closing the MariaDB CVE-2026-97380 Exception Queue Exception queues can outlive the vulnerability they were meant to cover. MariaDB CVE-2026-97380 is a good case for a closure discipline. A GRANT PROXY statement with I
Closing the MariaDB CVE-2026-97380 Exception Queue
Exception queues can outlive the vulnerability they were meant to cover. MariaDB CVE-2026-97380 is a good case for a closure discipline. A GRANT PROXY statement with IDENTIFIED and an empty password caused affected server releases to check the wrong grantor privileges. The vendor says a low-privileged attacker who can name another account may use the flaw to set that account's password.
The CNA gives the vulnerability a CVSS 3.1 score of 8.8 with network access, low complexity, low privileges and no user interaction. The affected range crosses six release lines, so a simple βproduction is patchedβ statement is insufficient unless every database role and deployment artifact is included.
Enumerate affected and fixed releases
Versions 10.6.1 through 10.6.27, 10.11.1 through 10.11.18, 11.4.1 through 11.4.12, 11.8.1 through 11.8.8, 12.3.1 through 12.3.2 and 13.0.1 are listed as affected. Fixed releases are 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 and 13.0.2.
Build the closure list from actual process evidence and managed-service records. Include replicas, read-only backups, developer databases and recovery environments. If an exception was granted before the patch, state the precise system, owner, business reason, network restriction and expiration date.
Close the authorization path
The vulnerable condition is the empty-password clause in GRANT PROXY, combined with an incorrect grantor-privilege check. Review whether low-privilege accounts can issue administrative statements and whether proxy-era grants remain after the upgrade. Remove authority that has no current owner.
The advisory adds a workaround: random, non-guessable account names prevent the stated password-change path because the attacker cannot name the target. This is not a patched binary and its value depends on secrecy. Audit where account names are stored, and make the workaround temporary.
Require account-change evidence
Review database audit and authentication records for the interval when an affected engine served traffic. Compare unexpected password changes with change tickets and source networks. The absence of an alert can be explained by missing audit coverage; record that gap rather than treating it as a clean result.
CISA's SSVC snapshot on 2026-10-28 listed exploitation as none and automatable as no. The evidence available does not identify a confirmed victim. That lowers the basis for claiming an incident, but it does not answer whether a particular environment processed a crafted statement.
Use exposure counts as leads
ZoomEye returned 5,116,358 matches for app="MariaDB" and zero for vul.cve="CVE-2026-97380". The product count is not a confirmed vulnerable population, and the filter result is not proof that no affected asset exists. Keep external visibility separate from internal version and account evidence.
Make the final record useful
A good closure record names every affected asset, the fixed release it now runs and the person who verified it. It includes account-change review results, open logging gaps and exceptions that remain. For each exception, show that the vulnerable statement path is constrained by network and account controls and specify the date the engine will be replaced.
Recheck the queue after autoscaling, restore tests and scheduled maintenance. An asset that enters service with an old image should reopen the control gap even if the original record was closed. The objective is a durable release control that can prove both the patched engine and the absence of unnecessary authority.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.