OWASP Coraza WAF: Truncated multipart body bypasses MULTIPART_STRICT_ERROR (rule 200003) via silent io.ErrUnexpectedEOF handling

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

12 Oct 2026 20:01:09 UTC

Source modified

13 Oct 2026 20:24:17 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 5.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

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.

Source published

Oct 12, 2026, 8:01:09 PM (timezone not stated)

Source modified

Oct 13, 2026, 8:24:17 PM (timezone not stated)

Observed here

7 Nov 2026 13:22:31 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 5.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

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.

Source published

12 Oct 2026 21:17:17 UTC

Source modified

16 Oct 2026 20:04:29 UTC

Observed here

25 Oct 2026 09:17:41 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 5.8 CVSS:3.1/AV: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: | # | 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. ## 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`

Source published

6 Oct 2026 20:37:54 UTC

Source modified

20 Oct 2026 00:56:07 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

Publisher rating · MODERATE

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

Source published

20 Oct 2026 00:20:51 UTC

Source modified

20 Oct 2026 00:45:10 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.