Two lines of code were enough to undermine years of carefully built database security. That is exactly what happened with the official MariaDB Connector/Node.js: in early October 2026, two separate MariaDB SQL injection vulnerabilities became public, rooted deep in how the driver handles text-protocol requests and SET statements. For Node.js and PHP teams running MySQL or MariaDB in the backend, this is not a theoretical risk but a concrete review task for the coming week.
If you want to go deeper into backend fundamentals like PHP, Node.js and MySQL, check out our foundational guide PHP, Node.js and MySQL Compared (German original, linked here as the most relevant existing resource).
Both vulnerabilities were registered as CVEs between October 7 and 9, 2026, and publicly analyzed on October 8 and 9, 2026. They were reported by security researcher fg0x0 via JIRA tickets CONJS-368 and CONJS-369. The good news upfront: fixes have existed since August 7, 2026, via release 3.2.5 — the vulnerabilities were simply documented publicly only afterward.
Table of Contents
What Happened: Two MariaDB SQL Injection Vulnerabilities at a Glance
Key Takeaways
- CVE-2026-107385 (CVSS 7.4) affects backslash escaping in the text protocol when the server runs in NO_BACKSLASH_ESCAPES mode.
- CVE-2026-107384 (CVSS 8.1) results from insufficient sanitization of object keys when the permitSetMultiParamEntries option is enabled.
- Primarily affected are Connection.escape() and raw text-protocol queries — the binary-protocol methods execute() and batch() are not affected by CVE-2026-107385.
- Fixed in mariadb-connector-nodejs 3.2.5, 3.3.4, 3.4.7 and 3.5.4; a third, related vulnerability (CONJS-358) concerning memory exhaustion before authentication was also fixed in the same release.
- No active exploit known (as of October 9, 2026); EPSS for CVE-2026-107385 is only 0.44 percent — action is still warranted, since high-severity vulnerabilities typically get exploited eventually.
MariaDB Connector/Node.js is the official driver maintained by MariaDB Corporation that lets Node.js applications talk to MariaDB and MySQL databases. Because it sits so deep in the application layer, any vulnerability in the driver directly affects every application that uses it — regardless of how carefully the application’s own code was written. In October 2026, two independent ways for attackers to trigger SQL injection via driver behavior became known. Both fall under CWE-89 (SQL Injection) and carry a CVSS 3.1 rating of “High”.
| Identifier | CVSS 3.1 | Cause | Affected API |
|---|---|---|---|
| CVE-2026-107385 | 7.4 (High) | Backslash escaping ignores NO_BACKSLASH_ESCAPES | Connection.escape(), text-protocol queries |
| CVE-2026-107384 | 8.1 (High) | Unsanitized object keys during SET expansion | permitSetMultiParamEntries option |
Both issues share a common lesson: escaping logic that assumes a fixed server state regardless of reality is a false sense of security. A driver that assumes the server always behaves the same way can be undermined by a single server-side configuration change.
CVE-2026-107385: When Backslash Escaping Becomes a Trap
CVE-2026-107385 strikes at the core of SQL string escaping: marking quote characters inside text values. By default, MariaDB Connector/Node.js always escapes quote characters in the text protocol with a backslash — the classic MySQL convention. The problem: the driver never checks whether the current database session actually operates in backslash mode at all.
MariaDB and MySQL support an alternative SQL mode called NO_BACKSLASH_ESCAPES. When this mode is active — whether set server-wide, through connector initialization options, or via an explicit SET sql_mode command — the backslash loses its special meaning and becomes an ordinary character. That is exactly where the vulnerability lies: the driver keeps escaping with a backslash even though the server no longer interprets it as an escape character. For attackers, this means an injected quote character is no longer neutralized by the server — it prematurely terminates the SQL string literal. From that point on, arbitrary SQL can be appended with the privileges of the application’s database connection, ranging from simple data exfiltration to destructive commands, depending on the granted database rights.
“A driver that performs escaping without knowledge of the server mode only protects you for as long as nobody changes the mode.”
Important for risk assessment: only Connection.escape() and text-protocol queries are affected — that is, classic query() calls using manually concatenated strings. The binary-protocol methods execute() and batch(), which use real placeholders, are not affected by this specific vulnerability.
CVE-2026-107384: Backtick Injection via permitSetMultiParamEntries
The second vulnerability, CVE-2026-107384, is rated even higher with a CVSS score of 8.1. It affects the connector option permitSetMultiParamEntries. This option lets you efficiently expand multiple parameters within a single SET statement — handy for batch updates or dynamically generated assignments.
The problem lies in identifier handling: when the connector processes object keys as part of SET expansion, it fails to sanitize them correctly. Object keys are normally marked in SQL with backticks (`) to distinguish them from regular values. Without proper sanitization of these keys, an attacker can deliberately inject backticks into the key values and thereby completely bypass identifier escaping. The result: additional SQL commands can be appended directly to the original statement. Because SET statements are frequently used alongside UPDATE operations on production-relevant data, the potential damage here is especially high — which explains the higher CVSS rating compared to CVE-2026-107385.
This vulnerability is relevant exclusively to applications that actively use permitSetMultiParamEntries. Projects that never set this option are not directly affected by CVE-2026-107384 — but should still check whether it was accidentally enabled through framework defaults.
The Third Issue: Memory Exhaustion Before Authentication
In the same release 3.2.5 that closes both SQL injection vulnerabilities, a third, related vulnerability was also fixed: CONJS-358. This one is not about SQL injection but about a denial-of-service weakness at the protocol level. Specifically, the client accepted multi-part packets larger than 16 megabytes for reassembly before authentication had completed. A malicious or compromised server could exploit this weakness to exhaust the memory of the Node.js client — even before any credentials were validated.
This is especially relevant for environments where applications connect to less trusted or externally reachable database endpoints, such as multi-tenant architectures or database proxies. Even though this vulnerability did not receive a CVE number within the scope of this MariaDB SQL injection analysis, it belongs to the same patch package and should be factored into the update.
Risk Assessment: How Dangerous Is This MariaDB SQL Injection Really?
The raw CVSS scores — 7.4 and 8.1 — signal “High”, not “Critical”. That matches the assessment at the time of analysis on October 9, 2026: there is no known active exploit in the wild. The EPSS score (Exploit Prediction Scoring System) for CVE-2026-107385 stands at only 0.44 percent within 30 days — statistically a low probability of near-term mass exploitation.
Still, underestimating the urgency would be a mistake. Three reasons argue for addressing this promptly:
- Delayed exploit code is the rule, not the exception. Low EPSS values shortly after a vulnerability becomes known say little about the situation three or six months from now.
- The attack surface is easy to find. Both vulnerabilities affect standard functionality (escaping, SET expansion) already in use across many existing codebases.
- Parameterized queries are the decisive lever. Applications that consistently use execute() with real placeholders instead of raw query() calls with string concatenation significantly reduce the risk from CVE-2026-107385, since the binary protocol does not rely on the error-prone backslash escaping. Applications that manually embed user input into SQL strings and rely on Connection.escape() remain fully exposed.
In short: the MariaDB SQL injection vulnerabilities are no reason to panic, but they are a clear signal to review existing database access patterns in your own code.
Recommendations: How to Protect Your Application
The most important and effective measure is simple: update. MariaDB Corporation has provided fixes for all actively maintained branches. The table below shows which version is required depending on the branch in use:
| Branch in use | Fix version |
|---|---|
| 3.2.x | 3.2.5 |
| 3.3.x | 3.3.4 |
| 3.4.x | 3.4.7 |
| 3.5.x | 3.5.4 |
Concretely, backend teams should follow this approach:
- Check the version. Running npm ls mariadb quickly reveals which driver version is actually installed in any Node.js project — even deeply nested in dependencies.
- Perform the update. Bump the dependency to the matching fix version for the branch in use, and test existing database access, especially SET statements and escaping calls.
- Check the configuration. Verify whether permitSetMultiParamEntries is actively set in your own project — for example in the connection pool configuration or in framework defaults.
- Disable the option if an update isn’t immediately possible. As long as a patch cannot be applied, disabling permitSetMultiParamEntries at least partially mitigates the attack vector of CVE-2026-107384.
- Switch to parameterized queries. In the long run, moving from raw query() usage to execute() with placeholders reduces the structural risk of further, still-unknown escaping issues.
- Document your SQL mode. Teams running NO_BACKSLASH_ESCAPES server-side should explicitly note it in the deployment runbook so future driver updates are tested against it specifically.
These steps can be integrated into existing CI/CD pipelines: an automated check that compares npm ls mariadb against a minimum version prevents outdated driver versions from silently reaching production unnoticed.
Conclusion and Next Steps
The two MariaDB SQL injection vulnerabilities CVE-2026-107384 and CVE-2026-107385 are a clear example of how assumptions about server behavior — such as the SQL mode or correct sanitization of identifiers — can turn into concrete security vulnerabilities, even in an officially maintained, widely used database driver. Both vulnerabilities have been fixed since release 3.2.5 on August 7, 2026; the public analysis followed only in October 2026. For Node.js and PHP teams running MariaDB or MySQL, this means concretely: check your current version now with npm ls mariadb, update to 3.2.5, 3.3.4, 3.4.7, or 3.5.4, review your use of permitSetMultiParamEntries, and — independent of this specific incident — gradually move your own code toward parameterized queries using execute(). This combination of a quick patch and structural change is the most reliable way to durably reduce future SQL injection risk in your own database access.
