Area: query · api — security (DoS, missing server-side enforcement) · found via pre-launch audit
Expected: the policy's max_execution_time_ms (and an implicit row/memory budget) is enforced by ClickHouse server-side, so a query can't outrun it during a server-side scan/merge/aggregation phase.
Actual: cmd/wavehouse/main.go:151 clickhouse.Open(&clickhouse.Options{...}) passes no Settings map, so no max_execution_time / max_memory_usage / max_rows_to_read / max_result_rows ever reaches CH. The only budget a public query gets is a Go context.WithTimeout (min(MaxExecutionTimeMs=3000, query_timeout)), which (a) cancels only while the client goroutine is in the block-read loop — a long server-side aggregation phase runs to completion first — and (b) bounds neither memory nor rows read server-side, so a query can allocate GBs of aggregation state within the 3 s budget. Re-verified no Settings on 40619b8a.
Impact: the systemic root that makes the rest of the DoS set worse — it removes the mitigation one would assume protects the box, so the heavy-aggregation and pipe cache-bypass findings are each worse than the policy caps imply. Latent on today's tiny corpus; grows directly with table size.
Scope: pass per-query CH Settings derived from the role's caps.
Related: #232 (per-role lookback), epic(security) DoS / resource-exhaustion hardening, the pipe cache-bypass issue.
From WaveHouse-Stats pre-launch security audit (WAVEHOUSE-FEEDBACK.md dogfooding), audited dev 60fed15 / DoS-pass 0b62271; re-verified live on 40619b8a (2026-06-10). Full repro: WAVEHOUSE-CRASH-REPORT.md (private, R1). Filed via /pm-triage.
Area: query · api — security (DoS, missing server-side enforcement) · found via pre-launch audit
Expected: the policy's
max_execution_time_ms(and an implicit row/memory budget) is enforced by ClickHouse server-side, so a query can't outrun it during a server-side scan/merge/aggregation phase.Actual:
cmd/wavehouse/main.go:151clickhouse.Open(&clickhouse.Options{...})passes noSettingsmap, so nomax_execution_time/max_memory_usage/max_rows_to_read/max_result_rowsever reaches CH. The only budget a public query gets is a Gocontext.WithTimeout(min(MaxExecutionTimeMs=3000, query_timeout)), which (a) cancels only while the client goroutine is in the block-read loop — a long server-side aggregation phase runs to completion first — and (b) bounds neither memory nor rows read server-side, so a query can allocate GBs of aggregation state within the 3 s budget. Re-verified noSettingson40619b8a.Impact: the systemic root that makes the rest of the DoS set worse — it removes the mitigation one would assume protects the box, so the heavy-aggregation and pipe cache-bypass findings are each worse than the policy caps imply. Latent on today's tiny corpus; grows directly with table size.
Scope: pass per-query CH
Settingsderived from the role's caps.Related: #232 (per-role lookback), epic(security) DoS / resource-exhaustion hardening, the pipe cache-bypass issue.
From WaveHouse-Stats pre-launch security audit (
WAVEHOUSE-FEEDBACK.mddogfooding), audited dev60fed15/ DoS-pass0b62271; re-verified live on40619b8a(2026-06-10). Full repro:WAVEHOUSE-CRASH-REPORT.md(private, R1). Filed via /pm-triage.