@hapi/content CVE-2026-119202

Exploitation requires the target to parse an untrusted Content-Disposition header via @hapi/content. The primary path is any hapi route with payload.multipart enabled (the default behavior when a route accepts multipart/form-data), because @hapi/pez invokes Content.disposition() on every part header BEFORE the route handler and before any validation, and such routes can be auth:false - so no authentication is needed. The secondary path is any application that passes untrusted headers directly to Content.disposition(). The only limiting factor is the route payload.maxBytes (default 1 MB), which caps the malicious token length and thus the per-request freeze duration; however a 64 KB token already blocks the process for more than 1 second, so this limit does not prevent exploitation. No special non-default configuration, user interaction, or platform-specific condition is required beyond accepting multipart payloads.

This is a genuine, actionable availability risk rather than an inflated high-CVSS score. The provided CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the mechanism described: a remote, unauthenticated attacker triggers quadratic-time regex processing in Content.disposition() with a single normal-sized multipart request, blocking the Node.js single-threaded event loop for seconds to minutes (the reporter measured 542 s for a ~1 MB token). Because Node.js is single-threaded, blocking the event loop halts ALL clients, so impact is a full service freeze, not degradation - this justifies A:H with C:N/I:N. Signal cross-reference: no EPSS score was supplied, and KEV status is not present (not listed), so there is no evidence of active exploitation; the vuln.today decision label is 'this_week' (urgent but not emergency/act_now), aligning with a high-impact DoS that is trivially exploitable but not confidence-/integrity-affecting. A working proof-of-concept with reproduction timings is published in the GHSA advisory, which raises practical risk materially above a theoretical ReDoS. No SSVC machine-readable decision block (exploitation/automatable/technical-impact) was supplied, so that framework cannot be independently applied beyond the 'this_week' label. Net: prioritize patching this week; it is a real, easy, repeatable DoS against any hapi service accepting multipart uploads, but it cannot be used for data theft or RCE.

An unauthenticated attacker sends a single, normal-sized HTTP POST to any hapi route that accepts multipart/form-data (payload.multipart enabled), with a Content-Disposition part header containing a long run of token characters and no '=' (e.g. name="f"; followed by 64 KB of 'a'). @hapi/pez calls Content.disposition() on that header before the handler or validation runs, and the unanchored global regex scan backtracks quadratically, freezing the event loop so the process answers no clients for seconds to minutes. A working proof-of-concept with measured timings (0.42 s at 32 KB, 7.17 s at 128 KB, 542 s near the 1 MB default maxBytes) is published in the GHSA advisory, and a small number of such requests keeps the service unavailable.