High priorityDisclosed

Advisory · CVE-2026-115728

hapi content parser ReDoS can block the Node.js event loop on one upload

The @hapi/content package from 6.0.1 before 6.0.3 has a regular expression denial of service flaw in Content.disposition(), so an unauthenticated multipart upload with a long parameter and no equals sign can block the event loop. CVSS 4.0 8.7.

Vendor
hapijs
Product
@hapi/content
Identifier / CWE
CVE-2026-115728
CWE-1333
Action timing
Immediate
ELI5

Explain it like I’m five

A header parser in this library can be given one long, oddly shaped label that makes it re-check the same text over and over, so a single upload can freeze the whole server process while it thinks.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Attacker sends a multipart upload

    An unauthenticated remote attacker sends a multipart upload with a long Content-Disposition parameter that has no equals sign.

  2. 02Parser hits the weak pattern

    Per the VulnCheck advisory, Content.disposition() in @hapi/content parses that parameter with a pattern left weak by an earlier incomplete fix.

  3. 03Backtracking grows quadratically

    The pattern backtracks quadratically over the long value instead of rejecting it quickly.

  4. 04Event loop blocks

    While the parser is stuck, the Node.js event loop is blocked and the process stops responding to other requests.

What happened

VulnCheck disclosed CVE-2026-115728 for @hapi/content, a header parsing package in the hapi Node.js ecosystem: versions from 6.0.1 before 6.0.3 contain a regular expression denial of service vulnerability in Content.disposition(). Per the advisory, the flaw comes from an incomplete fix for an earlier CVE, and unauthenticated remote attackers can trigger it with multipart uploads carrying a long Content-Disposition parameter that lacks an equals sign. The CVSS 4.0 score is 8.7, with availability as the impacted dimension, and the CVSS 3.1 score is 7.5.

Per the advisory, the crafted parameter triggers quadratic backtracking that blocks the event loop, so one request can make the Node.js process unresponsive rather than just failing that upload. The project security advisory for this package says the pattern problem is fixed by tightening the regular expressions and that there are no known workarounds, so upgrading is the stated path. The NVD record lists 6.0.3 as the first release outside the affected range.

What to do

  1. Inventory Node.js services that depend on @hapi/content, directly or through the hapi stack, and note the installed version of each.
  2. Upgrade affected installations to @hapi/content 6.0.3 or later.
  3. Until every instance is upgraded, put upload endpoints behind request size and timeout limits at the proxy or load balancer where you can, since the project states no workaround.
  4. Review logs and monitoring for multipart uploads with unusually long Content-Disposition parameters and for event loop stalls or health check failures that follow them.
  5. Verify the deployed version after updating and confirm normal multipart uploads still parse correctly.

Management note

This is a one-request freeze for any service that parses untrusted multipart uploads with this package, and the project says there is no workaround. Patch it as a routine availability fix, and do not let its denial of service label push it behind lower-impact work that needs authentication.