GHSA-6wcc-39rp-hh9p

A SQL injection vulnerability exists in the escapeValue() function used for parameter substitution. escapeValue() dispatches on the type of the parameter value, and two of its branches failed to escape safely. An attacker who can control a parameter value can terminate the enclosing string literal and have the rest of the value parsed as SQL.

Vector 1 - string parameters. Fixed in 2.0.2. The string branch escaped ' as '' but left \\ untouched. ClickHouse honours C-style backslash escapes as well as SQL-standard quote doubling, so a value ending in an odd number of backslashes escapes the closing quote and the next parameter lands outside the literal:

where('a', 'eq', 'x\\')          ->   WHERE a = 'x\\' AND b = ' OR 1=1 --'

Vector 2 - object and array parameters. Fixed in 2.5.1, NOT in 2.0.2. The final branch of the same function rendered non-scalar values as `'${JSON.stringify(value)}'` with no escaping at all. JSON has no reason to escape the apostrophe, so any nested string containing ' terminates the literal:

where('meta', 'eq', { k: \"x' OR 1=1 -- \" })
                                ->   WHERE meta = '{\"k\":\"x' OR 1=1 -- \"}'

The 2.0.2 patch changed only the string branch and did not address this. Vector 2 remained exploitable in 2.0.2, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.3.0, 2.4.0 and 2.5.0 - every release this advisory previously reported as patched.

Who is impacted. Any application on a version below 2.5.1 that passes user-controlled input as a query parameter. Both vectors are reachable through the documented public API: .where(column, operator, value), the in operator, and adapter.render() / rawQuery().

Schema type declarations do not mitigate vector 2. createQueryBuilder().table() builds its state with an empty column map, so the filter validator has no declared type to check against and returns without validating. Even where a schema is supplied, only String, Int32,...