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

The @hapi/content npm library (versions < 6.0.2) contains a parameter smuggling vulnerability that bypasses file upload security controls enforced by WAFs and reverse proxies.. A patch is available.

How to fix or mitigate CVE-2026-44974?

Within 24 hours: scan all Node.js applications for @hapi/content dependency versions < 6.0.2 using npm audit or equivalent SBOM tools. Within 7 days: upgrade all affected instances to @hapi/content version 6.0.2 or later and redeploy applications. Within 30 days: audit and re-validate file upload restrictions and WAF/proxy filtering rules to confirm the parameter smuggling behavior is no longer possible.

@hapi/content CVE-2026-44974

Q: How to fix or mitigate CVE-2026-44974?

Within 24 hours: scan all Node.js applications for @hapi/content dependency versions < 6.0.2 using npm audit or equivalent SBOM tools. Within 7 days: upgrade all affected instances to @hapi/content version 6.0.2 or later and redeploy applications. Within 30 days: audit and re-validate file upload restrictions and WAF/proxy filtering rules to confirm the parameter smuggling behavior is no longer possible.

HIGH

Interpretation Conflict (CWE-436)

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

GHSA-36hh-x5p5-jgc8

PHP Authentication Bypass

Lifecycle Timeline

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

504 npm packages depend on @hapi/content (4 direct, 500 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

Upload filename allowlist bypass in the @hapi/content npm header parser (versions < 6.0.2) lets remote attackers smuggle malicious parameters past upstream validation. The library's Content.disposition() retained the last occurrence of a duplicated parameter while Content.type() retained the first occurrence of charset/boundary, so when a WAF, reverse proxy, or security filter resolves the same duplicate the opposite way, the two layers disagree on values such as the upload filename. No public exploit code or active exploitation has been identified; the GitHub Security Advisory (GHSA-36hh-x5p5-jgc8) documents the exact smuggling header but no CVSS score or EPSS data is provided.

Technical ContextAI

@hapi/content is the header-parsing helper used by the hapi.js web framework to interpret Content-Type and Content-Disposition headers (per RFC 7231 §3.1.1.1 and RFC 6266 §4.1) for multipart form uploads. The flaw is a classic CWE-436 Interpretation Conflict: the parser silently tolerated duplicate parameters and resolved them deterministically but inconsistently (last-wins for Content-Disposition, first-wins for Content-Type charset/boundary). Because RFC 7230 §3.2.6 token rules were also loosely enforced, a crafted header like 'Content-Disposition: form-data; name="file"; filename="safe.txt"; filename="shell.php"' parses differently in @hapi/content than in another component that takes the first value, producing a parameter-smuggling primitive. The CPE pkg:npm/@hapi_content confirms this is the JavaScript/Node.js package, not a PHP component despite the 'PHP' tag, which derives only from the .php extension used in the example payload.

RemediationAI

Vendor-released patch: 6.0.2 - upgrade @hapi/content to 6.0.2 or later (fix commit 3850079550c191d25e3643dc82a6d61144db8c2f), which makes the parser reject duplicate charset/boundary and Content-Disposition parameters with a Boom badRequest error and tightens token-character validation. Run 'npm ls @hapi/content' to find transitive pulls and bump the resolution if a dependency pins an older version. As an interim workaround per the advisory, pre- or post-validate incoming Content-Type and Content-Disposition headers to detect and reject duplicate parameters before they reach the parser; the trade-off is that custom header validation must exactly mirror the parser's RFC handling or it can break legitimate ext-value (filename*) uploads. Advisory: https://github.com/hapijs/content/security/advisories/GHSA-36hh-x5p5-jgc8.