CVE-2026-104774: Coraza WAF jsDecode off-by-one in octal escape handling

CVE-2026-104774 · Severity: medium · CVSS 5.8 · Published 2026-10-12

Coraza WAF is a security tool that inspects web traffic to block attacks like cross-site scripting and SQL injection. A bug in how it decodes JavaScript octal escape sequences causes it to fail—attackers can encode malicious payloads using octal sequences (like \163 for 's') that the WAF cannot decode but web applications can, allowing attacks to bypass protection.

Technologies: github.com/corazawaf/coraza (Go), github.com/corazawaf/coraza/v2 (Go), github.com/corazawaf/coraza/v3 (Go). Vendors: Coraza, Go.

Quick answers

Is CVE-2026-104774 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-104774 being exploited in the wild.
How severe is CVE-2026-104774?
Medium severity, with a CVSS score of 5.8, published 12 October 2026.
Which products and versions are affected?
Coraza WAF 3.0.0 to 3.7.0; github.com/corazawaf/coraza (Go) SEMVER:introduced=0; github.com/corazawaf/coraza/v2 (Go) SEMVER:introduced=0; github.com/corazawaf/coraza/v3 (Go) >= 3.0.0, < 3.8.0, SEMVER:introduced=3.0.0,fixed=3.8.0.
Is there a fix for CVE-2026-104774?
Yes. github.com/corazawaf/coraza/v3 (Go): upgrade to 3.8.0 or later. Until then: If immediate upgrade is not possible, apply the code fix: change buf[j] = input[i+j] to buf[j] = input[i+1+j] in the octal escape branch of internal/transformations/js_decode.go, and change strconv.ParseInt to strconv.ParseUint with 16-bit width to correctly handle the full \000–\377 range.</anigation> <parameter name="timeline">[{"kind": "disclosed", "at": "2026-10-08"}, {"kind": "advisory", "at": "2026-10-08"}] Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-104774 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-104774?
Check whether you run Coraza WAF, github.com/corazawaf/coraza (Go), github.com/corazawaf/coraza/v2 (Go) or one of the others listed at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • github.com/corazawaf/coraza/v3 (Go): upgrade to 3.8.0 or later
    go get github.com/corazawaf/coraza/v3@v3.8.0

If immediate upgrade is not possible, apply the code fix: change buf[j] = input[i+j] to buf[j] = input[i+1+j] in the octal escape branch of internal/transformations/js_decode.go, and change strconv.ParseInt to strconv.ParseUint with 16-bit width to correctly handle the full \000–\377 range.</anigation> <parameter name="timeline">[{"kind": "disclosed", "at": "2026-10-08"}, {"kind": "advisory", "at": "2026-10-08"}]

Technical details

The jsDecode transformation in Coraza contains an off-by-one error where the backslash character is incorrectly included in the octal number buffer (buf[j] = input[i+j] instead of buf[j] = input[i+1+j]), causing strconv.ParseInt to fail and return a null byte. Additionally, octal values \200–\377 fail due to signed 8-bit parsing when they should parse as unsigned. Attack requires only network access and a WAF rule using jsDecode; the backend application must independently be vulnerable to the decoded payload (XSS, SQLi, etc.).

Affected products

  • Coraza WAF 3.0.0 to 3.7.0

Identifiers

  • CVE-2026-104774
  • GHSA-pc5q-qfxp-ggqv
  • GO-2026-6696

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.