CVE-2026-33468
SQL Injection in Kysely SQL Builder via Improper String Sanitization
Publication date: 2026-03-26
Last updated on: 2026-03-31
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| kysely | kysely | to 0.28.14 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in Kysely (versions up to 0.28.13) is a SQL Injection issue that occurs when using the MySQL dialect. The problem lies in the method `DefaultQueryCompiler.sanitizeStringLiteral()`, which escapes single quotes by doubling them but does not escape backslashes. Since MySQL treats backslashes as escape characters by default, an attacker can use a backslash to escape the trailing quote of a string literal, breaking out of the string context and injecting arbitrary SQL code.
This affects code paths that inline values using `ImmediateValueTransformer`, specifically methods like `CreateIndexBuilder.where()` and `CreateViewBuilder.as()`. The MySQL-specific compiler inherits this flawed method without properly handling backslashes, allowing malicious input to manipulate SQL queries.
How can this vulnerability impact me? :
This vulnerability can lead to arbitrary SQL injection, allowing attackers to execute unintended SQL commands. Potential impacts include:
- Exfiltration of sensitive data via UNION queries or subqueries.
- Modification or destruction of data through stacked queries.
- Possible authentication bypass if schema-building methods influenced by user input are exploited.
The attack complexity is high because it requires passing untrusted input into DDL schema builder methods, which is uncommon but feasible.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by analyzing the usage of the Kysely npm package versions up to 0.28.13 in your codebase, specifically looking for usage of the MySQL dialect with methods that inline values using ImmediateValueTransformer, such as CreateIndexBuilder.where() and CreateViewBuilder.as().
Detection can involve reviewing SQL queries generated by these methods for improper escaping of backslashes in string literals, which may allow SQL injection.
While no specific commands are provided in the resources, you can search your code for vulnerable versions and usage patterns with commands like:
- Check installed Kysely version: `npm list kysely` or `yarn list kysely`
- Search for usage of vulnerable methods in code: `grep -rE 'CreateIndexBuilder\.where|CreateViewBuilder\.as' ./src`
- Monitor SQL queries for suspicious patterns involving backslashes escaping quotes, which might require enabling query logging in MySQL and inspecting logs.
What immediate steps should I take to mitigate this vulnerability?
The immediate and recommended step to mitigate this vulnerability is to upgrade the Kysely package to version 0.28.14 or later, where the issue is fixed by properly escaping backslashes in the sanitizeStringLiteral() method.
Alternatively, avoid passing untrusted input into DDL schema builder methods like CreateIndexBuilder.where() and CreateViewBuilder.as() that inline values, or use parameterized queries where supported to prevent SQL injection.
Review your codebase for any usage of vulnerable Kysely versions and replace or refactor those parts to use safe query building practices.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows arbitrary SQL injection, which can lead to unauthorized data exfiltration, modification, or destruction. Such impacts can compromise the confidentiality, integrity, and availability of sensitive data.
This can affect compliance with common standards and regulations like GDPR and HIPAA, which require protection of sensitive personal and health data against unauthorized access and breaches.
Exploitation of this vulnerability could result in data breaches or unauthorized data manipulation, potentially leading to violations of these regulations and associated legal and financial consequences.