CVE-2026-119202 in Content
Summary
by MITRE • 10/29/2026
@hapi/content provides HTTP Content-* header parsing. From 3.0.6 until 6.0.3, Content.disposition() uses an unanchored parameter-name expression in a global regular-expression scan, causing repeated failed matching over the remaining input when a Content-Disposition parameter contains a long token without an equals sign. The resulting quadratic processing can block the Node.js event loop before route handlers or validation when @hapi/pez parses multipart/form-data headers, including unauthenticated hapi routes with payload.multipart enabled, and also affects applications that pass untrusted headers directly to Content.disposition(). This issue is fixed in @hapi/content version 6.0.3.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in the @hapi/content library represents a significant availability risk stemming from inefficient regular expression handling within HTTP header parsing logic. Specifically, the flaw resides in the Content.disposition() method which processes the Content-Disposition header to extract file names and other parameters for multipart form data submissions. Between versions 3.0.6 and 6.0.3, this function utilizes a global regular expression scan with an unanchored parameter-name pattern. This design choice creates a scenario where the regex engine performs redundant backtracking when encountering malformed input, particularly long tokens that lack the expected equals sign delimiter separating parameters from their values.
From a technical perspective, the core issue is rooted in catastrophic backtracking caused by nested quantifiers or ambiguous matching groups within an unanchored pattern applied globally across potentially large strings. When a malicious actor supplies a Content-Disposition header containing a very long token without an equal sign, the regular expression engine attempts to match the parameter name against every possible substring of the input. Because the pattern is not anchored and operates in global mode, it repeatedly scans the remaining portion of the string after each failed attempt at finding a valid delimiter or end-of-parameter marker. This results in quadratic time complexity relative to the length of the malicious header value, rather than linear time which would be expected for standard parsing operations.
The operational impact of this vulnerability is severe due to its direct effect on the Node.js event loop architecture. Since JavaScript execution is single-threaded and non-blocking by design, any operation that consumes excessive CPU cycles without yielding control blocks all other concurrent requests handled by the same process. In applications using @hapi/pez for parsing multipart/form-data payloads, this vulnerability can be triggered even through unauthenticated routes if payload.multipart validation is enabled. An attacker does not need to bypass authentication or possess valid credentials; they simply need to send a specially crafted HTTP request with an oversized and malformed Content-Disposition header. The resulting CPU spike effectively denies service to legitimate users by freezing the application's ability to process any other incoming requests until the malicious parsing operation completes, which may take minutes depending on input size.
This vulnerability aligns closely with CWE-400, Uncontrolled Resource Consumption, as it allows an attacker to exhaust server resources through a single request. Furthermore, from a threat modeling perspective using the MITRE ATT&CK framework, this behavior is characteristic of T1496, Resource Hijacking, where attackers leverage vulnerable software or configurations to consume computational resources for denial-of-service purposes. It also reflects CWE-730, Improper Error Handling, insofar as the library fails to validate input structure efficiently before processing, allowing malformed data to trigger expensive internal operations rather than failing fast with a clear error message.
Mitigation strategies must prioritize immediate patching of the @hapi/content dependency to version 6.0.3 or later, where the regular expression logic has been optimized to prevent backtracking and enforce stricter parsing constraints. For organizations unable to update immediately due to compatibility concerns, implementing an ingress-level Web Application Firewall rule can provide temporary protection by inspecting incoming HTTP headers for excessively long Content-Disposition values or malformed parameter structures before they reach the Node.js application layer. Additionally, developers should review their hapi route configurations to ensure that payload validation is not inadvertently enabled on endpoints that do not require multipart data processing, thereby reducing the attack surface exposed to this specific parsing routine.