Anyone know anything more about CVE-2026-40018 (Dovecot SQL Injection)?

glueckself

Hi all!

TIL about https://documentation.open-xchange.com/dovecot/security/advisories/html/2026/oxdc-adv-2026-0003.html#cve-2026-40018-mysql-multi-byte-escaping-wrong, but the page doesn't provide much infos about the vulnerability...

I couldn't find anything else about it, has anyone here any infos they can share? I'll take a binary "just shut down your mail server and wait for the patch"

Thanks!

itzsenu

cvss score is 7.4, with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. network exploitable, high attack complexity, no privileges or user interaction needed. confidentiality and integrity impact are high. no availability impact. affects dovecot pro core 2.3.0 through 3.1.5, and ce core 2.3.0 through 2.4.4. discovered 2026 04 08, credited to tipsennn via yeswehack. fix released 2026 08 26. no public exploit known. cwe is CWE 89, sql injection. the bug is in the mysql sql driver escaping path, driver_mysql_escape_string() in src/lib-sql/driver-mysql.c. the connected path uses mysql_real_escape_string(), which reads the active mysql connection charset. when the sql connection drops and reconnecting fails, the old code falls back to plain mysql_escape_string(), which does not know the charset. the old code comment even flagged the tradeoff directly: "the next query will most likely fail anyway so it shouldn't matter that much what we return here." that assumption turned out wrong. this matters with big5, gbk, sjis, cp932, and gb18030, where 0x5c can be a valid trailing byte inside a multi byte character. the multibyte mechanism itself is the known root cause class, though the exact remote exploit sequence isnt publicly documented by dovecot. the general idea: a crafted byte sequence can cause the backslash meant to escape a quote to get absorbed into the character before it instead. the quote then stays active and breaks out of the string literal. the trigger path sql connection drops, reconnect fails, escaping falls back to the charset unaware function, 0x5c gets consumed as a multi byte trailing byte, the quote stays active. as an inferred consequence of that escaping failure, attacker controlled sql can reach the mysql parser, though this is not an exploit sequence dovecot has published themselves. same escaping failure class as CVE 2006 2313, CVE 2006 2314, and CVE 2026 55855. CVE 2006 2314 is the closest match since it specifically involves 0x5c as a multi byte trailing byte. standard utf8 and utf8mb4 dont have this trailing byte issue. for dovecot, this hits the mysql sql driver, and auth paths like passdb and userdb use that same escaping path when configured for sql. the public adisory doesnt give a full component by component exploit matrix, and theres no confirmed dict quota exploit path listed either. the exact remote trigger sequence isnt published, so this trigger path comes from the known source behavior and the general mysql multi byte escaping mechanism, not a confirmed public writeup.

the fix is source level, confirmed in the actual 2.4.4 to 2.4.5 diff. the disconnected fallback branch is deleted entirely. driver_mysql_escape_string() changes signature from returning const char * to returning int with output_r/error_r out parameters. if still disconnected after the reconnect attempt, it now sets *error_r = SQL_ERRSTR_NOT_CONNECTED and returns -1, no escaping happens, no query gets built. the connected path is unchanged, still calling mysql_real_escape_string(). the vendor confirms pro 3.1.6 is the first fixed pro revision, carrying the same fix.

EDIT: Fixed some mistakes ( 13th time ). 95% confidence i got all of these from different sources, so there might be some inconsistencies or mistakes.

glueckself

Ok, so looking at the UTF-8 Wikipedia page, 0x5c (backslash) really can't be a part of a multibyte character (as all UTF-8 multibyte has a 0x80 set). I don't think that the client (=attacker) can change the charset used in the DB connection, so as long as the table uses utf8mb, this is a non-issue?
Another "mitigation" might be to make sure that the DB is not disconnected. In my case it runs on the same server, so as long as I start Dovecot after the DB it should be fine.