Which versions of @hapi/content are affected by CVE-2026-44974?

@hapi/content versions prior to 6.0.2 (used by Hapi.js web applications) contain a parameter parsing vulnerability that allows attackers to bypass upload filename restrictions, potentially enabling…. A patch is available.

How to fix or mitigate CVE-2026-44974?

Within 24 hours, inventory all systems using the Hapi.js framework and identify which are running @hapi/content versions prior to 6.0.2. Within 7 days, deploy patched @hapi/content version 6.0.2 to all development, staging, and production environments and validate that file upload functionality operates correctly post-deployment. Within 30 days, conduct a comprehensive security review of upload handling logic and audit any web application firewalls or reverse proxies to confirm they properly handle duplicate Content-Disposition and Content-Type parameters.

@hapi/content CVE-2026-44974

Q: What is the CVSS score of CVE-2026-44974?

CVE-2026-44974 has a CVSS 4.0 base score of 7.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-45313 HIGH

Interpretation Conflict (CWE-436)

2026-05-27 https://github.com/hapijs/content

GHSA-36hh-x5p5-jgc8

PHP Authentication Bypass

7.7

CVSS 4.0 · Vendor: https://github.com/hapijs/content

Severity by source

Vendor (https://github.com/hapijs/content) PRIMARY

7.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

5.8 MEDIUM

Remote, unauthenticated, no interaction (AV:N/AC:L/PR:N/UI:N); scope change (S:C) since the bypass impacts a separate upstream filter, with limited integrity impact and no confidentiality/availability effect.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:H/SA:N

Primary rating from Vendor (https://github.com/hapijs/content).

CVSS VectorVendor: https://github.com/hapijs/content

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

Jul 17, 2026 - 20:36 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 17, 2026 - 20:22 vuln.today

cvss_changed

CVSS changed

Jul 17, 2026 - 20:22 NVD

7.7 (HIGH)

Source Code Evidence Fetched

May 27, 2026 - 23:21 vuln.today

Analysis Generated

May 27, 2026 - 23:21 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

511 npm packages depend on @hapi/content (4 direct, 507 indirect)

Ecosystem-wide dependent count for version 6.0.2.

DescriptionCVE.org

Impact

The two parsers resolved duplicates inconsistently and silently:

Content.disposition() retained the last occurrence of each parameter.
Content.type() retained the first occurrence of charset and boundary.

Either behavior creates a parameter-smuggling primitive when another component in the request-processing chain (a WAF, reverse proxy, security filter, or alternate parser) resolves duplicates the opposite way. The primary attack vector is upload filename allowlist bypass:

Content-Disposition: form-data; name="file"; filename="safe.txt"; filename="shell.php"

Patches

The issue has been patched in 6.0.2.

Workarounds

Pre or post validate headers looking for duplicates.

Resources

AnalysisAI

Parameter smuggling in @hapi/content (the header parser used by the Hapi.js framework) before 6.0.2 lets remote unauthenticated attackers bypass upload security controls by sending duplicate Content-Disposition or Content-Type parameters. Because Content.disposition() kept the last duplicate while Content.type() kept the first, a filename allowlist enforced by a WAF, reverse proxy, or alternate parser that resolves duplicates the opposite way can be evaded (e.g. filename="safe.txt"; filename="shell.php"). No public exploit identified at time of analysis and EPSS is very low (0.05%), but a vendor-released patch (6.0.2) is available and the technique is trivially reproducible.

Technical ContextAI

The affected component is @hapi/content (npm package pkg:npm/@hapi/content), the MIME/header parsing library that backs multipart and Content-Type/Content-Disposition handling in the Hapi.js Node.js web framework. The root cause maps to CWE-436 (Interpretation Conflict): RFC 6266 (Content-Disposition) and RFC 7231 (Content-Type) do not mandate a single deterministic resolution for repeated parameters, so two parsers in the same request chain can disagree. Here Content.disposition() silently retained the last occurrence of a duplicated parameter while Content.type() retained the first occurrence of charset and boundary. When a defensive component upstream (WAF, proxy, security filter) picks a different occurrence than the Hapi application does, the two see different effective values from the same header - the classic parameter-smuggling condition. The fix (commit 3850079) tightens the content-type token regex to the RFC 7230 §3.2.6 token set and makes both parsers throw Boom.badRequest on duplicate charset/boundary and duplicate disposition parameters instead of silently choosing one, while still allowing RFC 6266 ext-value (filename*) overrides.

RemediationAI

Vendor-released patch: 6.0.2 - upgrade @hapi/content to >= 6.0.2 (directly or by updating the parent Hapi packages that depend on it, then verifying the resolved version with npm ls @hapi/content), per advisory GHSA-36hh-x5p5-jgc8 (https://github.com/hapijs/content/security/advisories/GHSA-36hh-x5p5-jgc8). If you cannot upgrade immediately, the vendor-suggested workaround is to pre- or post-validate incoming headers and reject any request containing duplicate Content-Disposition or Content-Type parameters (more than one filename, name, charset, or boundary token) before it reaches the parser or the upload filter; the trade-off is added request-processing logic and a small risk of rejecting unusual-but-legitimate clients that emit repeated parameters. Additionally, ensure your WAF/reverse proxy and the application resolve duplicate parameters identically, and enforce upload allowlists on server-side validated attributes (final stored filename, magic-byte content type) rather than solely on the raw header value.