SQL Injection in Kysely MySQL string literal sanitization
CVE-2026-33468 is an SQL injection vulnerability in Kysely, a type-safe TypeScript SQL query builder, affecting versions prior to 0.28.14. The flaw is in DefaultQueryCompiler.sanitizeStringLiteral(), which escapes single quotes by doubling them but does not escape backslashes. In the MySQL dialect, where NO_BACKSLASH_ESCAPES is OFF by default, a crafted backslash can escape the trailing quote of a generated string literal, allowing an attacker to break out of the intended string context and inject arbitrary SQL. The issue affects code paths that inline values through ImmediateValueTransformer, specifically CreateIndexBuilder.where() and CreateViewBuilder.as().
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows arbitrary SQL injection against the backend MySQL database in affected query-construction paths. Depending on the database account privileges and application logic, this can result in unauthorized data disclosure, data modification, destructive operations, schema manipulation, or service disruption. The provided context indicates high potential impact to confidentiality, integrity, and availability.
If you can’t patch tonight, do this now.
If immediate upgrade is not possible, avoid passing untrusted input into affected Kysely code paths that inline values via ImmediateValueTransformer, particularly CreateIndexBuilder.where() and CreateViewBuilder.as(). Where feasible, avoid MySQL configurations in which backslash escaping is interpreted for string literals, and prefer safer query construction patterns that do not inline attacker-controlled values into SQL literals.
Patch, then assume compromise.
Upgrade Kysely to version 0.28.14 or later, which contains the fix for this vulnerability. Review application code that uses affected value-inlining paths, especially CreateIndexBuilder.where() and CreateViewBuilder.as(), and validate that no untrusted input is passed into generated SQL in vulnerable versions.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.