CVE-2026-5079

What it actually does

CVE-2026-5079 is a network-exploitable denial-of-service vulnerability in multer, a Node.js middleware commonly used to process multipart/form-data uploads in Express applications. Affected versions parse bracket notation in multipart field names through the append-field dependency without enforcing a maximum nesting depth. An attacker can send a multipart request containing deeply nested field names, causing the application to allocate excessively deep object structures and consume large amounts of CPU and memory. The issue does not provide confidentiality or integrity impact, but it can exhaust application resources and make upload endpoints or the entire Node.js process unavailable.

Why it matters to the business

Applications that accept file uploads or multipart form submissions through affected multer versions can be disrupted by a single crafted unauthenticated HTTP request. Successful exploitation may cause degraded performance, process crashes, container restarts, autoscaling spikes, failed uploads, API downtime, and increased infrastructure cost. Because multer is widely used in Express-based Node.js services, organizations should treat externally reachable upload endpoints as priority exposure even though the vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score at this time.

How an attack unfolds

An attacker identifies an HTTP endpoint that accepts multipart/form-data and is handled by an affected multer version. The attacker then crafts a multipart request where one or more field names use extreme bracket nesting, such as repeated nested keys. When the vulnerable application receives the request, multer delegates field parsing to append-field, which recursively or iteratively builds nested JavaScript object structures without a depth limit. This consumes CPU and memory disproportionately to the attacker’s effort. If resource exhaustion is severe enough, the Node.js event loop becomes blocked, the process may run out of memory, and the service can become slow, crash, or restart. No authentication or user interaction is required if the upload endpoint is publicly reachable.

How to fix it

Upgrade multer to a patched version: use multer 2.2.0 or later for the 2.x line, or 3.0.0-alpha.2 or later if using the 3.x prerelease line. After upgrading, configure the new limits.fieldNestingDepth option to the smallest nesting depth required by the application’s legitimate form structure. As a partial workaround where immediate upgrade is not possible, set limits.fields to a reasonable maximum to reduce the number of multipart fields accepted per request; this lowers blast radius but does not fully prevent deeply nested single-field payloads. Also consider enforcing request body size limits at the reverse proxy, API gateway, load balancer, and application layer; applying route-level authentication where appropriate; rate-limiting upload endpoints; and rejecting multipart field names with excessive bracket nesting before they reach multer.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve multer to 2.2.0 or later, or 3.0.0-alpha.2 or later for prerelease users. Verify that applications using multer explicitly set limits.fieldNestingDepth to an application-appropriate value and that limits.fields, file size, field size, and total request size limits are configured. Use software composition analysis, npm audit-equivalent tooling, and lockfile review to identify affected versions across services. In a non-production environment, test representative multipart submissions to ensure legitimate forms still work, then send a controlled multipart request with excessive bracket nesting and confirm it is rejected quickly without abnormal CPU or memory growth. Review runtime metrics after deployment to confirm upload endpoints no longer trigger event-loop stalls, out-of-memory conditions, or process restarts under malformed multipart input.

Typical attack path

1. Reconnaissance: identify Express/Node.js endpoints that accept multipart/form-data, especially upload, import, profile, support attachment, or form submission routes.
2. Version targeting: infer or confirm that the application uses multer versions 1.0.0 through 2.1.1 or 3.0.0-alpha.1.
3. Payload creation: craft a multipart/form-data request containing field names with excessive bracket nesting depth.
4. Delivery: send the crafted request to the multipart endpoint; a single request may be sufficient depending on available resources and nesting depth.
5. Resource exhaustion: trigger excessive object allocation and parsing work in the Node.js process.
6. Service impact: cause high CPU, memory exhaustion, event-loop starvation, request timeouts, process crash, or repeated service restarts.

How to detect it

To determine whether exploitation may have already occurred, review web server, reverse proxy, API gateway, WAF, and application logs for multipart/form-data POST requests containing unusually long field names or repeated bracket notation. Focus on upload and form submission paths that showed request timeouts, HTTP 500/502/503/504 responses, elevated latency, or abrupt connection resets. Correlate suspicious requests with Node.js application telemetry such as CPU spikes, heap growth, garbage collection pressure, event-loop lag, out-of-memory errors, container restarts, Kubernetes OOMKilled events, PM2/systemd restarts, and autoscaling events. Inspect application error logs for parser failures or memory exhaustion near the time of suspicious multipart requests. If request bodies are not logged, use WAF, reverse proxy debug logs, packet capture, or retained request samples where legally and operationally appropriate to look for excessive bracket nesting in multipart field names. Because no public exploit campaign or named threat actor is currently associated with this issue, detection should focus on behavioral signs of malformed multipart parsing and resource exhaustion rather than actor-specific infrastructure.

• Content-Type: multipart/form-data
• name="a[a][a][a][a][a][a][a][a][a][a]
• name="field[][][][][][][][][][]"
• name="constructor[prototype]
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• ENOMEM
• Error: socket hang up
• upstream prematurely closed connection
• connect() failed (111: Connection refused) while connecting to upstream
• upstream timed out
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504
• OOMKilled
• Killed process node
• pm2 restart
• systemd[1]: node
• npm package multer version 1.
• npm package multer version 2.0.
• npm package multer version 2.1.1
• npm package multer version 3.0.0-alpha.1

What your security team should do

• Inventory all Node.js and Express applications that accept multipart/form-data and identify use of multer.
• Prioritize externally reachable upload or form submission endpoints for remediation.
• Upgrade affected multer deployments to 2.2.0 or later, or 3.0.0-alpha.2 or later for prerelease users.
• Configure limits.fieldNestingDepth to the minimum depth required by each application.
• Add or tighten multipart limits, including limits.fields, field size, file size, total request size, and gateway/proxy body-size limits.
• Deploy rate limiting and request anomaly detection for upload endpoints, especially unauthenticated routes.
• Search recent logs and telemetry for malformed multipart requests, unusual bracket-heavy field names, spikes in 4xx/5xx responses, request timeouts, high memory usage, garbage collection pressure, or Node.js out-of-memory crashes.
• Ensure process managers and container orchestrators restart failed services, but do not rely on restarts as the primary mitigation.
• Add regression tests for deeply nested multipart field names to prevent future reintroduction of unsafe parser behavior.