CVE-2026-3494: MariaDB Audit Logging Bypass Vulnerability

CVE-2026-3494 Overview

A logging bypass vulnerability exists in MariaDB server version through 11.8.5 when the server audit plugin is enabled with specific query filtering configurations. When server_audit_events is configured with QUERY_DCL, QUERY_DDL, or QUERY_DML filtering, an authenticated database user can evade audit logging by prefixing SQL statements with double-hyphen (--) or hash (#) style comments. This allows malicious or unauthorized database operations to be executed without leaving a trace in the audit logs.

Critical Impact

Authenticated users can bypass audit logging mechanisms, enabling undetected execution of sensitive SQL operations including data manipulation, schema changes, and privilege modifications.

Affected Products

• MariaDB Server through version 11.8.5
• Deployments with server audit plugin enabled
• Configurations using QUERY_DCL, QUERY_DDL, or QUERY_DML event filtering

Discovery Timeline

• 2026-03-03 - CVE-2026-3494 published to NVD
• 2026-03-03 - Last updated in NVD database

Technical Details for CVE-2026-3494

Vulnerability Analysis

This vulnerability falls under CWE-778 (Insufficient Logging), where security-critical operations fail to be properly recorded in audit logs. The MariaDB server audit plugin is designed to capture and log database queries based on configured event types. However, the parsing logic fails to properly handle SQL statements that begin with comment syntax.

When an authenticated user prepends a SQL statement with either the double-hyphen (--) or hash (#) comment markers, the audit plugin's event classification mechanism incorrectly interprets or skips processing of the statement. As a result, the actual query executes normally against the database, but the audit trail is not updated. This creates a significant blind spot for security monitoring and compliance requirements.

The vulnerability requires network access and valid database authentication credentials, making it exploitable by any authenticated database user. Organizations relying on MariaDB's audit plugin for compliance logging, forensic analysis, or intrusion detection face substantial risk as malicious insiders or compromised accounts can perform data exfiltration, privilege escalation, or destructive operations without detection.

Root Cause

The root cause lies in the server audit plugin's query parsing and classification logic. When evaluating whether a statement matches the configured QUERY_DCL, QUERY_DDL, or QUERY_DML event filters, the plugin fails to strip or properly handle leading comment syntax before classifying the statement type. The comment prefix causes the classification to fail or return an incorrect result, resulting in the query bypassing the audit log write operation entirely.

Attack Vector

The attack is network-accessible and requires low privilege (valid database authentication). An attacker with legitimate database credentials can craft SQL statements with comment prefixes to evade audit logging while still executing the intended database operations.

For example, an attacker attempting to exfiltrate data or modify records could prefix their malicious queries with -- or # characters. The MariaDB query parser correctly ignores these comments and executes the following SQL, but the audit plugin fails to capture the event due to its flawed classification logic.

The attack is particularly dangerous in environments where audit logs serve as the primary detection mechanism for unauthorized database activity. Database administrators and security teams would have no visibility into the malicious operations being performed.

Detection Methods for CVE-2026-3494

Indicators of Compromise

• Discrepancies between application-level query logs and MariaDB audit logs
• Evidence of comment-prefixed queries in network traffic or application logs that do not appear in server_audit.log
• Unusual patterns of SQL statements beginning with -- or # from specific user accounts
• Data modifications or schema changes with no corresponding audit entries

Detection Strategies

• Enable general query logging (general_log) temporarily to compare against audit plugin output for gaps
• Implement network-level SQL traffic inspection to capture all database queries independently
• Deploy database activity monitoring (DAM) solutions that parse SQL at the network layer
• Correlate application-layer database logging with MariaDB audit logs to identify missing entries

Monitoring Recommendations

• Configure SentinelOne Singularity Platform to monitor MariaDB processes and network connections for anomalous query patterns
• Set up alerts for authenticated users executing high volumes of comment-prefixed SQL statements
• Implement log integrity monitoring to detect tampering or gaps in audit trail
• Review audit plugin configuration and ensure comprehensive logging beyond just DCL/DDL/DML event types

How to Mitigate CVE-2026-3494

Immediate Actions Required

• Review MariaDB server audit plugin configuration and assess exposure
• Implement compensating controls such as network-level query logging
• Audit recent database activity for potential abuse during the exposure window
• Restrict database access to essential personnel and applications until patches are applied

Patch Information

MariaDB users should monitor the AWS Security Bulletin 2026-006 for updated patch information and vendor guidance. Apply the latest MariaDB server updates that address this audit logging bypass as soon as they become available. Organizations using managed database services should verify with their cloud provider that patches have been applied.

Workarounds

• Configure the audit plugin to log all query events (QUERY_ALL) instead of selective filtering as a temporary measure
• Enable MariaDB's general query log as a supplementary logging mechanism
• Deploy network-based database activity monitoring to capture all SQL traffic
• Implement application-level query logging to maintain an independent audit trail

# Configuration example - Enable comprehensive audit logging
# Edit MariaDB configuration file (my.cnf or my.ini)

[mariadb]
# Enable general query log as supplementary logging
general_log = 1
general_log_file = /var/log/mysql/general.log

# Configure audit plugin for all queries (workaround)
server_audit_events = CONNECT,QUERY
server_audit_logging = ON
server_audit_output_type = FILE