<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-14T08:02:41.220623+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-104774</id>
    <title>fkie_cve-2026-104774</title>
    <updated>2026-10-14T08:02:41.247157+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-104774"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-pc5q-qfxp-ggqv</id>
    <title>GHSA-pc5q-qfxp-ggqv — Coraza: jsDecode Off-by-One in Octal Escape Handling Enables WAF Bypass</title>
    <updated>2026-10-14T08:02:41.247246+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/corazawaf/coraza/v3</p>
<p>### 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.</p>
<p>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.</p>
<p>### Details
Vulnerable code: `internal/transformations/js_decode.go:64-70.`
```go
case (i+1 &lt; inputLen) &amp;&amp; isodigit(input[i+1]):
    /* \OOO (only one byte, \000 - \377) */
    buf := make([]byte, 3)
    j := 0</p>
<p>for (i+1+j &lt; inputLen) &amp;&amp; (j &lt; 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 bac…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-pc5q-qfxp-ggqv"/>
  </entry>
</feed>
