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.