GHSA-3c6w-j9xm-8h2h

### Summary The JSON response body processor parses response bodies with no recursion limit. `ProcessResponse` calls `readJSON(ss, ignoreJSONRecursionLimit)`, and that constant is `-1`. The guard in `readItems` only fires on `== 0`, so counting down from `-1` (-2, -3, ...) never reaches it. The guard is effectively dead on the response path. The request path is fine: `ProcessRequest` passes the configured limit (default 1024). There is no equivalent directive or default for responses. Parsing a deeply nested JSON response is CPU-bound and its cost grows quadratically with nesting depth. A 512 KiB response (the default `ResponseBodyLimit`) holds about 87,000 nesting levels and takes ~12 s to process, keeping one core busy the whole time. ### Root cause `internal/bodyprocessors/json.go` ```go const ignoreJSONRecursionLimit = -1 // line 51 func (js *jsonBodyProcessor) ProcessResponse(reader io.Reader, v ..., _ plugintypes.BodyProcessorOptions) error { ... data, err := readJSON(ss, ignoreJSONRecursionLimit) // line 62, passes -1 } func (js *jsonBodyProcessor) ProcessRequest(...) error { ... data, err := readJSON(ss, bpo.RequestBodyRecursionLimit) // line 32, default 1024 } ``` The guard and the decrement: ```go func readItems(json gjson.Result, objKey []byte, maxRecursion int, res map[string]string) error { if maxRecursion == 0 { // line 106 return errors.New("max recursion reached while reading json object") } ... iterationError = readItems(value, objKey, maxRecursion-1, res) // line 126 ``` Note that `ProcessResponse` discards `BodyProcessorOptions` (the parameter is `_`), so even a caller that wanted to set a limit on responses has no way to. ### Why the cost is quadratic Every nesting level re-parses the remaining nested document through `gjson.ForEach`, so total work is O(n²) in the depth. Numbers below were measured on an Intel Core Ultra 7 255H, Go 1.22.2, gjson v