Live › vulnerability › CVE-2026-119202
A crafted Content-Disposition header with a long token and no equals sign makes @hapi/content's parser run in quadratic time. The Node.js event loop stalls, so the server stops answering other requests.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 21:26 UTC. All times on this page are UTC.
Applications using @hapi/content from 3.0.6 up to 6.0.2 are exposed. The risk is highest for unauthenticated hapi routes with multipart payload parsing enabled, since @hapi/pez calls the vulnerable code before route handlers or validation run. Applications that never parse multipart uploads or untrusted Content-Disposition headers can deprioritize it, but should still upgrade.
No product ranges from the sources yet.
Unknown from the sources.
6.0.3Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
@hapi/content provides HTTP Content-* header parsing. From 3.0.6 until 6.0.3, Content.disposition() uses an unanchored parameter-name expression in a global regular-expression scan, causing repeated failed matching over the remaining input when a Content-Disposition parameter contains a long token without an equals sign. The resulting quadratic processing can block the Node.js event loop before route handlers or validation when @hapi/pez parses multipart/form-data headers, including unauthenticated hapi routes with payload.multipart enabled, and also affects applications that pass untrusted headers directly to Content.disposition(). This issue is fixed in @hapi/content version 6.0.3.
This page as .md · .json · in your agent: get_signal("CVE-2026-119202")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.