Cloudanix VulnDB

CVE-2026-12590

Low · 3.7

CVSS

3.7

EPSS

0.4%

Published

Jul 9, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A settings mistake in a widely used request-handling component can let attackers flood servers with huge uploads that overwhelm memory and processing power, leading to slowdowns or outages.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
Library
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

When body-parser is initialized with an invalid limit option (unparseable string or NaN), bytes.parse returns null and the request-body size enforcement is silently bypassed, allowing arbitrarily large payloads to be fully read into memory.

Why it matters to the business

Services may suffer denial-of-service outages or degraded performance from excessive memory and CPU consumption when attackers submit oversized requests, increasing operational costs and risking availability SLAs.

How an attack unfolds

An attacker locates an HTTP endpoint that uses body-parser with a misconfigured or invalid limit value. They craft and send a single request containing a multi-gigabyte body; because the size check is disabled at construction time, the parser accepts the entire payload, exhausting server resources and causing slowdown or crash.

How to fix it

Upgrade body-parser to version 1.20.6 (1.x) or 2.3.0 (2.x). Validate that any supplied limit value parses to a finite positive number before passing it to the parser constructor; reject invalid values at application startup.

How to confirm the fix worked

Inspect package.json and installed module versions to confirm body-parser >= 1.20.6 or >= 2.3.0. Attempt to instantiate the parser with an invalid limit string and verify that a clear error is thrown instead of silent fallback.

Typical attack path

  1. Map application routes that invoke body-parser middleware
  2. Confirm or induce an invalid limit configuration
  3. Transmit an HTTP request with an extremely large body
  4. Monitor for high memory/CPU usage or service unavailability

How to detect it

Review web-server and application logs for sudden spikes in memory or CPU usage tied to individual requests; correlate with access logs showing unusually large Content-Length headers on POST/PUT methods.

What your security team should do

  • Upgrade body-parser to 1.20.6 or 2.3.0 across all services within the next sprint
  • Add startup-time validation that rejects null or non-finite limit values
  • Enable request-size monitoring and alerting on memory/CPU anomalies
  • Audit all body-parser usages for explicit, correctly-typed limit settings

The record

Impact: In body-parser versions prior to 1.20.6 (1.x line) and 2.3.0 (2.x line), when the parser is configured with an invalid limit option value such as an unparseable string or NaN, bytes.parse returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. Patches: This issue is fixed in body-parser 1.20.6 and 2.3.0. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement, while null and undefined continue to fall back to the default limit of 100kb. Workarounds: Validate the limit value before passing it to body-parser. For example, parse the value at startup and reject any configuration where the result is null or a non-finite number.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities