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 NO_BACKSLASH_ESCAPES SQL mode. The server status flag was declared (STATUS_NO_BACKSLASH_ESCAPES) but never read.
Under a server or session running with NO_BACKSLASH_ESCAPES, 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().
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 NO_BACKSLASH_ESCAPES is enabled — server-wide, through the connector's sessionVariables / initSql options, or by an application-issued SET sql_mode. 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.
The escaping routines now branch on the session status flag, doubling the quote and leaving the backslash untouched when NO_BACKSLASH_ESCAPES is set
Use execute() or batch(), or do not enable NO_BACKSLASH_ESCAPES, until upgraded.
Reported by fg0x0.
{
"cwe_ids": [
"CWE-89"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T19:42:28Z",
"nvd_published_at": null,
"severity": "HIGH"
}