How Denial of Service via Deeply Nested Field Names Happens in Node.js Multer and How to Fix It

Introduction

In the backend of this application, a high-severity Denial of Service vulnerability was lurking in backend/package-lock.json. The culprit? An outdated version of multer (version 2.0.2), the widely-used Node.js middleware for handling multipart/form-data uploads. This vulnerability, tracked as CVE-2026-5079, could have allowed attackers to crash the server by sending specially crafted requests with deeply nested field names—without even needing to authenticate.

The backend/package.json specified multer as a direct dependency:

"multer": "^2.0.2",

This version lacked critical safeguards against maliciously structured form data, creating a significant attack surface for any endpoint accepting file uploads or form submissions.

The Vulnerability Explained

What Makes Nested Field Names Dangerous?

Multer parses multipart form data, including field names like user[profile][settings][theme]. In vulnerable versions, there was no limit on how deeply these field names could be nested. An attacker could send a request with field names containing hundreds or thousands of nested brackets:

field[a][b][c][d][e][f][g][h][i][j][k][l][m][n][o][p][q][r][s][t]...

When multer attempts to parse this deeply nested structure, it recursively builds JavaScript objects. With extreme nesting depths, this process:

1. Consumes excessive CPU cycles processing the recursive structure
2. Exhausts memory creating deeply nested object hierarchies
3. Blocks the event loop, preventing the server from handling other requests

Attack Scenario Specific to This Application

Consider this backend application accepting file uploads. An attacker could:

1. Identify any endpoint using multer (file upload forms, profile picture uploads, document submissions)
2. Craft a malicious multipart request:

POST /api/upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="data[a][b][c][d][e]...[repeated 1000 times]..."

malicious
------WebKitFormBoundary--

1. Send multiple concurrent requests to amplify the impact
2. The server becomes unresponsive, denying service to legitimate users

The attack requires no authentication and minimal bandwidth—a small payload can cause disproportionate resource consumption.

Real-World Impact

For this application, the consequences could include:

• Complete service outage affecting all users
• Cascading failures if other services depend on this backend
• Infrastructure costs from auto-scaling triggered by the attack
• Reputation damage from service unavailability

The Fix

The fix is straightforward but critical: upgrade multer from version 2.0.2 to 2.2.0.

Before (Vulnerable)

// backend/package.json
"multer": "^2.0.2",

After (Fixed)

// backend/package.json
"multer": "^2.2.0",

The corresponding backend/package-lock.json was also updated to lock the new version and its dependency tree.

What Changed in Multer 2.2.0?

The patched version implements:

1. Depth limits on nested field name parsing
2. Early termination when parsing encounters excessive nesting
3. Configurable thresholds allowing developers to set appropriate limits for their use case

These changes ensure that even maliciously crafted requests are handled safely without exhausting server resources.

Why Both Files Changed

• backend/package.json: Updates the version constraint to require 2.2.0+
• backend/package-lock.json: Locks the exact resolved version and updates the dependency tree, ensuring consistent installations across environments

Prevention & Best Practices

1. Keep Dependencies Updated

Regularly audit and update your dependencies. Use tools like:

npm audit
npm outdated

2. Implement Defense in Depth

Even with updated dependencies, add additional protections:

const multer = require('multer');

const upload = multer({
  limits: {
    fieldNameSize: 100,     // Max field name size
    fieldSize: 1024 * 1024, // Max field value size (1MB)
    fields: 10,             // Max number of non-file fields
    fileSize: 5 * 1024 * 1024, // Max file size (5MB)
    files: 5,               // Max number of files
    parts: 20               // Max number of parts (fields + files)
  }
});

3. Use Rate Limiting

Protect upload endpoints with rate limiting:

const rateLimit = require('express-rate-limit');

const uploadLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100 // limit each IP to 100 requests per window
});

app.use('/api/upload', uploadLimiter);

4. Monitor for Anomalies

Implement monitoring to detect unusual patterns:
- Sudden spikes in request processing time
- Memory usage anomalies
- High CPU utilization on upload endpoints

Key Takeaways

• Multer versions before 2.2.0 are vulnerable to DoS via nested field names—upgrade immediately if you're using an older version
• Small payloads can cause massive resource consumption when parsing logic lacks depth limits
• The backend/package-lock.json file is a security-critical artifact—include it in vulnerability scans
• Defense in depth matters: even with patched dependencies, configure explicit limits on multer options
• Automated dependency scanning catches vulnerabilities that manual code review might miss

How Orbis AppSec Detected This

• Source: Multipart form data field names from incoming HTTP requests
• Sink: Multer's field name parsing logic in the vulnerable version 2.0.2
• Missing control: No depth limit on nested field name parsing, allowing unbounded recursion
• CWE: CWE-400 (Uncontrolled Resource Consumption)
• Fix: Upgraded multer from 2.0.2 to 2.2.0, which implements parsing depth limits

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-5079 demonstrates how a seemingly innocent feature—nested field names in form data—can become a severe security vulnerability when proper limits aren't enforced. The fix was simple: a version bump from multer 2.0.2 to 2.2.0. But the lesson is broader: dependency management is security management.

Keep your dependencies updated, configure explicit limits even when using patched versions, and leverage automated security scanning to catch vulnerabilities before attackers do. A few minutes of proactive maintenance can prevent hours of incident response.

References

• CWE-400: Uncontrolled Resource Consumption
• OWASP Denial of Service Cheat Sheet
• Multer npm Documentation
• Semgrep Rules for DoS Vulnerabilities
• fix: upgrade multer to 2.2.0, 3.0.0-alpha.2 (CVE-2026-5079)