CVE-2026-44974 in hapijs
Summary
by MITRE • 07/17/2026
@hapi/content provided HTTP Content-* headers parsing. Prior to 6.0.2, Content.disposition() retained the last occurrence of each duplicate parameter while Content.type() retained the first occurrence of duplicate charset and boundary parameters, creating a parameter-smuggling primitive when another component in the request-processing chain resolves duplicates the opposite way. This can allow an upload filename allowlist bypass in headers such as Content-Disposition: form-data; name="file"; filename="safe.txt"; filename="shell.php". This issue is fixed in version 6.0.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/17/2026
The vulnerability described represents a critical parameter smuggling primitive that emerged in the hapi content parsing library prior to version 6.0.2. This security flaw stems from inconsistent handling of duplicate HTTP header parameters during content type and disposition parsing operations, creating a scenario where different components within the same request processing chain may interpret identical header data in contradictory ways. The root cause lies in the library's divergent approach to resolving duplicate parameters across its Content.disposition() and Content.type() methods, which creates opportunities for attackers to manipulate header parsing outcomes through carefully crafted malicious input.
The technical implementation of this vulnerability exploits the inconsistent parameter resolution behavior between two distinct parsing functions within the library. When Content.disposition() processes headers containing duplicate parameters, it retains the last occurrence of each duplicate parameter, while Content.type() maintains the first occurrence of duplicate charset and boundary parameters. This fundamental inconsistency creates a parameter smuggling vector where an attacker can construct malicious headers that appear benign to one parser but are interpreted differently by another component in the processing chain. The vulnerability manifests when subsequent components in the request pipeline resolve duplicate parameters in the opposite manner, allowing attackers to bypass security controls designed to validate upload filenames.
The operational impact of this vulnerability is particularly severe for applications that rely on filename validation as a security control mechanism. Attackers can craft Content-Disposition headers with duplicate filename parameters such as "Content-Disposition: form-data; name="file"; filename="safe.txt"; filename="shell.php"" where the first filename parameter appears legitimate while the second contains malicious payload. When different components in the processing chain resolve these duplicates inconsistently, the system may accept the malicious filename while appearing to validate against the safe one, thereby enabling unauthorized file uploads and potential code execution. This type of vulnerability directly impacts application security controls and can lead to complete system compromise through unauthorized file upload attacks.
The vulnerability aligns with CWE-1247, which addresses parameter smuggling in HTTP headers, and demonstrates characteristics that could be mapped to ATT&CK technique T1059.007 for command and scripting interpreter usage through file uploads. Organizations implementing applications using vulnerable versions of the hapi content library face significant risk of bypassing security controls designed to restrict file uploads based on filename extensions or content validation. The fix implemented in version 6.0.2 addresses this by standardizing parameter resolution behavior across all parsing functions, ensuring consistent handling of duplicate parameters regardless of their position within header structures.
Mitigation strategies should focus on immediate patching of the vulnerable library components to version 6.0.2 or later, while also implementing defensive measures such as comprehensive header validation, strict content type checking, and redundant security controls that do not rely solely on filename parameter parsing. Organizations should conduct thorough vulnerability assessments across their entire application stack to identify other potential instances where similar parameter resolution inconsistencies might exist between different components in their request processing pipelines. Additionally, implementing proper input sanitization and parameter validation at multiple layers of the application architecture can help prevent exploitation of such parameter smuggling vulnerabilities that may exist in other third-party libraries or custom implementations.