CVE-2026-119202: Regular Expression Denial of Service in @hapi/content Header Parsing

@hapi/content is the core HTTP Content-* header parsing utility library used across the Node.js and Hapi framework ecosystem. It provides functions to parse and validate Content-Type and Content-Disposition headers according to HTTP specifications, including RFC 6266 and RFC 5987. Within the Hapi framework architecture, @hapi/content is an upstream dependency of @hapi/pez, the multipart stream parser responsible for processing multipart/form-data HTTP request payloads.

A vulnerability classified under CWE-1333 (Inefficient Regular Expression Complexity) exists in @hapi/content starting in version 3.0.6 and affecting all releases prior to version 6.0.3. Specifically, the Content.disposition() function executes a global regular expression scan (internals.contentDispositionParamRegex) to extract key-value parameters from Content-Disposition headers. Due to an unanchored initial character class matching parameter names, malformed parameter tokens that omit the mandatory = delimiter force the V8 regular expression engine into quadratic $O(N^2)$ time complexity.

The primary attack surface includes any Hapi server route configured with payload.multipart enabled, as well as standalone Node.js applications that pass untrusted HTTP headers directly to Content.disposition(). In Hapi applications, @hapi/pez invokes Content.disposition() on each part's headers inside the multipart stream before route-level input validation or handler logic executes. Consequently, an unauthenticated remote attacker can trigger synchronous CPU exhaustion on the main Node.js execution thread via a single HTTP request, blocking the event loop and causing an application-wide denial of service.

The root cause of CVE-2026-119202 is the interaction between an unanchored negated character class at the beginning of internals.contentDispositionParamRegex and the global match flag (/g) used during String.prototype.replace(). When Content.disposition(header) parses a Content-Disposition header, it first verifies the form-data prefix using internals.contentDispositionRegex and isolates the remaining parameter string. It then iterates over the parameter string by passing internals.contentDispositionParamRegex to parameters.replace().

In vulnerable versions, internals.contentDispositionParamRegex begins with the capture group ([^\=\*\s]+), which greedily matches one or more characters that are not an equals sign (=), an asterisk (*), or whitespace. Immediately following this group is the optional extended parameter indicator (\*)? and the required delimiter pattern \s*\=\s*. For a valid parameter such as name="field", the first group consumes name, matches the =, and consumes the value in linear time.

When the parameter string contains a contiguous sequence of $N$ characters lacking an equals sign, asterisk, or whitespace (for example, form-data; name="f"; aaaaa...), the regular expression engine starts at index $i = 0$ of the malformed token and greedily consumes all $N$ characters into the ([^\=\*\s]+) group. The engine then attempts to match \s*\=\s* at the end of the string, which fails because no = is present. Because the pattern is unanchored and uses the /g flag, the regular expression engine's failure recovery mechanism advances the starting search index by a single character to $i = 1$ and re-evaluates the entire pattern.

At index $i = 1$, ([^\=\*\s]+) consumes the remaining $N - 1$ characters, fails again on the missing =, and advances to $i = 2$. This cycle repeats for every character in the $N$-length token. The total number of character comparisons performed by the regular expression engine equals $\sum_{i=1}^{N} i = \frac{N(N+1)}{2}$, yielding $O(N^2)$ quadratic complexity. For a token of $64,000$ characters, the engine executes approximately $2.048 \times 10^9$ character evaluations synchronously on the main V8 thread.

The vulnerability is located in lib/index.js within the hapijs/content repository. Prior to version 6.0.3, internals.contentDispositionParamRegex only defined matching branches for well-formed key-value pairs where an = character was present. If a parameter segment lacked an =, the regex engine had no way to consume and discard the segment in a single pass.

// Vulnerable code in lib/index.js (prior to v6.0.3)
internals.contentDispositionRegex = /^\s*form-data\s*(?:;\s*(\S.*))?$/i;
 
