Vulnerability GHSA-r3rv-jm3r-62q2

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 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().

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 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.

Resolution

The escaping routines now branch on the session status flag, doubling the quote and leaving the backslash untouched when NO_BACKSLASH_ESCAPES is set

Workarounds

Use execute() or batch(), or do not enable NO_BACKSLASH_ESCAPES, until upgraded.

Credit

Reported by fg0x0.