CVE-2026-41508

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.4.0 until 3.8.0, the multipart processor in internal/bodyprocessors/multipart.go treats io.ErrUnexpectedEOF as nonfatal without setting MULTIPART_STRICT_ERROR. A remote attacker can submit a truncated multipart body that produces io.ErrUnexpectedEOF, causing parsing to stop without raising the strict-error signal used by the recommended defensive rule. Rules 200002 and 200003 do not fire, allowing multipart parser-disagreement payloads to reach a backend that interprets the truncated body differently. This issue is fixed in version 3.8.0.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.4.0 until 3.8.0, the multipart processor in internal/bodyprocessors/multipart.go treats io.ErrUnexpectedEOF as nonfatal without setting MULTIPART_STRICT_ERROR. A remote attacker can submit a truncated multipart body that produces io.ErrUnexpectedEOF, causing parsing to stop without raising the strict-error signal used by the recommended defensive rule. Rules 200002 and 200003 do not fire, allowing multipart parser-disagreement payloads to reach a backend that interprets the truncated body differently. This issue is fixed in version 3.8.0.

Root Cause

File: internal/bodyprocessors/multipart.go (since commit 3347961b, PR #1453 "feat: ignore unexpected EOF in MIME multipart request body processor", merged 2026-03-06, first shipped in v3.4.0).

The multipart body processor treats io.ErrUnexpectedEOF as a benign condition. Three sites are affected; all mishandle the error the same way.

File branch, filesystem-backed (lines 71–77)

sz, err := io.Copy(temp, p)
if err != nil {
    if !errors.Is(err, io.ErrUnexpectedEOF) {
        v.MultipartStrictError().(*collections.Single).Set("1")
        return err
    }
    seenUnexpectedEOF = true     // <-- flag never set for UnexpectedEOF
}

File branch, TinyGo path (lines 82–88)

sz, err := io.Copy(io.Discard, p)
if err != nil {
    if !errors.Is(err, io.ErrUnexpectedEOF) {
        v.MultipartStrictError().(*collections.Single).Set("1")
        return err
    }
    seenUnexpectedEOF = true     // <-- same gap
}

Field branch (lines 102–113)

data, err := io.ReadAll(p)
if err != nil {
    if !errors.Is(err, io.ErrUnexpectedEOF) {
        v.MultipartStrictError().(*collections.Single).Set("1")
        return err
    }
}
...
if errors.Is(err, io.ErrUnexpectedEOF) {
    break                         // <-- exits loop with no flag set
}

The function then returns nil at line 116 for any body that ended prematurely. Consequences:

1. MULTIPART_STRICT_ERROR stays at its initial value 0.
2. REQBODY_ERROR is not propagated either (since ProcessRequest returns nil).
3. Neither of the two canonical defensive rules shipped in coraza.conf-recommended fires:

   SecRule REQBODY_ERROR "!@eq 0" "id:200002,phase:2,deny,status:400,..."
   SecRule MULTIPART_STRICT_ERROR "!@eq 0" "id:200003,phase:2,deny,status:400,..."
   

All other error branches in the same function (lines 27, 48, 66, 84, 104) correctly set MULTIPART_STRICT_ERROR before returning; this is an inconsistency introduced in #1453, not a systemic issue.

Context — why the error is swallowed

PR #1453 was introduced to support SecRequestBodyLimitAction ProcessPartial: when a body is cut off because it hit the configured request-body limit, the parser should still surface the parts it did receive. The PR legitimately needs to avoid return err on ErrUnexpectedEOF. But it also silenced the strict-error flag, which is the wrong compromise — the flag is exactly how operators observe that something was incomplete. The fix should keep the non-fatal break and still set MULTIPART_STRICT_ERROR, letting the operator decide (via rule 200003 or their own policy) whether partial processing is acceptable.

Impact

Rule 200003 is Coraza's blanket defense against multipart parser-inconsistency evasions — attack classes where the body is crafted so Coraza's Go mime/multipart reader and the backend's multipart parser (PHP, Node, Java, legacy libmodsecurity, etc.) disagree about where fields start or end. The rule fails-closed on any malformed body, so the operator does not need to enumerate every parser-disagreement trick. That defense is now void for any evasion that also truncates the body.

Examples of what becomes reachable:

• Smuggling a second field past the truncation boundary that the backend's more permissive parser still extracts.
• Hiding payload bytes after a deliberately malformed Content-Disposition header that the Go parser refuses but the backend accepts.
• Generic CRS evasion chains that depend on rule 200003 as a catch-all.

The fix is tiny and low-risk. The impact is disproportionately large because rule 200003 is the only defense-in-depth rule for multipart in the recommended config — there is no secondary signal.

Proof of Concept

Start a Coraza-wrapped HTTP server shipping the canonical defensive rules from coraza.conf-recommended:

SecRuleEngine On
SecRequestBodyAccess On
SecRule REQBODY_ERROR "!@eq 0" \
   …

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.4.0 until 3.8.0, the multipart processor in internal/bodyprocessors/multipart.go treats io.ErrUnexpectedEOF as nonfatal without setting MULTIPART_STRICT_ERROR. A remote attacker can submit a truncated multipart body that produces io.ErrUnexpectedEOF, causing parsing to stop without raising the strict-error signal used by the recommended defensive rule. Rules 200002 and 200003 do not fire, allowing multipart parser-disagreement payloads to reach a backend that interprets the truncated body differently. This issue is fixed in version 3.8.0.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.4.0 until 3.8.0, the multipart processor in internal/bodyprocessors/multipart.go treats io.ErrUnexpectedEOF as nonfatal without setting MULTIPART_STRICT_ERROR. A remote attacker can submit a truncated multipart body that produces io.ErrUnexpectedEOF, causing parsing to stop without raising the strict-error signal used by the recommended defensive rule. Rules 200002 and 200003 do not fire, allowing multipart parser-disagreement payloads to reach a backend that interprets the truncated body differently. This issue is fixed in version 3.8.0.

Root Cause

File: internal/bodyprocessors/multipart.go (since commit 3347961b, PR #1453 "feat: ignore unexpected EOF in MIME multipart request body processor", merged 2026-03-06, first shipped in v3.4.0).

The multipart body processor treats io.ErrUnexpectedEOF as a benign condition. Three sites are affected; all mishandle the error the same way.

File branch, filesystem-backed (lines 71–77)

sz, err := io.Copy(temp, p)
if err != nil {
    if !errors.Is(err, io.ErrUnexpectedEOF) {
        v.MultipartStrictError().(*collections.Single).Set("1")
        return err
    }
    seenUnexpectedEOF = true     // <-- flag never set for UnexpectedEOF
}

File branch, TinyGo path (lines 82–88)

sz, err := io.Copy(io.Discard, p)
if err != nil {
    if !errors.Is(err, io.ErrUnexpectedEOF) {
        v.MultipartStrictError().(*collections.Single).Set("1")
        return err
    }
    seenUnexpectedEOF = true     // <-- same gap
}

Field branch (lines 102–113)

data, err := io.ReadAll(p)
if err != nil {
    if !errors.Is(err, io.ErrUnexpectedEOF) {
        v.MultipartStrictError().(*collections.Single).Set("1")
        return err
    }
}
...
if errors.Is(err, io.ErrUnexpectedEOF) {
    break                         // <-- exits loop with no flag set
}

The function then returns nil at line 116 for any body that ended prematurely. Consequences:

1. MULTIPART_STRICT_ERROR stays at its initial value 0.
2. REQBODY_ERROR is not propagated either (since ProcessRequest returns nil).
3. Neither of the two canonical defensive rules shipped in coraza.conf-recommended fires:

   SecRule REQBODY_ERROR "!@eq 0" "id:200002,phase:2,deny,status:400,..."
   SecRule MULTIPART_STRICT_ERROR "!@eq 0" "id:200003,phase:2,deny,status:400,..."
   

All other error branches in the same function (lines 27, 48, 66, 84, 104) correctly set MULTIPART_STRICT_ERROR before returning; this is an inconsistency introduced in #1453, not a systemic issue.

Context — why the error is swallowed

PR #1453 was introduced to support SecRequestBodyLimitAction ProcessPartial: when a body is cut off because it hit the configured request-body limit, the parser should still surface the parts it did receive. The PR legitimately needs to avoid return err on ErrUnexpectedEOF. But it also silenced the strict-error flag, which is the wrong compromise — the flag is exactly how operators observe that something was incomplete. The fix should keep the non-fatal break and still set MULTIPART_STRICT_ERROR, letting the operator decide (via rule 200003 or their own policy) whether partial processing is acceptable.

Impact

Rule 200003 is Coraza's blanket defense against multipart parser-inconsistency evasions — attack classes where the body is crafted so Coraza's Go mime/multipart reader and the backend's multipart parser (PHP, Node, Java, legacy libmodsecurity, etc.) disagree about where fields start or end. The rule fails-closed on any malformed body, so the operator does not need to enumerate every parser-disagreement trick. That defense is now void for any evasion that also truncates the body.

Examples of what becomes reachable:

• Smuggling a second field past the truncation boundary that the backend's more permissive parser still extracts.
• Hiding payload bytes after a deliberately malformed Content-Disposition header that the Go parser refuses but the backend accepts.
• Generic CRS evasion chains that depend on rule 200003 as a catch-all.

The fix is tiny and low-risk. The impact is disproportionately large because rule 200003 is the only defense-in-depth rule for multipart in the recommended config — there is no secondary signal.

Proof of Concept

Start a Coraza-wrapped HTTP server shipping the canonical defensive rules from coraza.conf-recommended:

SecRuleEngine On
SecRequestBodyAccess On
SecRule REQBODY_ERROR "!@eq 0" \
   …

Coraza: Truncated multipart body bypasses MULTIPART_STRICT_ERROR (rule 200003) via silent io.ErrUnexpectedEOF handling in github.com/corazawaf/coraza