CVE-2026-55855 in Connectorinfo

Summary

by MITRE • 08/29/2026

MariaDB Connector/Node.js is used to connect applications developed on Node.js to MariaDB and MySQL databases. Prior to 3.2.4, 3.3.3, 3.4.6, and 3.5.3, MariaDB Connector/Node.js permits SQL injection when attacker-controlled Buffer parameters are escaped client-side under the big5, gbk, sjis, cp932, or gb18030 client character sets. PacketOutputStream.writeBufferEscape in lib/io/packet-output-stream.js escaped bytes without the charset-aware getMbRecognizer logic in lib/misc/charset-mb.js. The server SQL lexer runs my_ismbchar before escape processing, so an attacker-controlled lead byte can consume the inserted 0x5C backslash as a multibyte trail byte and leave the following 0x27 quote unescaped, terminating the string literal and allowing arbitrary SQL. The default utf8mb4 character set and parameters sent through the execute binary prepared-statement path are not affected. Successful exploitation can expose or modify data available to the database account. This issue is fixed in versions 3.2.4, 3.3.3, 3.4.6, and 3.5.3.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 08/29/2026

MariaDB Connector/Node.js serves as a critical bridge for Node.js applications seeking to interact with MariaDB and MySQL database systems, facilitating data exchange through various connection protocols. A significant security vulnerability was identified in versions prior to 3.2.4, 3.3.3, 3.4.6, and 3.5.3 of this connector library. The flaw resides within the client-side escaping mechanism used for SQL query construction, specifically affecting operations where attacker-controlled Buffer parameters are processed under specific multi-byte character sets including big5, gbk, sjis, cp932, and gb18030. This vulnerability is classified as a classic injection flaw resulting from improper neutralization of special elements used in an SQL command, commonly referred to as CWE-89: Improper Neutralization of Special Elements used in an SQL Command.

The technical root cause lies in the implementation of the PacketOutputStream.writeBufferEscape function located within lib/io/packet-output-stream.js. This function was responsible for escaping user-supplied data before it was transmitted to the database server. However, during this process, the connector failed to utilize the charset-aware getMbRecognizer logic found in lib/misc/charset-mb.js when handling multi-byte character sets. Consequently, the escape routine treated byte sequences incorrectly, failing to recognize that certain bytes functioned as lead or trail bytes within multibyte encodings rather than simple single-byte characters. This oversight created a discrepancy between how the client prepared the data and how the server interpreted it during SQL parsing.

The exploitation mechanism relies on the interaction between the client-side escaping logic and the server-side SQL lexer. When the MariaDB server receives the query, its SQL lexer employs the my_ismbchar function to identify multibyte character sequences before performing escape processing. An attacker can craft a payload containing specific lead bytes that, when combined with an inserted backslash (0x5C) by the client's escaping routine, form a valid multibyte trail byte sequence in the targeted character set. This causes the server to consume the backslash as part of the data rather than treating it as an escape character. As a result, any subsequent quote character (0x27), which was intended to be escaped by the preceding backslash, remains unescaped from the perspective of the SQL parser.

This failure in escaping allows the attacker to terminate the original string literal prematurely and inject arbitrary SQL commands into the query stream. Because the injection occurs at the parsing level before execution constraints are fully applied, it grants the attacker significant control over the database operations. The impact is severe, potentially allowing unauthorized data exposure or modification of records accessible by the compromised database account. This aligns with ATT&CK technique T1059: Command and Scripting Interpreter, as SQL injection effectively allows an adversary to execute commands within the context of the database engine, which can often lead further into lateral movement or privilege escalation depending on server configurations.

It is important to note that this vulnerability does not affect all usage patterns equally. The default utf8mb4 character set remains unaffected because it operates primarily as a single-byte encoding in most contexts relevant to this specific escaping logic flaw. Furthermore, parameters transmitted through the execute binary prepared-statement path are also immune to this issue, as prepared statements handle parameter binding and escaping differently at the protocol level, bypassing the flawed client-side string concatenation logic entirely.

To mitigate this risk, organizations utilizing MariaDB Connector/Node.js must upgrade immediately to version 3.2.4 or later for the 3.2 branch, version 3.3.3 or later for the 3.3 branch, version 3.4.6 or later for the 3.4 branch, and version 3.5.3 or later for the 3.5 branch. These updated versions correct the escaping logic to properly account for multi-byte character set complexities, ensuring that backslashes are correctly interpreted as escape characters regardless of the encoding context. Additionally, developers should continue to prioritize the use of prepared statements with parameterized queries wherever possible, as this approach inherently mitigates SQL injection risks by separating code from data at a fundamental level.

Responsible

GitHub M

Reservation

06/17/2026

Disclosure

08/29/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!