The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 6, 2026 12:50am

PR Summary

Medium Risk
Changes security-sensitive ClickHouse query and mutation WHERE handling; mis-tuned regex could block legitimate filters or miss edge-case tautologies despite server readonly.

Overview
Hardens the ClickHouse Query operation and shared mutation WHERE validation.

For read-only queries, HTTP requests now pass ClickHouse readonly=1 when enforceReadOnly is set, so the server blocks writes/DDL (existing client-side SQL-shape checks stay as defense-in-depth). ClickHouse update/delete/count WHERE checks no longer use a local denylist; they call new validateSqlWhereClause in input-validation.server.ts.

That helper masks quoted literals before pattern scans (fewer false positives on values like 'OR 1'), blocks standalone OR <truthy> tautologies (e.g. status = 'active' OR 1), and documents that this layer is not a full security boundary.

^{Reviewed by Cursor Bugbot for commit 327ee96. Configure here.}

Greptile Summary

This PR hardens the ClickHouse integration's read-only boundary and centralizes WHERE-clause validation. Server-side readonly=1 is now passed as a ClickHouse HTTP query parameter for the Query operation, ensuring the server rejects writes or DDL regardless of SQL-shape checks. WHERE-clause guard logic is moved from an inline denylist in utils.ts into a new shared validateSqlWhereClause export in input-validation.server.ts, which adds string-literal masking before pattern matching to prevent false positives on quoted values that look like injection patterns.

• readonly=1 enforcement: Threaded through clickhouseRequest via a new readOnly option; executeClickHouseQuery passes enforceReadOnly → readOnly so ClickHouse itself rejects writes — SQL-shape checks become defense-in-depth.
• Centralized WHERE validation: validateSqlWhereClause replaces the per-call denylist with masked-pattern matching, catching bare truthy-literal tautologies (OR 1, OR 42) while correctly passing BETWEEN … AND <n> range filters and quoted string values that resemble injection patterns.

Confidence Score: 5/5

Safe to merge — the changes add a genuine server-side enforcement layer and centralize an existing guard without regressing any current validation path.

Both changed files make narrowly scoped, additive security improvements. The readonly=1 enforcement is correctly threaded through only the query operation and has no effect on the write/DDL helpers. The new validateSqlWhereClause preserves all previously blocked patterns while fixing the BETWEEN … AND false positive and adding masking to avoid false positives on quoted values. No mutation path loses a guard.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[executeClickHouseQuery] -->|enforceReadOnly=true| B{SQL shape checks}
    B -->|pass| C[clickhouseRequest\nreadOnly: true]
    B -->|fail| D[throw Error]
    C -->|readonly=1 in URL| E[(ClickHouse Server)]
    E -->|rejects write/DDL| F[Server-enforced boundary]

    G[executeClickHouseUpdate\nexecuteClickHouseDelete\nexecuteClickHouseCountRows] --> H[validateWhereClause]
    H --> I[validateSqlWhereClause\nin input-validation.server.ts]
    I --> J[maskSqlStringLiterals\nreplace string contents with spaces]
    J --> K{SQL_WHERE_MASKED_PATTERNS\nOR 1, stacked stmts, tautologies}
    K -->|match| L[return isValid: false]
    K -->|no match| M{SQL_WHERE_RAW_PATTERNS\n'a'='a' identical strings}
    M -->|match| L
    M -->|no match| N[return isValid: true]

_{Reviews (2): Last reviewed commit: "fix(clickhouse): allow BETWEEN bounds in..." | Re-trigger Greptile}

@greptile

@cursor review