Vulnerability GHSA-r3rm-qphw-hh76

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" \
    "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:

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.

Mitigation

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.

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