github.com/corazawaf/coraza/v3: Coraza JSON body processor: argument-limit truncation reopens an unbounded-depth gjson.Valid stack overflow (process crash)

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:

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):

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

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.