| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/corazawaf/coraza | all versions | |
| github.com/corazawaf/coraza/v2 | all versions | |
| github.com/corazawaf/coraza/v3 | ≥ 3.4.0, < 3.8.0 | 3.8.0 |
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.
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
}
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
}
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:
MULTIPART_STRICT_ERROR stays at its initial value 0.REQBODY_ERROR is not propagated either (since ProcessRequest returns nil).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.
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 . 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 and still set , letting the operator decide (via rule 200003 or their own policy) whether partial processing is acceptable.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeErrUnexpectedEOFbreakMULTIPART_STRICT_ERRORRule 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:
Content-Disposition header that the Go parser refuses but the backend accepts.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.
Start a Coraza-wrapped HTTP server shipping the canonical defensive rules from coraza.conf-recommended:
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:
| # | Body | Expected (with rule 200003) | Observed |
|---|---|---|---|
| 1 | Well-formed field1=benign + closing boundary | HTTP 200 | HTTP 200 (baseline) |
| 2 | Two parts, no closing boundary (...MALFORMED_NO_TRAILING_BOUNDARY) | HTTP 400 | HTTP 200 |
| 3 | Mid-part cutoff: name="x"\r\n\r\nabc (no \r\n, no boundary) | HTTP 400 | HTTP 200 |
Server-side match log is empty for cases 2 and 3: neither rule 200002 nor rule 200003 fires. Example (case 2):
--PoCBoundary12345\r\n
Content-Disposition: form-data; name="field1"\r\n\r\n
benign\r\n
--PoCBoundary12345\r\n
Content-Disposition: form-data; name="truncated"\r\n\r\n
MALFORMED_NO_TRAILING_BOUNDARY
→ HTTP 200, no audit record, transaction.variables.multipartStrictError == 0.
A two-line change per site in internal/bodyprocessors/multipart.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.
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.
internal/bodyprocessors/multipart.go lines 70–113coraza.conf-recommended rule id:200003 (MULTIPART_STRICT_ERROR)ErrUnexpectedEOF swallowingcoraza.conf-recommended rule id:200002 (REQBODY_ERROR) — also not raised because ProcessRequest returns nil