Summary
A SQL injection vulnerability in MariaDB Connector/Node.js can affect applications that enable permitSetMultiParamEntries and accept attacker-controlled object keys. A malicious key may alter unintended columns or append SQL executed with the database account's privileges.
A SQL injection vulnerability in MariaDB Connector/Node.js can affect applications that enable permitSetMultiParamEntries and accept attacker-controlled object keys. A malicious key may alter unintended columns or append SQL executed with the database account's privileges.
Affected context
The vulnerability occurs in applications using MariaDB Connector/Node.js versions within the affected release ranges when permitSetMultiParamEntries is enabled. Object keys supplied through the relevant parameter-handling path are expanded into a SQL SET clause without being safely processed as identifiers. The default-disabled option and serialized-object handling used when it remains disabled are not affected.
The vulnerability occurs in applications using MariaDB Connector/Node.js versions within the affected release ranges when permitSetMultiParamEntries is enabled. Object keys supplied through the relevant parameter-handling path are expanded into a SQL SET clause without being safely processed as identifiers. The default-disabled option and serialized-object handling used when it remains disabled are not affected.
Exploit preconditions
- Attack surface: Application functionality that constructs database updates from object parameters
- Required access: Ability to influence object keys reaching the connector
- Trigger point: Expansion of object keys into a SQL
SETclause - Why exploitation is possible: Identifier keys are not escaped before being incorporated into generated SQL, allowing SQL syntax to escape the intended identifier context
- Attack surface: Application functionality that constructs database updates from object parameters
- Required access: Ability to influence object keys reaching the connector
- Trigger point: Expansion of object keys into a SQL
SETclause - Why exploitation is possible: Identifier keys are not escaped before being incorporated into generated SQL, allowing SQL syntax to escape the intended identifier context
Why this happens
The underlying issue is improper neutralization of user-controlled input used in SQL construction, mapping to CWE-89: SQL Injection. When object keys are expanded into a SET clause without identifier escaping, delimiter characters can terminate the intended quoted identifier and cause additional text to be interpreted as SQL. The insecure pattern is treating externally influenced object property names as trusted SQL identifiers rather than validating or safely encoding them.
The underlying issue is improper neutralization of user-controlled input used in SQL construction, mapping to CWE-89: SQL Injection. When object keys are expanded into a SET clause without identifier escaping, delimiter characters can terminate the intended quoted identifier and cause additional text to be interpreted as SQL. The insecure pattern is treating externally influenced object property names as trusted SQL identifiers rather than validating or safely encoding them.
Potential impact
- An attacker may modify columns the application did not intend to expose.
- Arbitrary SQL may be executed with the database user's privileges.
- Application data could be altered, deleted, or corrupted.
- Confidential database information could be disclosed.
- Database integrity and dependent application workflows could be disrupted.
- An attacker may modify columns the application did not intend to expose.
- Arbitrary SQL may be executed with the database user's privileges.
- Application data could be altered, deleted, or corrupted.
- Confidential database information could be disclosed.
- Database integrity and dependent application workflows could be disrupted.
General mitigation guidance
Mitigation generally focuses on preventing untrusted object keys from becoming SQL syntax.
Common defensive patterns include:
- Keep multi-parameter object expansion disabled unless the feature is explicitly required.
- Use parameterized values and allowlisted, application-defined column names.
- Apply dedicated identifier escaping or structured query builders for dynamic identifiers.
- Reject unexpected keys before they reach database query construction.
- Limit database accounts to the minimum permissions required by the application.
- Treat client-controlled object structure as untrusted input, even when values are parameterized.
Mitigation generally focuses on preventing untrusted object keys from becoming SQL syntax.
Common defensive patterns include:
- Keep multi-parameter object expansion disabled unless the feature is explicitly required.
- Use parameterized values and allowlisted, application-defined column names.
- Apply dedicated identifier escaping or structured query builders for dynamic identifiers.
- Reject unexpected keys before they reach database query construction.
- Limit database accounts to the minimum permissions required by the application.
- Treat client-controlled object structure as untrusted input, even when values are parameterized.
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis rules identifying dynamic object keys used in SQL query construction.
- Code review checks for connector options that enable object-to-
SETexpansion. - Tests that verify unexpected identifiers and SQL metacharacters cannot alter generated statements.
- Database audit logging for unusual updates, schema targets, or statements issued by application accounts.
- Policy enforcement requiring allowlisted column mappings and least-privilege database roles.
Automated code review and dependency-analysis tools may help identify risky query-building patterns.
Organizations can look for this issue through:
- Static analysis rules identifying dynamic object keys used in SQL query construction.
- Code review checks for connector options that enable object-to-
SETexpansion. - Tests that verify unexpected identifiers and SQL metacharacters cannot alter generated statements.
- Database audit logging for unusual updates, schema targets, or statements issued by application accounts.
- Policy enforcement requiring allowlisted column mappings and least-privilege database roles.
Automated code review and dependency-analysis tools may help identify risky query-building patterns.