//                                        1: name     2: *            3: ext-value                      4: quoted  5: token
internals.contentDispositionParamRegex = /([^\=\*\s]+)(\*)?\s*\=\s*(?:([^;'"\s]+\'[\w-]*\'[^;\s]+)|(?:"([^"]*)")|([^;\s]*))/g;
 
exports.disposition = function (header) {
    // ... header validation and prefix extraction ...
    const extKeys = new Set();
    parameters.replace(internals.contentDispositionParamRegex, ($0, $1, $2, $3, $4, $5) => {
 
        if ($1 === '__proto__') {
            throw Boom.badRequest('Invalid content-disposition header format includes invalid parameters');
        }
        // ... parameter extraction logic ...
    });
};

In commit 0993851dc7234976a3fce3a7c31662b213c940fd, the maintainer modified internals.contentDispositionParamRegex by appending an uncaptured alternation branch |[^\=\*\s]+ at the end of the expression, and added an early return check in the .replace() callback.

// Patched code in lib/index.js (v6.0.3)
// The trailing alternative consumes a name that isn't followed by "=", otherwise the global scan retries from every
// character of it and backtracks quadratically, any later start in the same run would fail the same way anyway.
 
//                                        1: name     2: *            3: ext-value                      4: quoted  5: token     skipped
internals.contentDispositionParamRegex = /([^\=\*\s]+)(\*)?\s*\=\s*(?:([^;'"\s]+\'[\w-]*\'[^;\s]+)|(?:"([^"]*)")|([^;\s]*))|[^\=\*\s]+/g;
 
exports.disposition = function (header) {
    // ...
    const extKeys = new Set();
    parameters.replace(internals.contentDispositionParamRegex, ($0, $1, $2, $3, $4, $5) => {
 
        // If $1 is undefined, the trailing fallback branch matched a token without '='.
        // Ignore the token and return immediately.
        if ($1 === undefined) {
            return;
        }
 
        if ($1 === '__proto__') {
            throw Boom.badRequest('Invalid content-disposition header format includes invalid parameters');
        }
        // ...
    });
};

> [!NOTE] > Fix Completeness Assessment: The patch completely eliminates the quadratic backtracking behavior on malformed tokens. When the primary branch fails at index $i=0$ due to a missing =, the regex engine immediately evaluates the second alternation branch (|[^\=\*\s]+) at index $i=0$. This branch matches the entire contiguous run of non-delimiter characters in a single pass, advancing the regex lastIndex pointer past the end of the token. Because no capture groups exist in the fallback branch, $1 evaluates to undefined inside the callback, causing it to return immediately. This restores strict $O(N)$ linear time complexity without altering the functional return value of Content.disposition().

Exploiting CVE-2026-119202 requires no authentication or session state if the target application exposes an HTTP endpoint that parses Content-Disposition headers or accepts multipart/form-data payloads via Hapi's built-in multipart handling. In a network attack scenario against a Hapi server, the attacker sends an HTTP POST or PUT request with a Content-Type: multipart/form-data; boundary=... header. Inside the multipart body, the part header is crafted to include a Content-Disposition line containing a large sequence of characters without an equals sign.

Because @hapi/pez parses multipart headers while streaming the request body, the payload size is not limited by standard HTTP request header size limits enforced by Node.js (--max-http-header-size, typically 16 KB), as multipart part headers reside inside the HTTP request body. Instead, the size of the crafted Content-Disposition header is bounded only by the route's payload.maxBytes configuration (which defaults to 1 MB in @hapi/hapi) or any internal buffer limits in @hapi/pez.

The following standalone proof-of-concept demonstrates the local reproduction of the vulnerability using @hapi/content, matching the regression test cases introduced in commit 0993851dc7234976a3fce3a7c31662b213c940fd:

const Content = require('@hapi/content');
 
// Construct a Content-Disposition header with a 64,000-byte token lacking '='
const payload = 'a'.repeat(64000);
const header = `form-data; name="f"; ${payload}`;
 
const start = Date.now();
const result = Content.disposition(header);
const duration = Date.now() - start;
 
console.log('Parsed result:', result);
console.log(`Execution time: ${duration} ms`);

As demonstrated in the official test suite in test/index.js, the vulnerable code path is triggered whether the malformed token appears at the end of the header (form-data; name="f"; aaaaa...) or precedes valid parameters (form-data; aaaaa...; name="f"; filename=file.jpg). On vulnerable versions (< 6.0.3), a 64,000-character token blocks the Node.js event loop for multiple seconds per invocation, pinning a CPU core at 100% utilization. On patched versions (>= 6.0.3), both payloads execute in under 10 milliseconds.

The primary impact of CVE-2026-119202 is high availability loss (Denial of Service), reflected in its CVSS v3.1 score of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The attack vector is Network (AV:N), Attack Complexity is Low (AC:L), Privileges Required is None (PR:N), and User Interaction is None (UI:N). Confidentiality (C:N) and Integrity (I:N) are unaffected, as the flaw does not permit memory corruption, out-of-bounds reads, or unauthorized state modification.

In a Node.js runtime environment, JavaScript code and regular expression evaluation execute synchronously on a single main event loop thread. When Content.disposition() enters the quadratic backtracking loop, the V8 engine cannot yield execution to process other pending I/O events, timers, or incoming network connections. Every other concurrent user request handled by the same Node.js worker process is stalled until the regular expression evaluation finishes.

Furthermore, because multipart header parsing in @hapi/pez occurs during the payload parsing phase of the Hapi request lifecycle, it executes prior to route-level validation (options.validate.payload) and route handler execution. If a route allows multipart payloads without requiring prior authentication, an attacker can continuously transmit small, low-bandwidth multipart requests to keep the event loop permanently saturated, causing health check failures and upstream load balancer timeouts.

Threat intelligence metrics currently indicate an EPSS score of 0.00411 (35.40th percentile), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. While no mass weaponized exploitation has been recorded in public exploit databases, the triviality of constructing the payload makes any internet-facing Hapi multipart endpoint susceptible to service disruption.

To remediate CVE-2026-119202, upgrade @hapi/content to version 6.0.3 or later. Applications that depend on @hapi/content directly can update the package via standard package managers:

npm install @hapi/content@^6.0.3

In most Hapi deployments, @hapi/content is installed as a transitive dependency of @hapi/pez or @hapi/hapi. Operators should inspect their dependency tree using npm ls @hapi/content to identify all installed versions. If an older version (>= 3.0.6, < 6.0.3) is locked by a parent package, enforce version resolution in package.json using the overrides field (for npm) or resolutions field (for Yarn/pnpm):

{
  "overrides": {
    "@hapi/content": "^6.0.3"
  }
}

If immediate package patching is not operationally feasible, several defense-in-depth mitigations can reduce exposure:

1. Disable Unnecessary Multipart Parsing: Audit Hapi route configurations and disable payload.multipart on routes that do not explicitly require multipart file or form uploads.
2. Enforce Authentication Pre-Parsing: Where possible, require authentication before allowing large or multipart request bodies to be processed, or restrict access to multipart endpoints at the API gateway level.
3. WAF and Reverse Proxy Filtering: Configure upstream reverse proxies (such as NGINX, Envoy, or cloud WAFs) to inspect Content-Disposition headers and multipart bodies, rejecting requests containing contiguous non-whitespace parameter tokens without an = sign exceeding 256 bytes.