Unspecified Affected Product CVE-2026-104269

Requires an application that (1) parses multipart/form-data uploads, (2) enforces a security-relevant filename rule - such as an extension allowlist/denylist, sanitization, or path restriction - by inspecting only the standard Content-Disposition 'filename' parameter, and (3) has a downstream component that reads and acts on the RFC 2231 'filename*' extended parameter instead. The attacker supplies both parameters, placing a compliant value in 'filename' and the restricted/malicious value in 'filename*'. Limiting factors: the vulnerability is only meaningful where filename validation is used as a security control and where the 'filename*' value is actually consumed; applications that do not rely on filename rules, or that normalize both parameters consistently, are not materially affected. Exact affected product, versions, and whether the upload endpoint requires authentication are not determinable from the provided data.

Data for this CVE is severely limited: no CVSS score or vector, no CWE, no EPSS value, no KEV listing, and no POC indicator were supplied - the only signals are the GHSA advisory title (GHSA-5pww-8rfg-9crf) and a report via vendor:ubuntu. Based on the advisory title alone, this is a multipart filename-validation bypass: filename-restriction rules that inspect the standard Content-Disposition 'filename' parameter can be evaded by supplying an RFC 2231 extended 'filename*' parameter instead, which carries a different value that the validator does not check but a downstream consumer does. This is characteristically an integrity/validation-bypass weakness (CWE-20-class / inconsistent parsing), not a direct code-execution or memory-safety bug, so raw impact is moderate and highly dependent on how the application uses the filename (extension allowlisting, storage paths, antivirus/content checks). Exploitation status: no public exploit identified at time of analysis. Because no CVSS vector is provided, authentication requirements cannot be confirmed from the available data - this would typically be reachable by remote attackers against any endpoint accepting multipart uploads, but whether auth is required depends on the specific application. This looks like a genuine defense-in-depth-defeating parser-differential issue worth patching, but with no EPSS, KEV, or POC signal and no identified affected product, it cannot currently be ranked as a high-urgency widespread threat; priority should be set per-deployment based on whether filename rules are relied upon for a security decision.

An attacker uploads a file to an endpoint that enforces filename rules (e.g. an extension denylist or sanitization) by checking the ordinary Content-Disposition 'filename' parameter. The attacker sets a benign-looking 'filename' value but smuggles a malicious name via the RFC 2231 'filename*' extended parameter, which the validator ignores while the downstream handler honors it - bypassing the restriction. No public proof-of-concept is identified in the provided data, and because no CVSS vector was supplied, the required authentication level is not confirmed.