DEV Community

yutianle
yutianle

Posted on

What Grant Abuse Looks Like in MariaDB Logs: Detection Notes for the AL-2026-144 Flaws

What Grant Abuse Looks Like in MariaDB Logs: Detection Notes for the AL-2026-144 Flaws

Vulnerability overview

Four of the five MariaDB Server vulnerabilities in CSA Singapore alert AL-2026-144 require an authenticated database account with specific privileges. CVE-2026-107814 and CVE-2026-107818 need FILE, CVE-2026-107815 needs access to the CONNECT engine, and CVE-2026-107823 needs CREATE USER together with CREATE VIEW WITH GRANT OPTION. Only CVE-2026-107821, the FRM file parsing flaw, sits outside that model at 8.0 under CVSS v3.1.

Mechanism and exploitation conditions

That shared shape gives defenders a lever. Each of those paths produces database activity, and some produce activity that rarely appears in a well-run instance.

CVE-2026-107823 is the clearest case. Exploitation requires creating a username that carries additional view metadata, so an audit trail will contain a CREATE USER statement with an unusual identifier. Normal usernames are short, structured and predictable; an identifier containing delimiters or a long structured suffix is worth a look. The same attacker then defines a view, so correlate view creation by accounts that do not normally author schema objects.

For CVE-2026-107814 and CVE-2026-107818 the database side is quieter. The file write happens through the FILE privilege, so the signal is a suddenly granted or already over-broad privilege combined with writes landing in the service account home or /run/mysqld. Host-level file integrity monitoring carries more of the load here than SQL logging.

CVE-2026-107815 may surface as an unexpected restart or crash loop on an instance where CONNECT was used, but a memory corruption that succeeds leaves nothing to alert on.

Impact

Detection matters most where patching lags. An instance still inside an affected range that also shows anomalous grant activity is a higher-priority incident than one that merely runs the vulnerable build.

It is equally true that absence of log evidence is weak reassurance. Two of these flaws act on the filesystem, one corrupts a file parser, and one produces a short burst of entirely legal-looking DDL. A quiet log is not a clean host.

Affected products and scope

The advisory lists 10.6.1 to 10.6.27, 10.11.1 to 10.11.18, 11.4.1 to 11.4.12, 11.8.1 to 11.8.8, 12.3.1 to 12.3.2 and 13.0.1. No public proof of concept and no confirmed in-the-wild exploitation are documented, which is precisely why grant hygiene has to substitute for threat intelligence.

Exposure context

A ZoomEye query for app="MariaDB" returns 5111720 assets. That figure locates the software family on the public internet; it says nothing about which hosts grant FILE broadly. Combine it with your own grant inventory to decide where detection content is worth building.

ZoomEye search: https://www.zoomeye.ai/searchResult?q=YXBwPSJNYXJpYURCIg%3D%3D

Remediation and mitigations

Start with the grant baseline. Export SHOW GRANTS for every account, flag anything holding FILE, CREATE USER, or GRANT OPTION, and confirm each one against a known business reason. Anything unexplained is a finding regardless of patch state.

Then add the narrow detections. Alert on CREATE USER where the identifier falls outside the expected naming pattern, and on CREATE VIEW by accounts outside the schema-management group. Turn on general query logging temporarily during investigation windows rather than permanently, since the volume cost is real.

Patch to a fixed build, verify the running version, and re-run the grant export afterwards. The two controls overlap: the patch removes the flaw, and the grant review removes the standing capability that made it reachable.

References

Top comments (0)