CVE-2026-44974

What it actually does

The flaw is an inconsistent duplicate-parameter parsing issue in MIME or multipart content handling. When a header such as Content-Disposition or Content-Type contains the same parameter more than once, different parser paths resolve the duplicate differently: one path may keep the first value while another keeps the last. This creates a parameter-smuggling primitive where a security control, proxy, WAF, or validation layer may inspect one value while the application logic later uses another. The most important technical consequence is upload validation bypass, such as a file allowlist accepting filename="safe.txt" while the downstream application stores or executes filename="shell.php". Similar ambiguity may affect charset, boundary, or other MIME parameter handling where duplicate parameters influence parsing, routing, storage, or content interpretation.

Why it matters to the business

Applications that accept file uploads or parse multipart requests may make incorrect security decisions, allowing attackers to bypass filename, extension, content-type, or multipart boundary checks. In the worst case, this can lead to upload of prohibited file types, web shell placement, stored malicious content, downstream parser confusion, or compromise of systems that process uploaded files. The CVSS score indicates high severity, but the currently low EPSS score and absence from the CISA KEV catalog suggest no broad public exploitation signal at this time. Risk is highest for internet-facing services that rely on filename or MIME parameters for upload allowlists, malware scanning decisions, or content handling.

How an attack unfolds

An attacker crafts a multipart/form-data request with duplicated MIME parameters in a header. For example, the attacker may submit a file upload where Content-Disposition contains both filename="safe.txt" and filename="shell.php". If an upstream component, WAF, reverse proxy, or application security filter reads the first filename and approves the upload, but the vulnerable parser or downstream application uses the last filename, the attacker can cause the application to store or process the disallowed value. The same class of attack can occur when duplicate charset or boundary parameters cause different components to interpret the same request body differently. Successful exploitation depends on parser chaining: the attacker needs at least two components in the request-processing path that resolve duplicates inconsistently and a security decision based on the ambiguously parsed value.

How to fix it

Upgrade to a vendor-fixed version of the affected parser or framework as soon as one is available. Because no fixed versions were provided in the input, consult the relevant vendor advisory and package manager metadata for the exact patched release. As a defense-in-depth mitigation, reject requests that contain duplicate MIME parameters in Content-Disposition or Content-Type headers, especially duplicate filename, name, charset, or boundary parameters. Normalize request parsing so every layer in the chain uses the same parser behavior and the same canonical value before making security decisions. Avoid relying only on client-supplied filename or Content-Type for security; validate file content, enforce server-generated filenames, store uploads outside executable paths, and apply strict extension and MIME allowlists after canonicalization. Configure WAFs, reverse proxies, and application middleware to block ambiguous multipart requests rather than attempting to choose between duplicate values.

How to confirm the fix worked

Confirm that the deployed parser or framework version includes the vendor fix once available. In application testing, send multipart requests with duplicated parameters and verify they are rejected consistently before reaching business logic. Test examples should include duplicate filename values, duplicate name values, duplicate charset values, and duplicate boundary values. Confirm that upload validation, malware scanning, storage naming, and downstream processing all operate on the same canonicalized values. Review reverse proxy and WAF behavior to ensure they do not approve a request using one duplicate value while the application consumes another. For exposed services, run negative tests against representative upload endpoints and confirm that policy-violating filenames or content types cannot be smuggled behind benign duplicate parameters.

Typical attack path

1. Identify an endpoint that accepts multipart/form-data uploads or parses MIME Content-Disposition or Content-Type headers.
2. Determine whether an upstream control validates filename, extension, content type, charset, or multipart boundary parameters.
3. Send test requests containing duplicate parameters, such as two filename values or two boundary values, and observe whether validation and final processing disagree.
4. Craft a request where the value seen by validation is benign and the value used by the application is malicious or policy-violating.
5. Upload or submit the crafted content to bypass allowlists or content-handling restrictions.
6. If the application stores uploaded files in an executable or sensitive location, attempt follow-on impact such as retrieving the file, triggering server-side processing, or executing uploaded content.

How to detect it

To determine whether this issue was already exploited, review HTTP access logs, WAF logs, reverse proxy logs, application request logs, and file-upload audit logs for multipart requests containing duplicate MIME parameters. Focus on Content-Disposition headers with more than one filename parameter, Content-Disposition headers with repeated name parameters, and Content-Type headers with repeated charset or boundary parameters. Correlate suspicious requests with successful upload events, creation of files with executable extensions, unexpected server-side processing of uploads, or newly accessible files in upload directories. If request bodies are not logged, use WAF telemetry, packet captures, object-storage audit logs, and application upload metadata to identify mismatches between the filename validated by security controls and the filename stored or processed by the application. Pay special attention to requests returning 200, 201, 204, 302, or other success responses after ambiguous multipart headers. Also review downstream artifacts such as newly created .php, .jsp, .asp, .aspx, .war, .jar, .pl, .py, .sh, or .cgi files if the application should not allow those uploads.

• Content-Disposition: form-data; name="file"; filename="safe.txt"; filename="shell.php"
• filename="safe.txt"; filename="shell.php"
• filename="image.jpg"; filename="shell.php"
• filename="document.pdf"; filename="shell.jsp"
• filename="upload.txt"; filename="webshell.aspx"
• Content-Disposition: form-data; name="file"; filename=
• ; filename=
• Content-Type: multipart/form-data; boundary=
• ; boundary=
• Content-Type: text/plain; charset=utf-8; charset=
• charset=utf-8; charset=
• Content-Disposition: form-data; name="file"; name=
• .php uploaded
• .jsp uploaded
• .aspx uploaded
• .war uploaded

What your security team should do

• Inventory internet-facing and high-risk applications that accept file uploads or parse multipart/form-data, MIME, or email-like content.
• Prioritize review of applications that allow user-controlled filenames, process uploaded files server-side, or store uploads under web-accessible paths.
• Upgrade affected libraries, frameworks, or parsers to patched versions when vendor fixes are available.
• Implement request rejection for duplicate Content-Disposition and Content-Type parameters at the application edge and in application code.
• Add regression tests for duplicate filename, name, charset, and boundary parameters across upload workflows.
• Ensure uploaded files are renamed server-side, stored outside executable directories, and validated by content inspection rather than filename alone.
• Tune WAF, reverse proxy, and application logs to alert on duplicate MIME parameters in multipart requests.
• Hunt historical logs for suspicious duplicate filename, charset, or boundary parameters, especially requests that resulted in successful uploads.