Vulnerabilities

Vulnerability · CVE-2026-114101

Coraza: Multipart filename* (RFC 5987) charset restriction lets a decoy filename bypass FILES-based rules in github.com/corazawaf/coraza

Published Oct 8, 2026 · catalog updated Oct 21, 2026 · Coraza: Multipart filename* (RFC

Open the advisory

Exploitation likelihood is not on this record for CVE-2026-114101. A missing EPSS score is not a low risk. Compare Coraza: Multipart filename* (RFC with the linked advisory before you change production.

Severity

Medium4.0

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Awaiting synchronization with FIRST

Remediation

Advisory link

Affected products

Go github.com/corazawaf/coraza · Go github.com/corazawaf/coraza/v2 · Go github.com/corazawaf/coraza/v3

## Summary Coraza extracts a multipart file upload's filename using Go's standard-library , which only decodes the RFC 5987/6266 extended parameter when its declared charset is exactly or . Any other charset — including , which RFC 5987 explicitly permits — is silently dropped by the stdlib, with no error and no fallback signal. This lets an attacker present one filename to Coraza and a different one to the backend application in the same request. ## Affected variables (documented as *"the original filenames as submitted by the client in the multipart upload"*), , and the file-vs-field routing decision that determines whether a part is tracked as a file at all. is not affected. It is declared in Coraza but is not populated by any code path in the affected versions. ## Details 's calls on the raw header and reads , which then populates / for parts recognized as file uploads. Per RFC 7578 §4.2 and RFC 6266, when both and are present, is authoritative. Go's implements this precedence internally ( in ), but only for values whose charset token is or : When returns , the stdlib silently leaves whatever was parsed for the plain parameter untouched (or leaves absent entirely if only was supplied) — there is no error, no partial-parse indicator, nothing a caller can detect. The stdlib also discards the RFC 5987 component of entirely; it is not recoverable from the parsed params map at all. ### Verified behavior (prior to the fix) | fields | Effective filename ( ) | Recognized as file upload? | |---|---|---| | | (correct) | yes | | | (decoy wins) | yes, but with the wrong name | | (no plain ) | *(none)* | **no** — processed as an ordinary form field into instead | In the second row, any rule inspecting for a dangerous extension only ever sees , while a backend that follows RFC 7578 precedence and accepts (an RFC-5987-legal, non-exotic charset) uses as the filename. In the third row, the upload skips file-specific rule scope and size-limit tracking ( ) entirely. ## Impact A ru