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.

Description With the non-default permitSetMultiParamEntries option enabled, an object passed as a query parameter is expanded into a SET clause, each key becoming a column name. The three code paths implementing that expansion built the backtick-quoted identifier by hand and wrote the key out unescaped, while only the value was escaped.

A key containing a backtick therefore closed the identifier, and the remainder of the key was parsed as SQL. The connector's own identifier escaper (escapeId, which correctly doubles backticks) existed but was not called from any of the three sites. This is an incomplete fix of GitHub issue #252, which corrected escapeId itself in 2023 but left these hand-built call sites unchanged.

Impact

An application that enables permitSetMultiParamEntries and passes an object with attacker-influenced keys into a statement such as conn.query('UPDATE users SET ? WHERE id = ?', [body, id]) allows the caller to write columns the application never intended to expose — a role, balance or password column — and to append arbitrary SQL to the statement, since the injected text is not confined to an assignment.

Exposure requires the option to be enabled: it is off by default, and with it off the object is serialised and escaped as a single string literal, so the key never reaches the SQL grammar. Passing a request body into this API is, however, the ordinary reason to enable the option. An application that enables it is asking for keys to become column names, not for keys to become arbitrary SQL.

Resolution All three expansion sites now route the key through the identifier escaper, doubling backticks before writing the column name. The feature is unchanged for legitimate keys, including reserved words.

Workarounds Disable permitSetMultiParamEntries (the default), or validate object keys against an allow-list of column names before passing them to query(), until upgraded.

Credit Reported by fg0x0.

Description When encoding a GeoJSON Polygon or MultiPolygon parameter for the binary protocol, the connector sized its output buffer from the length property of each ring, then wrote each ring only if it was a real array. The two loops disagreed: any non-array ring carrying a numeric length (a string, or an object such as {"length": 4000}) still reserved 4 + 16 length bytes, but wrote none of them. The buffer came from Buffer.allocUnsafe() and was returned in full regardless of how far the write position had advanced, so every reserved-but-unwritten byte was uninitialized Node.js heap.

The sibling LineString case handled this correctly, aborting with null on the first malformed point, so no reserved byte could escape unwritten.

The only gate on this path is value.type naming a GeoJSON type, so any object shaped like {"type": "Polygon", ...} reached the encoder.

Impact An application that passes an attacker-influenced object as a parameter to execute() or batch() writes uninitialized process memory into the database, where it is readable by anyone who can read that row and persists into backups and replicas. Applications accepting GeoJSON for map or location features are the natural case, as the attacker controls coordinates directly.

The disclosed memory is not scoped to the requesting user: in a shared Node.js process the heap may hold other users' request and response bodies, session tokens and cookies, database credentials and TLS key material. The leak is silent — the insert succeeds and the column simply holds more bytes than it should.

No non-default connector option and no particular server configuration are required. query() is not affected: the text encoder builds geometry as strings rather than through Buffer.allocUnsafe().

Resolution Both the Polygon and MultiPolygon encoders now reject a non-array ring before reserving space for it, so no byte of the allocation can be left uninitialized by the writing loop, matching the existing LineString behaviour.

Workarounds Validate that GeoJSON coordinates are properly nested arrays of numbers before passing the object as a parameter, or use query(), until upgraded.