critical · 9.8CVE-2026-54658Jul 28, 2026

CVE-2026-54658: @hypequery/clickhouse SQL Injection via Backslash Escape Bypass

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A flaw in the query builder's value-escaping logic lets an attacker supply a trailing backslash to break out of a quoted SQL string and run arbitrary ClickHouse SQL.

Package@hypequery/clickhouse
Ecosystemnpm
Affected< 2.0.2
Fixed in2.0.2
CVE-2026-54658: @hypequery/clickhouse SQL Injection via Backslash Escape Bypass

The problem

The escapeValue() function in @hypequery/clickhouse escaped single quotes by prefixing them with a backslash, but never escaped backslashes first. Any user-controlled value passed to .where() or similar methods was therefore injectable.

An attacker who can influence a query parameter value can break out of the SQL string literal, append arbitrary clauses, and read or manipulate any data the ClickHouse user can reach. No authentication or special role is required beyond the ability to supply a query parameter.

Proof of concept

A working proof-of-concept for CVE-2026-54658 in @hypequery/clickhouse, with the exact payload below.

javascript
// Attacker-controlled value passed as a query parameter:
// Trailing \ causes escapeValue() to produce: 'foo\' OR 1=1 --'
// ClickHouse parses the \ as escaping the closing quote,
// so the string closes at the injected quote and OR 1=1 executes.

db.table('users')
  .where('name', 'eq', "foo\\' OR 1=1 --")
  .execute();

// Resulting (vulnerable) SQL:
// ... WHERE name = 'foo\' OR 1=1 --'
//   -> string closes after foo\, then OR 1=1 runs unconditionally

The root cause is the wrong order of operations in string escaping. escapeValue() ran .replace(/'/g, "\\'") without first running .replace(/\\/g, "\\\\") to neutralize existing backslashes. A trailing \ in attacker input became the escape character for the very quote the function added, turning \' into a literal backslash followed by an unescaped closing quote.

The patch in commit 4dfa9d77 added the backslash-escape step first, so a literal \ in user input is doubled to \\ before any quote escaping happens. The injected \ can no longer consume the protective quote. This is CWE-89, and the same class of bypass that historically affected PHP's addslashes() against MySQL.

The fix

Upgrade to @hypequery/clickhouse version **2.0.2** or later. The fix (commit 4dfa9d77d70a08b970e722268b75ca7d13db0bdf) adds backslash escaping before single-quote escaping inside escapeValue(). No workaround exists for older versions; manual input sanitization is not a reliable substitute.

Reporter not attributed.

References: [1][2][3][4][5]

Related research