CVE-2026-44172 is a critical SQL injection issue (CVSS 9.1) in libmariadb, the MariaDB client library. With the big5 character set, escaping input with mysql_real_escape_string can fail to prevent injection. Upgrade to 3.3.19 or 3.4.9 as soon as you can, or switch the affected code paths to prepared statements.
What's affected
From the project advisory for libmariadb:
- 3.3.1 to 3.3.18, fixed in 3.3.19
- 3.4.1 to 3.4.8, fixed in 3.4.9
The record text names 3.3.18 and 3.4.8 as the vulnerable versions, while the advisory gives the wider ranges above. Use the advisory ranges.
An application is exposed only if it builds queries as text by escaping input with mysql_real_escape_string, uses the text protocol, and runs the connection with the big5 character set. The record also lists Red Hat Enterprise Linux as an affected product, so vendor packages that bundle the library may carry their own fixes.
How to check if you're exposed
Find which copy of the client library your software uses:
ldconfig -p | grep -i mariadb
rpm -q mariadb-connector-c 2>/dev/null
dpkg -l | grep -i libmariadb
Then search your code for the pattern the advisory describes: calls to mysql_real_escape_string that build query text, and any code that sets the connection character set to big5. Statically linked applications and language drivers that bundle the library need their own check.
What to do now
- Upgrade libmariadb to 3.3.19 or 3.4.9, and update any application or driver that bundles its own copy.
- Move queries to prepared statements with bound parameters. The project says this is always preferable to escaping and string building.
- If you cannot upgrade yet, the advisory lists switching the connection to the gbk character set as a workaround. Test your application before relying on it.
- Check your vendor notices if you use a distribution package, as the record links several Red Hat errata.
Why it matters
The class is CWE-89 (SQL injection). Escaping functions work by adding a backslash before dangerous characters. In multibyte character sets such as big5, some byte sequences make the escaping step and the server disagree about where a character begins and ends, and the escape can be absorbed into a character instead of protecting the quote.
This is the old lesson behind prepared statements. Escaping depends on the client and server sharing the same view of the character set, and bound parameters do not.
The record does not mark this CVE as KEV. The conditions are narrow, but the attack needs no login, and any internet facing application that matches them is worth patching quickly.
Quick check
Do prepared statements avoid this issue?
The advisory says they are the preferable general solution, because user input never becomes part of the query text.
Does this affect only big5?
The advisory describes big5 and offers gbk as a workaround. Check the project advisory for any later notes.
Sources
Last reviewed: 19 October 2026.
