CVE-2026-5079: Partial fix for Multer multipart parser DoS

Vulnerability

CVE-2026-5079 describes a denial-of-service condition in Multer triggered by deeply nested bracket notation in multipart form field names. The issue is consistent with uncontrolled resource consumption during field-name parsing, where attacker-supplied names such as nested a[b][c]... structures can drive excessive CPU work or crash behavior. The upstream release notes visible in the compare view for v2.1.1...v2.2.0 add a new fieldNestingDepth limit and document it as a DoS mitigation, which strongly indicates the vulnerable path is field-name nesting rather than file payload size or file count.

The relevant security impact is request-driven parser exhaustion before application logic can safely reject the input. Because multipart field names are attacker-controlled and processed early, this is a low-complexity availability issue for services that accept uploads or multipart forms.

if (limits && Object.prototype.hasOwnProperty.call(limits, 'fieldNestingDepth')) {
  if (fieldname.split('[').length - 1 > limits.fieldNestingDepth) return abortWithCode('LIMIT_FIELD_NESTING', fieldname)
}

References: official patch compare, NVD record, CVE record.

Patch

The security-relevant code change in lib/make-middleware.js adds a pre-check on multipart field names. If the caller provides limits.fieldNestingDepth, Multer counts bracket nesting by splitting on '[' and aborts with LIMIT_FIELD_NESTING when the configured threshold is exceeded. The README in the same release documents the new option and explicitly recommends setting it to the minimum depth required by the application.

Documented behavior added in the release:

`fieldNestingDepth` | Max number of nesting levels for field names (e.g. `a[b][c]` has 2 levels) | Infinity

This release also includes separate robustness changes for orphan-file cleanup on aborted or malformed uploads, including tracking pendingFiles, removing both uploaded and in-progress files on error, and guarding disk storage with if (file.stream.destroyed) return. Those changes are useful hardening, but they are orthogonal to the CVE's parser resource-consumption root cause.

Review

Pros

• The patch introduces a direct control on the attacker-controlled dimension identified by the CVE: field-name nesting depth.
• The check executes early in middleware processing and fails closed with a dedicated error code, which is operationally useful for logging and policy enforcement.
• The mitigation is simple and cheap: counting '[' occurrences is low overhead compared with allowing deeper parser work.
• The README now gives concrete defensive guidance, linking the new limit to DoS prevention.
• Additional cleanup changes in the same release improve resilience for aborted/truncated uploads, reducing filesystem side effects during malformed request handling.

Cons

• The new protection is opt-in. The documented default is Infinity, so upgrading to v2.2.0 without configuration leaves the vulnerable behavior effectively unchanged for many deployments.
• The implementation is a threshold guard, not a parser redesign. It constrains one abusive input shape but does not demonstrate broader normalization or bounded parsing guarantees.
• The depth calculation is syntactic and based on fieldname.split('[').length - 1; while adequate for the documented bracket notation, it is not evidence of a comprehensive parser hardening strategy.
• The release diff and tests shown focus on orphan-file cleanup; no source snippet here shows regression tests specifically validating rejection of pathological nesting for this CVE path.

Verdict

Partial fix.

The patch addresses the reported attack vector by adding a configurable nesting-depth limit, but it does not secure existing users by default because fieldNestingDepth remains Infinity unless explicitly set. For operators who configure a sane bound, the mitigation is practical and likely effective against the disclosed deeply nested field-name DoS. For the ecosystem at large, however, the fix is incomplete as a default-safe remediation. Engineers adopting v2.2.0 should treat this as a required configuration change, not a drop-in silent fix.

Source-grounded conclusion based on the upstream compare and the vulnerability descriptions in NVD and CVE.