@hapi/content EUVD-2026-108939

The target application must use @hapi/content version 6.0.1 or 6.0.2 to parse Content-Disposition headers - in practice any hapi service (via @hapi/subtext) that accepts multipart/form-data uploads on a reachable route. No special configuration, authentication, or user interaction is required (PR:N/UI:N against default parsing behavior); the attacker only needs to deliver one HTTP request whose Content-Disposition contains a long parameter value with no equals sign. Limiting factors are narrow: exploitation is confined to applications that actually invoke Content.disposition() on attacker-controlled headers (i.e. multipart-accepting endpoints), and deployments already upgraded to 6.0.3 or that do not parse multipart input are not exposed. Impact is limited to availability (process hang); no data is read or modified.

All signals describe a remote, unauthenticated, availability-only denial of service. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms a network-reachable, low-complexity attack needing no privileges or user interaction, and the only impact set is VA:H (VC:N/VI:N/VA:N for integrity/confidentiality), so there is no data exposure or code execution - this is a process-availability issue, not a compromise. No EPSS score and no CISA KEV entry are provided in the input, so neither widespread automated exploitation nor confirmed in-the-wild use can be asserted; the vuln.today Decision label is 'this_week' (not act_now/emergency), aligning with a serious-but-not-emergency triage. The 8.7 score is driven entirely by the availability metric and the ease of reach, which is consistent with the mechanism: a single crafted request can block the Node.js event loop and stall the whole service. This is a real priority for any service that parses multipart/Content-Disposition input through @hapi/content, but it should be read as a DoS exposure rather than a high-CVSS issue masking low real risk - the risk is genuine yet bounded to availability. Note the vulnerability stems from an incomplete fix for CVE-2026-35213, so environments that believed they were patched by an earlier @hapi/content upgrade may still be exposed.

An unauthenticated attacker sends a single HTTP multipart/form-data request to any endpoint that parses the Content-Disposition header via @hapi/content, using a parameter of tens of thousands of characters that lacks an equals sign (e.g. 'form-data; name="f"; aaaa…'). The quadratic backtracking in Content.disposition()'s parsing regex consumes CPU and blocks the Node.js event loop, making the process unresponsive to all other clients. The fix PR #42 ships regression tests containing the exact malicious header (a 64,000-character parameter), so the trigger is publicly demonstrated.