CVE-2026-107384: MariaDB Connector/Node.js: SQL injection through object keys in SET expansion (permitSetMultiParamEntries)
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.
Other sources
MariaDB Connector/Node.js is used to connect applications developed on Node.js to MariaDB and MySQL databases. From 3.2.0 until 3.2.5, 3.3.4, 3.4.7, and 3.5.4, applications that enable permitSetMultiParamEntries can pass objects whose keys are expanded into a SQL SET clause without being processed by escapeId. An attacker-controlled key containing a backtick can close the quoted identifier and cause the remainder of the key to be interpreted as SQL. This can update columns the application did not intend to expose and can append arbitrary SQL with the database user's privileges. The option is disabled by default, and serialized-object handling used when it is disabled is not affected. This issue is fixed in versions 3.2.5, 3.3.4, 3.4.7, and 3.5.4.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.5.4 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.4.7 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.3.4 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.2.5 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.2.5 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.3.4 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.4.7 - Upgrade
Upgrade
MariaDB Connector/Node.jsto a version that resolves this vulnerability.Fixed in 3.5.4 - Configuration
Disable permitSetMultiParamEntries until upgraded; it is disabled by default.
MariaDB Connector/Node.js permitSetMultiParamEntries = false
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using MariaDB Connector/Node.js versions from 3.2.0 up to the fixed releases are exposed only if they enable permitSetMultiParamEntries and pass attacker-controlled object keys into SET-clause expansion. The option is disabled by default; serialized-object handling when it remains disabled is not affected.
What does an attacker need to exploit it?
An attacker must be able to influence an object key that the application passes through the permitSetMultiParamEntries SET expansion path. A key containing a backtick can terminate identifier quoting, allowing subsequent key content to be interpreted as SQL.
What can successful exploitation do?
Exploitation can update database columns that the application did not intend to expose and append arbitrary SQL. Any appended SQL executes with the privileges of the database user used by the application.
What should be done if upgrading cannot happen immediately?
Disable permitSetMultiParamEntries and avoid passing untrusted object keys into SET-clause expansion. Keeping the option disabled uses serialized-object handling, which is not affected by this issue.
Which versions contain fixes?
Fixed versions are 3.2.5, 3.3.4, 3.4.7, and 3.5.4.