CVE-2026-3494

What it actually does

CVE-2026-3494 is an audit logging bypass in MariaDB Server through 11.8.5 when the MariaDB server audit plugin is enabled and `server_audit_events` is configured to log filtered query classes such as `QUERY_DCL`, `QUERY_DDL`, or `QUERY_DML`. An authenticated database user can prefix a SQL statement with a double-hyphen comment or hash comment so that the statement executes but is not recorded by the affected audit-event filtering path. The flaw does not directly grant additional database privileges or remote code execution, but it weakens integrity and non-repudiation of database audit trails for privileged or sensitive SQL activity.

Why it matters to the business

The main risk is loss of reliable evidence about who changed data, schemas, permissions, or other database state. This can affect incident response, fraud investigation, insider-risk monitoring, compliance reporting, and regulated audit requirements. Because exploitation requires valid database credentials and the CVSS and EPSS values are low, broad opportunistic exploitation is less likely; however, the flaw is important for environments that rely on MariaDB audit logs as a control for detecting unauthorized data changes or privileged database activity. Amazon Aurora MySQL and Amazon RDS deployments should be reviewed for vendor exposure and available managed-service updates or mitigations.

How an attack unfolds

An attacker first obtains valid database access, such as through a compromised application account, developer credential, reused password, or malicious insider access. They identify or assume that MariaDB server audit logging is enabled with filtered query event classes such as DCL, DDL, or DML. Instead of issuing a sensitive SQL statement directly, they send it with a leading SQL comment using `--` or `#` style syntax. The database still parses and executes the intended SQL after the comment, but the affected audit plugin filtering logic fails to record the statement. The attacker can then perform actions such as changing rows, modifying objects, granting privileges, creating persistence through database users or routines, or removing records while reducing visibility in the audit log. Post-exploitation review may show database state changes without corresponding MariaDB audit entries, requiring correlation with binary logs, general query logs, application logs, proxy logs, cloud database logs, and backup/diff evidence.

How to fix it

Upgrade MariaDB Server to a vendor release that fixes the audit plugin filtering behavior once available for the deployed branch; the provided advisory data lists affected versions through 11.8.5 and does not provide an exact fixed version. For managed services such as Amazon Aurora MySQL and Amazon RDS, monitor AWS engine-version advisories, apply the first fixed engine version when released, and verify whether the managed service uses or exposes the affected MariaDB server audit plugin behavior. Until patched, avoid relying solely on filtered `QUERY_DCL`, `QUERY_DDL`, or `QUERY_DML` audit events for security monitoring. Where operationally acceptable, enable broader query logging such as unfiltered `QUERY` audit events, general query logging, database proxy logging, or cloud database activity streams. Restrict database accounts to least privilege, especially permissions for `GRANT`, `CREATE USER`, `ALTER`, `DROP`, `CREATE`, bulk updates, and destructive DML. Consider temporarily alerting on or blocking SQL submitted through applications or administrative interfaces that begins with comment syntax followed by sensitive SQL, while accounting for legitimate tools that prepend SQL comments.

How to confirm the fix worked

Confirm the running database version and audit plugin configuration. On self-managed MariaDB, check `SELECT VERSION();`, `SHOW PLUGINS;`, and `SHOW VARIABLES LIKE 'server_audit%';`, especially `server_audit_events`. Validate exposure by using a non-production instance with the same version and audit settings: execute representative DML, DDL, or DCL statements normally and then execute equivalent statements prefixed by `--` or `#` comments. The system is exposed if the prefixed statement executes successfully but does not appear in the MariaDB audit log while the non-prefixed equivalent does. After patching or mitigating, repeat the test and confirm both normal and comment-prefixed statements are captured by the intended audit source. For managed database services, verify the engine version, audit configuration, and provider documentation, then perform only approved validation in a test instance or maintenance window.

Typical attack path

