Is CVE-2026-41508 exploited in the wild?

No. Junglewise Threat Intelligence has no report of CVE-2026-41508 being exploited in the wild.

How severe is CVE-2026-41508?

Medium severity, with a CVSS score of 5.8, published 12 October 2026.

Which products and versions are affected?

Coraza Project Coraza 3.4.0 through 3.7.0; github.com/corazawaf/coraza (Go) SEMVER:introduced=0; github.com/corazawaf/coraza/v2 (Go) SEMVER:introduced=0; github.com/corazawaf/coraza/v3 (Go) >= 3.4.0, <= 3.7.0, SEMVER:introduced=3.4.0,fixed=3.8.0.

How is CVE-2026-41508 attacked?

It is attacked over the network, in a software library.

Am I affected by CVE-2026-41508?

Check whether you run Coraza Project Coraza, github.com/corazawaf/coraza (Go), github.com/corazawaf/coraza/v2 (Go) or one of the others listed at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

CVE-2026-41508: Coraza multipart strict validation bypass via truncated body

Q: Is there a fix for CVE-2026-41508?

Yes. github.com/corazawaf/coraza/v3 (Go): upgrade to 3.8.0 or later. Until then: Apply a two-line code change at three sites in internal/bodyprocessors/multipart.go to set MULTIPART_STRICT_ERROR when io.ErrUnexpectedEOF is encountered, restoring the strict validation flag. Operators using ProcessPartial mode should pair this with config-level changes such as downgrading rule 200003 to detection-only or adding secondary checks on SecRequestBodyLimit. [{"kind":"other","at":"2026-03-06","note":"Vulnerable code introduced in PR #1453, merged"},{"kind":"disclosed","at":"2026-10-06","note":"Advisory published (GHSA-r3rm-qphw-hh76)"}] Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

CVE-2026-41508 · Severity: medium · CVSS 5.8 · Published 2026-10-12

Coraza is a web application firewall that inspects HTTP requests to block malicious payloads. A flaw in how it handles incomplete multipart request bodies allows attackers to bypass a critical validation rule (MULTIPART_STRICT_ERROR) by crafting truncated requests, enabling parser-confusion attacks where Coraza and the backend application disagree on request structure. This can lead to payload smuggling and WAF evasion.

Technologies: github.com/corazawaf/coraza (Go), github.com/corazawaf/coraza/v2 (Go), github.com/corazawaf/coraza/v3 (Go). Vendors: Go.

Quick answers

Is CVE-2026-41508 exploited in the wild?: No. Junglewise Threat Intelligence has no report of CVE-2026-41508 being exploited in the wild.
How severe is CVE-2026-41508?: Medium severity, with a CVSS score of 5.8, published 12 October 2026.
Which products and versions are affected?: Coraza Project Coraza 3.4.0 through 3.7.0; github.com/corazawaf/coraza (Go) SEMVER:introduced=0; github.com/corazawaf/coraza/v2 (Go) SEMVER:introduced=0; github.com/corazawaf/coraza/v3 (Go) >= 3.4.0, <= 3.7.0, SEMVER:introduced=3.4.0,fixed=3.8.0.
Is there a fix for CVE-2026-41508?: Yes. github.com/corazawaf/coraza/v3 (Go): upgrade to 3.8.0 or later. Until then: Apply a two-line code change at three sites in internal/bodyprocessors/multipart.go to set MULTIPART_STRICT_ERROR when io.ErrUnexpectedEOF is encountered, restoring the strict validation flag. Operators using ProcessPartial mode should pair this with config-level changes such as downgrading rule 200003 to detection-only or adding secondary checks on SecRequestBodyLimit.</anigation> <parameter name="timeline">[{"kind":"other","at":"2026-03-06","note":"Vulnerable code introduced in PR #1453, merged"},{"kind":"disclosed","at":"2026-10-06","note":"Advisory published (GHSA-r3rm-qphw-hh76)"}] Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-41508 attacked?: It is attacked over the network, in a software library.
Am I affected by CVE-2026-41508?: Check whether you run Coraza Project Coraza, github.com/corazawaf/coraza (Go), github.com/corazawaf/coraza/v2 (Go) or one of the others listed at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

github.com/corazawaf/coraza/v3 (Go): upgrade to 3.8.0 or later
```
go get github.com/corazawaf/coraza/v3@v3.8.0
```

Apply a two-line code change at three sites in internal/bodyprocessors/multipart.go to set MULTIPART_STRICT_ERROR when io.ErrUnexpectedEOF is encountered, restoring the strict validation flag. Operators using ProcessPartial mode should pair this with config-level changes such as downgrading rule 200003 to detection-only or adding secondary checks on SecRequestBodyLimit.</anigation> <parameter name="timeline">[{"kind":"other","at":"2026-03-06","note":"Vulnerable code introduced in PR #1453, merged"},{"kind":"disclosed","at":"2026-10-06","note":"Advisory published (GHSA-r3rm-qphw-hh76)"}]

Technical details

The multipart body processor in Coraza's internal/bodyprocessors/multipart.go silently swallows io.ErrUnexpectedEOF errors (since v3.4.0) without setting the MULTIPART_STRICT_ERROR flag, allowing malformed or truncated multipart bodies to pass validation. An attacker exploits this by truncating a multipart body (e.g., omitting the closing boundary or cutting off mid-field) to bypass rule 200003, the sole defense-in-depth check for multipart parser inconsistencies. The fix requires setting MULTIPART_STRICT_ERROR when encountering io.ErrUnexpectedEOF at three code sites.

Affected products

Coraza Project Coraza 3.4.0 through 3.7.0

Identifiers

CVE-2026-41508
GHSA-r3rm-qphw-hh76
GO-2026-6670

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.