GHSA-6gcq-wc29-5xf2: Coraza WAF: stack overflow DoS via JSON body

### Summary The JSON body processor (`internal/bodyprocessors/json.go`) can be made to crash the whole process with an unrecoverable `fatal error: stack overflow`, using a request body that is well under the recommended `SecRequestBodyLimit` and the default `SecArgumentsLimit`. ### Root cause `readJSON` (json.go:113-143) runs a bounded, best-effort flattening walk (`readItems`) and *afterwards* calls `gjson.Valid(s)` on the raw body if `readItems` returned no error: ```go json := gjson.Parse(s) ... truncated, err = readItems(json, key, maxRecursion, argumentLimit, byteBudget, &usedBytes, &argCount, res) if err != nil { return res, truncated, err } if !gjson.Valid(s) { return res, truncated, errors.New("invalid JSON") } ``` `gjson.Valid` (gjson v1.18.0, `validany` -> `validarray`/`validobject`) recurses once per nesting level with **no depth bound**. `readItems` does have a depth bound (`maxRecursion`), enforced here (json.go:163-182): ```go func readItems(json gjson.Result, objKey []byte, maxRecursion int, argumentLimit int, byteBudget int, usedBytes *int, argCount *int, res map[string][]string) (truncated bool, err error) { if byteBudget > 0 && *usedBytes >= byteBudget { return true, nil // <-- checked first } if argumentLimit > 0 && *argCount >= argumentLimit { return true, nil // <-- checked second } ... if maxRecursion <= 0 { return false, errors.New("max recursion reached while reading json object") } ``` The byte-budget and argument-limit checks run *before* the recursion-depth check, and they short-circuit the walk with `truncated=true, err=nil` instead of recursing further. If the configured `SecArgumentsLimit` (`ArgumentLimit`, default 1000, `internal/corazawaf/waf.go:359`) is reached by earlier, shallow values in the document, `readItems` stops walking *before it ever reaches* a deeply nested tail later in the same document — so the `maxRecursion` error is never produced, `err` comes back `nil`, and `readJSON` falls through to the unconditional `gjson.Valid(s)` call on the complete raw body, including the part `readItems` never visited. This is not a new interaction with the recursion limit itself: at v3.7.0, `gjson.Valid` ran unconditionally before any recursion check at all, so a plain deeply-nested body crashed the process directly. A later fix added a depth check that returns an error before `Valid` runs for the *straightforward* case (nesting reached before any other guard fires). The argument-limit / byte-budget guards added since then (GHSA-6r3q-mjv7-xr8m, GHSA-3ww9-vw83-9w5x) reopened the same crash for the case above, because they short-circuit the walk (and therefore the recursion counter) ahead of the depth check, on both the request and response body path (`ProcessResponse` calls the same `readJSON`, json.go:57-88). Because this is `fatal error: stack overflow`, not a `panic`, it is **not** recoverable by any `recover()` in the calling goroutine — the process terminates unconditionally. ### PoC ```go package bodyprocessors import ( "strings" "testing" ) func TestStackOverflowRepro(t *testing.T) { body := "[" + strings.Repeat("1,", 1000) + strings.Repeat("[", 13_000_000) // 13,002,001 bytes total: under the recommended SecRequestBodyLimit // (13107200, coraza.conf-recommended:78) and default ArgumentLimit (1000, // internal/corazawaf/waf.go:359). _, _, _ = readJSON(body, 20, 1000) } ``` ``` $ go test -run TestStackOverflowRepro ./internal/bodyprocessors/ -v runtime: goroutine stack exceeds 1000000000-byte limit fatal error: stack overflow ... github.com/tidwall/gjson.validarray(...) .../gjson@v1.18.0/gjson.go:2584 github.com/tidwall/gjson.validany(...) .../gjson@v1.18.0/gjson.go:2499 github.com/tidwall/gjson.validarray(...) .../gjson@v1.18.0/gjson.go:2589 ... (repeats until the goroutine stack limit is hit) ``` Reproduced against commit `19b86824` (tag `v3.8.0`), both by calling `readJSON` directly and end-to-end through the recommended `coraza.conf-recommended` configuration (JSON `Content-Type`, default `SecArgumentsLimit`, recommended `SecRequestBodyLimit`). ### Impact An unauthenticated attacker who can send an HTTP request body (any endpoint protected by Coraza with the JSON body processor enabled, which is the default for `application/json`) can crash the entire host process with a single request, using a payload well within default and recommended body size and argument-count limits. There is no privilege or interaction requirement, and the crash cannot be caught or mitigated by the integrator (no `recover()` stops a stack-overflow fatal error). This is strictly worse than a CPU-exhaustion or slow-request DoS: the process must be restarted, and every in-flight request/transaction on that process is lost. ### Suggested fix Run an iterative, explicitly-bounded-depth pre-scan (or reuse `readItems`'s own recursion accounting) before calling `gjson.Valid`, and never call `gjson.Valid` on input whose nesting exceeds `maxRecursion`. The response path (`ProcessResponse`) needs the same treatment since it shares `readJSON`. ### AI involvement disclosure - **AI tools/models used:** Claude Sonnet 5 (Anthropic), via Claude Code. - **What was generated/assisted:** the initial vulnerability hypothesis and repro shape were supplied by the reporter as an existing written finding; Claude Sonnet 5 independently re-derived the root cause by reading the current source, wrote and ran a fresh PoC test against commit `19b86824` (tag `v3.8.0`), confirmed the crash and stack trace shown above, verified the default configuration values cited (`ArgumentLimit` default, `SecRequestBodyLimit` recommended value) against the current source, and drafted this advisory text. - **Review performed:** reproduced by hand by running the PoC test above with `go test -run TestStackOverflowRepro ./internal/bodyprocessors/ -v` against a clean checkout of commit `19b86824`; observed the `fatal error: stack overflow` and stack trace through `gjson.validarray`/`validany`; traced `readJSON`/`readItems` line by line to confirm the guard ordering described above; the PoC was reviewed by a human maintainer (fzipi) before submission of this advisory.

An attacker finds an LLM API gateway or model-serving endpoint protected by Coraza with the default configuration. They send one POST with Content-Type: application/json containing '[' followed by 1,000 entries of '1,' and then about 13 million '[' characters, which is under the recommended 13 MB body limit. The shallow values exhaust the argument limit, so the flattening walk stops before reaching the nested tail and never raises the recursion error. The raw body is then passed to gjson.Valid, which recurses without a depth bound until the Go runtime aborts with a fatal stack overflow. The WAF process dies, and the attacker repeats the request after each restart to keep the AI service unavailable.