1. Acquire valid credentials for a MariaDB-compatible database user.
2. Connect to an affected MariaDB Server, Amazon Aurora MySQL, or Amazon RDS-compatible deployment where vulnerable audit plugin behavior may be present.
3. Confirm the account has permission to run useful DML, DDL, or DCL statements.
4. Prefix SQL statements with `--` or `#` style comments before the actual operation.
5. Execute sensitive operations such as `UPDATE`, `DELETE`, `INSERT`, `ALTER`, `DROP`, `CREATE`, `GRANT`, or `REVOKE`.
6. Rely on the audit plugin filtering flaw to omit those statements from filtered audit logs.
7. Use missing or incomplete audit records to hinder investigation, compliance review, or attribution.

How to detect it

Because successful exploitation may intentionally omit records from the MariaDB server audit log, detection should focus on correlation and negative evidence rather than the audit log alone. Compare MariaDB audit logs with binary logs, general query logs, slow query logs if enabled, database proxy logs, application SQL logs, cloud database logs, backup diffs, schema-drift tools, and privilege/user snapshots. Look for DML, DDL, or DCL activity that appears in one telemetry source but is missing from the MariaDB audit log during the same time window. Search query-capable logs for statements that begin with SQL comment markers followed by sensitive keywords such as `CREATE`, `ALTER`, `DROP`, `TRUNCATE`, `INSERT`, `UPDATE`, `DELETE`, `REPLACE`, `GRANT`, `REVOKE`, `CREATE USER`, `ALTER USER`, or `SET PASSWORD`. Review changes to database users, roles, grants, stored routines, triggers, events, and schema objects that lack matching audit entries. For managed services, include provider logs and database activity streams if available. There are no known KEV or ransomware-campaign indicators in the supplied data, and EPSS is low and flat, so investigations should be driven by exposure, privilege level, and anomalous database-change evidence rather than assumed mass exploitation.

• server_audit_events=QUERY_DCL
• server_audit_events=QUERY_DDL
• server_audit_events=QUERY_DML
• server_audit_events=.*QUERY_DCL.*QUERY_DDL.*QUERY_DML
• (?is)^\s*--.*\n\s*(CREATE|ALTER|DROP|TRUNCATE|INSERT|UPDATE|DELETE|REPLACE|GRANT|REVOKE)\b
• (?is)^\s*#.*\n\s*(CREATE|ALTER|DROP|TRUNCATE|INSERT|UPDATE|DELETE|REPLACE|GRANT|REVOKE)\b
• (?is)^\s*--.*\n\s*CREATE\s+USER\b
• (?is)^\s*#.*\n\s*CREATE\s+USER\b
• (?is)^\s*--.*\n\s*ALTER\s+USER\b
• (?is)^\s*#.*\n\s*ALTER\s+USER\b
• (?is)^\s*--.*\n\s*SET\s+PASSWORD\b
• (?is)^\s*#.*\n\s*SET\s+PASSWORD\b

What your security team should do

• Inventory MariaDB, Amazon Aurora MySQL, and Amazon RDS deployments and identify instances using MariaDB server audit plugin query-event filtering.
• Prioritize remediation for databases supporting regulated workloads, financial operations, identity stores, administrative systems, or high-risk insider-access scenarios.
• Upgrade to the first fixed MariaDB or managed-service engine version as soon as the vendor publishes one; track this closely because no fixed version was provided in the input data.
• Until upgraded, enable compensating telemetry such as broader audit events, general query logs, binary logs, database proxy logs, cloud activity streams, and application-level SQL operation logging.
• Review database users with DDL, DCL, and broad DML privileges; remove unnecessary privileges and rotate credentials for shared or stale accounts.
• Create detections for SQL text beginning with `--` or `#` followed by sensitive SQL keywords in query-capable log sources outside the affected audit plugin path.
• Investigate discrepancies where schema changes, grants, row-count changes, or binlog events lack corresponding MariaDB audit records.
• Document the audit limitation for compliance and incident-response teams until the affected systems are patched or mitigated.