CVE-2026-44173

What it actually does

MariaDB fails to enforce the FILE privilege for SELECT ... INTO OUTFILE and SELECT ... INTO DUMPFILE when the FROM clause is composed only of subqueries. An authenticated database user who can issue SELECT statements can cause the MariaDB server process to write attacker-controlled content to files on the database server, subject to MariaDB file-write behavior, secure_file_priv restrictions, filesystem permissions, and non-overwrite semantics. The most direct impact is unauthorized server-side file creation or disk consumption; in higher-risk deployments, such as database servers with write access to web roots, plugin directories, scheduled-task locations, or application-consumed paths, the primitive may be chained into application compromise or code execution.

Why it matters to the business

Organizations running affected MariaDB versions may have database accounts that can write files on the server even though they were intentionally not granted file-system access. This can lead to service disruption, unauthorized modification of application-accessible files, compliance concerns around privilege boundaries, and potential escalation if the database server can write to sensitive locations. The issue is not currently listed in CISA KEV, has low reported EPSS likelihood, and has no public exploit maturity in the provided data, but it affects multiple long-term MariaDB release branches and should be remediated during normal security patch cycles, with higher urgency for internet-facing, shared, multi-tenant, or web-adjacent database deployments.

How an attack unfolds

An attacker first obtains valid MariaDB credentials for an account that can connect to the server and run SELECT queries but does not have the FILE privilege. The attacker then crafts a SELECT statement whose FROM clause contains only subqueries and appends INTO OUTFILE or INTO DUMPFILE to write controlled bytes to a server-side path. Because affected versions skip the FILE privilege check for this query shape, MariaDB accepts the write if the target path is allowed by secure_file_priv, the file does not already exist, and the MariaDB OS process can create it. The attacker may use this to create marker files, consume disk space, place data where another application will read it, or, in favorable configurations, write script content into a web-accessible directory to gain further execution through the application stack.

How to fix it

Upgrade MariaDB to a patched release for the deployed branch: 10.6.26 or later, 10.11.17 or later, 11.4.11 or later, 11.8.7 or later, or 12.3.2 or later. Affected ranges are 10.6.1 through versions before 10.6.26, 10.11.1 through versions before 10.11.17, 11.4.1 through versions before 11.4.11, 11.8.1 through versions before 11.8.7, and 12.3.1. As defense in depth, set secure_file_priv to a tightly controlled directory or disable file import/export functionality where operationally feasible, ensure the MariaDB service account cannot write to web roots or executable locations, revoke unnecessary SELECT access from untrusted accounts, remove FILE privilege from accounts that do not strictly need it, and monitor or restrict use of INTO OUTFILE and INTO DUMPFILE statements.

How to confirm the fix worked

Confirm the running MariaDB version is one of the fixed versions or later by querying SELECT VERSION(); or using the operating system package manager. Review configuration to verify secure_file_priv is set to a restricted path or otherwise aligned with policy. Attempt a controlled negative test using a non-FILE-privileged test account: a SELECT ... INTO OUTFILE or SELECT ... INTO DUMPFILE statement with a FROM clause containing only subqueries should be denied unless the account legitimately has FILE privilege. Confirm that the MariaDB service account lacks write permission to application web roots, executable directories, startup locations, and other sensitive filesystem paths. Validate that database audit logging or general query logging captures file-write statements for ongoing monitoring.

Typical attack path

1. Acquire valid MariaDB credentials for a low-privileged user that can connect and execute SELECT statements.
2. Enumerate server behavior and writable export locations, commonly by checking secure_file_priv or testing allowed output directories.
3. Craft a SELECT ... INTO OUTFILE or SELECT ... INTO DUMPFILE statement where the FROM clause contains only subqueries.
4. Write attacker-controlled content to a permitted filesystem path as the MariaDB server process.
5. Use the created file for disruption, persistence, application manipulation, or further exploitation if the path is consumed or executed by another component.
6. Cover tracks by minimizing query volume or deleting application-level artifacts where possible.

How to detect it

Review MariaDB general query logs, MariaDB Audit Plugin logs, database proxy logs, application database access logs, and SIEM-ingested SQL telemetry for SELECT statements containing INTO OUTFILE or INTO DUMPFILE, particularly where the account lacks the FILE privilege or the query contains only derived tables/subqueries in the FROM clause. Correlate suspicious queries with filesystem activity by the MariaDB service account, newly created files in export directories, web roots, temporary directories, application directories, cron/systemd locations, or other paths writable by the database process. Check for sudden disk growth, unexpected files owned by mysql or mariadb, web server requests to newly created script files, and application errors following file creation. If audit logs include privilege information, flag successful OUTFILE/DUMPFILE operations by accounts not expected to have FILE privilege. Because successful exploitation may look like a normal SQL export operation, absence of SQL logging can make retrospective confirmation difficult; supplement with filesystem timestamps, OS auditd events, EDR file creation telemetry, and backups or file integrity monitoring.

• INTO OUTFILE
• INTO DUMPFILE
• SELECT INTO OUTFILE
• SELECT INTO DUMPFILE
• SELECT * INTO OUTFILE
• SELECT * INTO DUMPFILE
• FROM (SELECT
• FROM(SELECT
• secure_file_priv
• /var/lib/mysql-files/
• /tmp/
• /var/www/
• /var/www/html/
• C:\\inetpub\\wwwroot\\
• mysqld
• mariadbd

What your security team should do

• Inventory MariaDB deployments and identify instances running affected versions across the 10.6, 10.11, 11.4, 11.8, and 12.3 branches.
• Prioritize patching systems where untrusted users, applications, customers, or shared services have direct database credentials.
• Upgrade to MariaDB 10.6.26, 10.11.17, 11.4.11, 11.8.7, 12.3.2, or later as appropriate for the deployed branch.
• Review all accounts with database access and remove unnecessary privileges, especially FILE and broad SELECT permissions for untrusted identities.
• Set or tighten secure_file_priv and ensure MariaDB cannot write to web-accessible, executable, backup, cron, service, or application configuration paths.
• Search historical database query logs and audit logs for INTO OUTFILE and INTO DUMPFILE usage, especially from accounts that should not perform file export operations.
• Add SIEM detections for SELECT statements using INTO OUTFILE or INTO DUMPFILE and alert on any execution by non-administrative accounts.
• Investigate any newly created files owned by the MariaDB service account outside approved export directories.