CVE-2026-35213

What it actually does

CVE-2026-35213 is a network-exploitable denial-of-service vulnerability in @hapi/content through version 6.0.0. The library parses HTTP Content-Type and Content-Disposition header values using regular expressions that can enter catastrophic backtracking when given specially crafted input. A remote, unauthenticated attacker can send malformed or adversarial HTTP header values that cause the Node.js process to spend excessive CPU time evaluating the regex, delaying or blocking request handling and potentially making the affected service unavailable.

Why it matters to the business

Applications that depend on vulnerable versions of @hapi/content may be disrupted by a small number of crafted HTTP requests, causing slow responses, request timeouts, degraded API availability, or process restarts. Because exploitation requires no authentication and the attack is delivered over normal HTTP traffic, internet-facing services are the highest priority. Current public signals indicate low EPSS likelihood, no known CISA KEV listing, no ransomware association, and no known mature public exploit, but the issue is still operationally relevant because denial-of-service bugs can affect service availability without needing account compromise.

How an attack unfolds

An attacker first identifies an HTTP endpoint backed by an application that uses a vulnerable @hapi/content version to parse Content-Type or Content-Disposition headers. The attacker then sends requests containing intentionally malformed, unusually long, or repetitively structured header values designed to trigger catastrophic backtracking in the affected parsing regular expressions. When the application attempts to parse the header, the Node.js event loop can become CPU-bound while evaluating the regex. Repeating the request, or sending multiple concurrent requests, can keep worker processes busy, increase latency, exhaust capacity, and cause upstream proxies, load balancers, or clients to observe timeouts or service errors. The attack does not provide code execution or data access, but it can deny availability of the affected service.

How to fix it

Upgrade @hapi/content to version 6.0.1 or later wherever it is used, including transitive dependency paths where possible. Regenerate and redeploy lockfiles after updating package manifests, then rebuild containers or deployment artifacts so the patched package is actually present at runtime. If immediate upgrade is not possible, reduce exposure by enforcing strict limits on HTTP header size, rejecting malformed Content-Type and Content-Disposition values at a reverse proxy or application gateway, applying request rate limits, setting aggressive request timeouts, and isolating affected services behind load balancers with health checks. These mitigations reduce exploitability but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm that no deployed artifact contains @hapi/content version 6.0.0 or earlier. Check package manifests, lockfiles, SBOMs, container images, and runtime node_modules directories for the installed version. Validate that builds resolve to @hapi/content 6.0.1 or later. In staging, send benign negative tests with oversized or malformed Content-Type and Content-Disposition headers and confirm the application rejects them quickly without sustained CPU spikes, event-loop delay, worker restarts, or elevated error rates. Also confirm reverse proxies or gateways enforce expected header-size and request-rate limits.

Typical attack path

1. Identify an HTTP service likely implemented with Node.js or Hapi-related components.
2. Send probe requests containing unusual Content-Type or Content-Disposition header values and observe latency or timeout behavior.
3. Craft header values with repetitive or malformed parameter patterns that maximize regex backtracking in the vulnerable parser.
4. Send the crafted requests repeatedly or concurrently to consume CPU in the Node.js process.
5. Sustain the request stream until the service slows, returns errors, restarts, or becomes unavailable.

How to detect it

To assess prior exploitation, review HTTP access logs, reverse proxy logs, WAF logs, application logs, APM traces, and infrastructure metrics for periods of abnormal latency, high Node.js CPU usage, event-loop delay, request timeouts, or 5xx responses. Focus on requests containing unusually long, malformed, or repetitive Content-Type or Content-Disposition headers, especially if many such requests came from the same source IPs, autonomous systems, user agents, or paths shortly before availability incidents. Look for spikes in 400, 408, 429, 499, 502, 503, and 504 responses, worker restarts, container restarts, health-check failures, and load balancer target failures. Because ReDoS exploitation may leave no file-system artifact and does not require a dropped payload, detection is primarily behavioral: correlate suspicious header patterns with CPU saturation, event-loop lag, garbage collection pressure, and request backlog growth. Also search dependency inventories and SBOMs to determine whether vulnerable versions were deployed during any outage window.

• node_modules/@hapi/content/package.json
• "@hapi/content"
• "@hapi/content": "6.0.0"
• "@hapi/content": "^6.0.0"
• "@hapi/content": "~6.0.0"
• Content-Disposition:
• Content-Type:

What your security team should do

• Inventory all applications, containers, and serverless packages that include @hapi/content directly or transitively.
• Prioritize remediation for internet-facing Node.js services and APIs that parse inbound HTTP request headers.
• Upgrade @hapi/content to 6.0.1 or later and redeploy all affected runtime artifacts.
• Add or verify controls for maximum HTTP header size, malformed header rejection, request timeout, and rate limiting at the edge.
• Monitor for bursts of requests with unusually long or malformed Content-Type or Content-Disposition headers, especially when correlated with CPU saturation or event-loop lag.
• Add dependency scanning or SBOM policy checks to prevent vulnerable @hapi/content versions from being reintroduced.
• Because the CVE is not currently in KEV and EPSS is low, handle as availability-risk patching rather than emergency incident response unless suspicious traffic or outages are observed.