GHSA-r3rv-jm3r-62q2: SQL Injection

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.