Summary
OpenPanel before 3.0.0 contains an SQL injection vulnerability in the ClickHouse-backed live visitors WebSocket and related cohort preview handling. An unauthenticated remote attacker, or a project member in the cohort preview context, may manipulate query inputs to read events and profiles belonging to other tenants.
OpenPanel before 3.0.0 contains an SQL injection vulnerability in the ClickHouse-backed live visitors WebSocket and related cohort preview handling. An unauthenticated remote attacker, or a project member in the cohort preview context, may manipulate query inputs to read events and profiles belonging to other tenants.
Affected context
The vulnerability affects OpenPanel deployments using the live visitors WebSocket endpoint with a project identifier supplied through the request path. Risk is increased when the endpoint does not enforce session validation and project-access checks before constructing ClickHouse queries. Similar query-manipulation exposure may exist in cohort preview functionality when timeframe values are incorporated without adequate validation or parameterization.
The vulnerability affects OpenPanel deployments using the live visitors WebSocket endpoint with a project identifier supplied through the request path. Risk is increased when the endpoint does not enforce session validation and project-access checks before constructing ClickHouse queries. Similar query-manipulation exposure may exist in cohort preview functionality when timeframe values are incorporated without adequate validation or parameterization.
Exploit preconditions
- Attack surface: The
/live/visitors/:projectIdWebSocket and cohort preview request handling. - Required access: The live visitors path may be reachable without authentication; cohort preview exploitation may require project-member access.
- Trigger point: Processing the
projectIdparameter or cohort preview timeframe values during ClickHouse query construction. - Why exploitation is possible: Request-controlled values can influence SQL expressions without sufficient parameterization, while session and project-authorization checks may be absent or incomplete.
- Attack surface: The
/live/visitors/:projectIdWebSocket and cohort preview request handling. - Required access: The live visitors path may be reachable without authentication; cohort preview exploitation may require project-member access.
- Trigger point: Processing the
projectIdparameter or cohort preview timeframe values during ClickHouse query construction. - Why exploitation is possible: Request-controlled values can influence SQL expressions without sufficient parameterization, while session and project-authorization checks may be absent or incomplete.
Why this happens
The underlying flaw is the construction of ClickHouse SQL statements from attacker-influenced request values without reliably separating data from query syntax. This is CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection. Missing authentication and tenant-boundary checks increase the exposure and potential scope, but the core defect is unsafe query construction and insufficient input validation.
The underlying flaw is the construction of ClickHouse SQL statements from attacker-influenced request values without reliably separating data from query syntax. This is CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection. Missing authentication and tenant-boundary checks increase the exposure and potential scope, but the core defect is unsafe query construction and insufficient input validation.
Potential impact
- Attackers may read events, profiles, or other queryable tenant data.
- Cross-tenant information disclosure could occur.
- Boolean or aggregate query behavior may reveal database contents through response differences.
- Sensitive operational, behavioral, or customer data may be exposed.
- Database resources could be abused through expensive or unexpected queries.
- Attackers may read events, profiles, or other queryable tenant data.
- Cross-tenant information disclosure could occur.
- Boolean or aggregate query behavior may reveal database contents through response differences.
- Sensitive operational, behavioral, or customer data may be exposed.
- Database resources could be abused through expensive or unexpected queries.
General mitigation guidance
Mitigation generally focuses on eliminating string-built SQL and enforcing authorization before query execution.
Common defensive patterns include:
- Use parameterized ClickHouse queries or structured query APIs that keep values separate from SQL syntax.
- Apply strict allowlist validation for project identifiers, timeframe values, and other query parameters.
- Enforce authentication and project-level authorization at the WebSocket handshake and request-processing layers.
- Bind every query to the authenticated tenant and verify access independently of client-supplied identifiers.
- Return uniform, minimal error responses and avoid exposing query details or data outside the authorized scope.
- Run database credentials with least privilege and restrict access to only the required datasets and operations.
Mitigation generally focuses on eliminating string-built SQL and enforcing authorization before query execution.
Common defensive patterns include:
- Use parameterized ClickHouse queries or structured query APIs that keep values separate from SQL syntax.
- Apply strict allowlist validation for project identifiers, timeframe values, and other query parameters.
- Enforce authentication and project-level authorization at the WebSocket handshake and request-processing layers.
- Bind every query to the authenticated tenant and verify access independently of client-supplied identifiers.
- Return uniform, minimal error responses and avoid exposing query details or data outside the authorized scope.
- Run database credentials with least privilege and restrict access to only the required datasets and operations.
How teams detect issues like this
Detection can combine source review, runtime monitoring, and policy enforcement:
- Use static analysis to identify SQL strings assembled with request parameters or interpolation.
- Review WebSocket handlers and cohort-preview code for missing authentication, authorization, and tenant checks.
- Flag database calls that accept raw client-controlled identifiers or timeframe expressions.
- Monitor ClickHouse query logs for unexpected syntax, anomalous predicate behavior, cross-tenant access patterns, and unusual query volume.
- Add automated tests that verify parameterization, authorization boundaries, and consistent responses for invalid inputs.
- Security-focused code review tools may help identify injection sinks and missing access-control checks.
Detection can combine source review, runtime monitoring, and policy enforcement:
- Use static analysis to identify SQL strings assembled with request parameters or interpolation.
- Review WebSocket handlers and cohort-preview code for missing authentication, authorization, and tenant checks.
- Flag database calls that accept raw client-controlled identifiers or timeframe expressions.
- Monitor ClickHouse query logs for unexpected syntax, anomalous predicate behavior, cross-tenant access patterns, and unusual query volume.
- Add automated tests that verify parameterization, authorization boundaries, and consistent responses for invalid inputs.
- Security-focused code review tools may help identify injection sinks and missing access-control checks.
