CVE-2026-44172

What it actually does

This flaw allows SQL injection when an application uses MariaDB with the Big5 character set, sends SQL using the text protocol, and relies on mysql_real_escape_string() to sanitize untrusted input. A crafted multibyte Big5 byte sequence can cause the escaping routine and SQL parser to interpret bytes differently, leaving an attacker-controlled quote or SQL metacharacter active in the final query. The result is that application code believed to be safely escaped may still allow modification of SQL query structure, enabling unauthorized reads or writes depending on the privileges of the database account used by the application.

Why it matters to the business

Applications using affected MariaDB versions with Big5 text-protocol queries may be vulnerable to data tampering, unauthorized access to sensitive records, account abuse, and application compromise through database-layer manipulation. Although this issue is not currently listed in CISA KEV and has low EPSS activity at this time, the CVSS severity is high and SQL injection flaws are routinely weaponized once reliable exploit patterns become public. Organizations with multilingual applications, legacy encodings, or East Asian character-set support should treat exposure as higher priority.

How an attack unfolds

An attacker first identifies an application input that is incorporated into a MariaDB query after being escaped with mysql_real_escape_string(). If the connection or query path uses the Big5 character set and the text protocol, the attacker submits a specially crafted byte sequence containing a Big5 lead byte followed by a quote or other SQL-significant character. The escaping function inserts a backslash, but the server-side SQL parser may interpret the backslash as part of a valid Big5 multibyte character, leaving the quote effective. The attacker then appends SQL syntax such as boolean conditions, UNION queries, stacked logic where supported by the application, or data-changing clauses. Successful exploitation depends on the vulnerable application query shape and the permissions of the database user, but can lead to authentication bypass, unauthorized data access, or modification of records.

How to fix it

Upgrade affected MariaDB deployments to patched versions: 3.3.19 for the 3.3.x line or 3.4.9 for the 3.4.x line. If vendor packaging uses different version labels, apply the MariaDB package update that includes the fix for this issue. In addition, do not rely on mysql_real_escape_string() as the primary SQL injection defense for untrusted input; migrate application code to parameterized queries/prepared statements with bound parameters. Where immediate upgrade is not possible, avoid Big5 for client connections handling untrusted input, enforce a safer and consistent connection character set such as utf8mb4 where compatible, disable or refactor risky text-protocol dynamic SQL paths, and restrict database account privileges to the minimum required. Review application code for manual SQL string concatenation, especially in authentication, search, reporting, administrative, and import/export features.

How to confirm the fix worked

Confirm installed MariaDB server and client library/package versions are at or above 3.3.19 or 3.4.9, as applicable. Verify application database connections are not using Big5 unless explicitly required by business functionality. Inspect application code to ensure untrusted input is passed through prepared statements rather than concatenated into SQL strings after mysql_real_escape_string(). In test environments, use regression tests with Big5-encoded quote-breaking payloads to confirm that inputs remain data values and cannot alter SQL syntax. Review database session settings such as character_set_client, character_set_connection, and character_set_results for Big5 usage on application connections.

Typical attack path

1. Find an application endpoint that accepts user-controlled input and sends it to MariaDB.
2. Confirm or infer that the application uses a Big5 client character set and text-protocol SQL execution.
3. Send malformed or crafted Big5-encoded input containing quote-breaking byte sequences.
4. Observe SQL behavior changes, error messages, timing differences, or authentication/query bypass results.
5. Refine the payload to alter WHERE clauses, extract data, or change database records.
6. Use the application database account’s privileges to access or manipulate reachable data.

How to detect it

To determine whether exploitation has already occurred, review web, API gateway, WAF, application, and database logs for suspicious requests containing URL-encoded high-bit bytes followed by quotes, SQL comments, UNION clauses, boolean tautologies, or timing functions. Focus on endpoints that perform login, search, filtering, reporting, profile updates, order lookup, administrative actions, or other database-backed operations. Inspect MariaDB general query logs, audit logs, slow query logs, and application SQL debug logs for unexpected query structure, malformed Big5 characters, unexplained quote characters, UNION SELECT patterns, OR-based tautologies, SLEEP/BENCHMARK timing probes, or sudden use of character-set statements. Also review application configuration and connection initialization logs for Big5 usage, including SET NAMES big5 or character_set_client=big5. Correlate suspicious requests with database changes, authentication anomalies, unexpected data exports, new administrative users, modified records, or unusual query volume from a single source. There are no known named threat actors or confirmed widespread exploitation campaigns from the supplied intelligence, so detection should emphasize generic SQL injection behavior and Big5-specific payload patterns.

• SET NAMES big5
• CHARACTER SET big5
• character_set_client=big5
• character_set_connection=big5
• COLLATE big5
• mysql_real_escape_string
• %bf%27
• %BF%27
• %a1%27
• %A1%27
• %df%27
• %DF%27
• %bf%5c%27
• %BF%5C%27
• %a1%5c%27
• %A1%5C%27
• ' OR '1'='1
• " OR "1"="1
• UNION SELECT
• UNION ALL SELECT
• SLEEP(
• BENCHMARK(
• --
• #
• /*

What your security team should do

• Prioritize inventory of MariaDB deployments and identify any running affected 3.3.18 or 3.4.8 versions.
• Patch to MariaDB 3.3.19 or 3.4.9, or the corresponding fixed vendor package, especially for internet-facing or high-value applications.
• Search application repositories for mysql_real_escape_string(), manual SQL concatenation, SET NAMES big5, and Big5 connection configuration.
• Require parameterized queries for all database access paths that process user-controlled input.
• Temporarily disable Big5 client character set usage for untrusted input paths if patching or code changes cannot be completed immediately.
• Enable or tune application, web, and database logging to capture suspicious SQL injection probes and character-set manipulation attempts.
• Review database account privileges used by applications and remove unnecessary write, administrative, file, or schema privileges.
• Because the issue is not currently KEV-listed and EPSS is low, use risk-based prioritization, but do not defer remediation for applications that use Big5 or legacy SQL escaping patterns.