CVE-2026-107385: MariaDB Connector/Node.js: SQL injection in the text protocol when the session uses NO_BACKSLASH_ESCAPES
Description When escaping string and binary parameters for the text protocol, the connector always escaped the quote character with a backslash, without ever consulting the session's NOBACKSLASHESCAPES SQL mode. The server status flag was declared (STATUSNOBACKSLASHESCAPES) but never read.
Under a server or session running with NOBACKSLASHESCAPES, the backslash is an ordinary character and the quote must be escaped by doubling it. The escaped value produced by the connector therefore closed the string literal, and a value passed through a placeholder was interpreted as SQL.
All text-protocol escaping entry points were affected, including Connection.escape().
Impact An attacker able to influence any value the application passes as a query parameter could execute arbitrary SQL with the privileges of the application's database user: read, modify or delete any data reachable by that connection.
Exposure requires a deployment where NOBACKSLASHESCAPES is enabled — server-wide, through the connector's sessionVariables / initSql options, or by an application-issued SET sqlmode. It is not implied by the ANSI, ORACLE or TRADITIONAL compound modes on MariaDB 11.4, so it has to be set deliberately. Where it is enabled, no unusual application code is needed: the standard placeholder API is the injection point.
execute() and batch() are not affected: the binary prepared-statement and bulk protocols send parameter values out of band.
Resolution The escaping routines now branch on the session status flag, doubling the quote and leaving the backslash untouched when NOBACKSLASHESCAPES is set
Workarounds Use execute() or batch(), or do not enable NOBACKSLASHESCAPES, until upgraded.
Credit Reported by fg0x0.
Other sources
MariaDB Connector/Node.js is used to connect applications developed on Node.js to MariaDB and MySQL databases. Prior to 3.2.5, 3.3.4, 3.4.7, and 3.5.4, text-protocol escaping always prefixes quotes with a backslash and does not honor the session's NOBACKSLASHESCAPES mode, including in Connection.escape(). When that mode is enabled, the backslash is an ordinary character, so an attacker-controlled placeholder value can close the SQL string literal and inject arbitrary SQL with the application's database privileges. The vulnerable configuration may be enabled server-wide, through connector initialization options, or with an application-issued SET sqlmode; execute() and batch() use binary protocols and are not affected. This issue is fixed in versions 3.2.5, 3.3.4, 3.4.7, and 3.5.4.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.5.4 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.4.7 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.3.4 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.2.5 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.2.5 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.3.4 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.4.7 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.5.4 - Configuration
Do not enable NO_BACKSLASH_ESCAPES server-wide, through connector sessionVariables/initSql options, or with an application-issued SET sql_mode.
MariaDB SQL session/server configuration NO_BACKSLASH_ESCAPES = disabled - Compensating control
Until upgrading, use execute() or batch() instead of text-protocol escaping and placeholders; these use binary prepared-statement and bulk protocols.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using npm/mariadb versions earlier than 3.2.5, 3.3.4, 3.4.7, or 3.5.4 are exposed when they use the text protocol while the session has NO_BACKSLASH_ESCAPES enabled. The mode can be enabled server-wide, through connector initialization options, or by an application-issued SET sql_mode.
What does an attacker need to exploit it?
An attacker needs control over a placeholder value used in a text-protocol query in an affected session. With NO_BACKSLASH_ESCAPES enabled, that value can terminate a SQL string literal and inject SQL using the application's database privileges.
Are execute() and batch() calls affected?
No. execute() and batch() use binary protocols and are not affected by this text-protocol escaping issue.
What can be done if an immediate upgrade is not possible?
Avoid using the text protocol for attacker-controlled values in sessions where NO_BACKSLASH_ESCAPES is enabled. Using execute() or batch() avoids the affected protocol path; disabling NO_BACKSLASH_ESCAPES also removes the stated vulnerable configuration.
How can I determine whether an application may be affected?
Check whether the installed connector version predates its applicable fixed release, and identify sessions using NO_BACKSLASH_ESCAPES. Review server-wide SQL mode settings, connector initialization options, and application-issued SET sql_mode statements, then determine whether affected sessions issue text-protocol queries with attacker-controlled placeholder values.