PT-2026-107376 · Go · Github.Com/Corazawaf/Coraza/V3

CVE-2026-41508

·

Published

2026-10-06

·

Updated

2026-10-06

CVSS v3.1

5.8

Medium

VectorAV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

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)

go
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)

go
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)

go
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:
conf
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:
conf
SecRuleEngine On
SecRequestBodyAccess On
SecRule REQBODY ERROR "!@eq 0" 
  "id:200002,phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.'"
SecRule MULTIPART STRICT ERROR "!@eq 0" 
  "id:200003,phase:2,t:none,log,deny,status:400,msg:'Multipart strict validation failed.'"
Three real-curl requests against the listener:
#BodyExpected (with rule 200003)Observed
1Well-formed field1=benign + closing boundaryHTTP 200HTTP 200 (baseline)
2Two parts, no closing boundary (...MALFORMED NO TRAILING BOUNDARY)HTTP 400HTTP 200
3Mid-part cutoff: `name="x"r
r
abc(nor
`, no boundary)HTTP 400HTTP 200
Server-side match log is empty for cases 2 and 3: neither rule 200002 nor rule 200003 fires. Example (case 2):
--PoCBoundary12345r

Content-Disposition: form-data; name="field1"r
r

benignr

--PoCBoundary12345r

Content-Disposition: form-data; name="truncated"r
r

MALFORMED NO TRAILING BOUNDARY
→ HTTP 200, no audit record, transaction.variables.multipartStrictError == 0.

Mitigation

A two-line change per site in internal/bodyprocessors/multipart.go:
go
if errors.Is(err, io.ErrUnexpectedEOF) {
  v.MultipartStrictError().(*collections.Single).Set("1")
  seenUnexpectedEOF = true  // keep existing break semantics
}
Apply at the three sites (lines 71–77, 82–88, 102–113 in the current code). No change to the return err control flow is needed — the fix only adds the flag-setter alongside the existing seenUnexpectedEOF = true / break path. PR #1453's ProcessPartial goal is preserved.
Operators running in ProcessPartial mode who intentionally allow truncated bodies should pair this with a config-level change (downgrade rule 200003 to detection-only, or scope it with a secondary check on whether SecRequestBodyLimit was actually hit). The engine change above is safe by default — it restores the invariant that malformed multipart always raises MULTIPART STRICT ERROR.

Affected versions

Introduced in PR #1453 (commit 3347961b, merged 2026-03-06). First released in v3.4.0 and still present on main at 599ae64a.
Affected: >= 3.4.0, <= 3.7.0.
Releases prior to v3.4.0 returned err on io.ErrUnexpectedEOF and so REQBODY ERROR would propagate via rule 200002 even if MULTIPART STRICT ERROR was not set — a different (arguably stricter) behavior that did not exhibit this bypass.

References

  • internal/bodyprocessors/multipart.go lines 70–113
  • coraza.conf-recommended rule id:200003 (MULTIPART STRICT ERROR)
  • PR #1453 — introduction of ErrUnexpectedEOF swallowing
  • coraza.conf-recommended rule id:200002 (REQBODY ERROR) — also not raised because ProcessRequest returns nil

Fix

RCE

Protection Mechanism Failure

Improper Handling of Exceptional Conditions

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-20CWE-693CWE-755

Related Identifiers

CVE-2026-41508
GHSA-R3RM-QPHW-HH76

Affected Products

Github.Com/Corazawaf/Coraza/V3