Jun 17, 2026·6 min read·85 visits
A Denial of Service vulnerability exists in the multer library when parsing deeply nested bracket notations in form field names, leading to application crash or CPU exhaustion.
CVE-2026-5079 is a high-severity Denial of Service (DoS) vulnerability in the Node.js package 'multer'. The vulnerability resides in how its internal dependency, 'append-field', processes deeply nested bracket structures in multipart form field names. If an attacker submits a field name with an excessive number of nested brackets, the parsing process crashes the Node.js runtime environment or exhausts system resources, causing a complete denial of service.
CVE-2026-5079 defines a high-severity Denial of Service (DoS) vulnerability in the Node.js package multer. This package serves as a middleware for handling multipart/form-data uploads within the Express web framework. The vulnerability originates in the manner in which the package processes bracket notation syntax within form field names.
Applications that accept file or field uploads via multer expose a public-facing attack surface. By processing unauthenticated incoming HTTP requests, these endpoints permit input that triggers deep object parsing. The internal parsing mechanism resolves structured inputs without enforcing maximum depth limitations on property nesting.
This flaw represents a classic uncontrolled resource consumption issue classified under CWE-400. Because the vulnerability is exploitable by unauthenticated remote actors via a single malformed request, it poses a direct risk to service availability. The V8 JavaScript engine's thread model makes the entire process vulnerable to thread-blocking behavior when parsing these nested fields.
The technical root cause of CVE-2026-5079 lies in the dynamic parsing of structured keys inside the append-field library, which multer uses as a dependency. When a user submits standard multipart forms, key-value pairs may contain complex field names such as user[profile][address][street]. The parsing logic recursively traverses the field name string to build equivalent JavaScript objects within the req.body context.
Prior to the release of patched versions, the parser lacked a mechanism to restrict the depth of nested keys. When encountering consecutive open brackets [, the engine allocates new objects or arrays recursively. The lack of a predefined termination depth allows an attacker to supply a string containing thousands of nested dimensions.
This architecture results in two primary failure modes. First, the deep recursion eventually exceeds the maximum execution stack limit of the V8 engine, which triggers a RangeError: Maximum call stack size exceeded and terminates the process. Second, even if stack limits are not immediately hit, the overhead of creating and garbage-collecting thousands of nested structures consumes excessive CPU cycles and blocks the single-threaded event loop.
The vulnerability is resolved by introducing validation logic directly into the middleware generation sequence. This verification happens before calling appendField to construct the parsed objects.
// Vulnerable Code Path
// In lib/make-middleware.js, field names were passed directly to appendField without verification
function makeMiddleware (setup) {
// ... parsing loop ...
busboy.on('field', function (fieldname, value, ahead) {
if (limits && Object.prototype.hasOwnProperty.call(limits, 'fieldNameSize')) {
if (fieldname.length > limits.fieldNameSize) return abortWithCode('LIMIT_FIELD_KEY')
}
// The vulnerability: fieldname is passed directly
appendField(req.body, fieldname, value)
})
}The fix introduces an explicit check that evaluates the nesting depth of the field name. This is done by counting the frequency of the open bracket character in the field string.
// Patched Code Path
// In lib/make-middleware.js, verifying field depth before calling appendField
function makeMiddleware (setup) {
// ... parsing loop ...
busboy.on('field', function (fieldname, value, ahead) {
if (limits && Object.prototype.hasOwnProperty.call(limits, 'fieldNameSize')) {
if (fieldname.length > limits.fieldNameSize) return abortWithCode('LIMIT_FIELD_KEY')
}
// Added check to restrict nesting depth
if (limits && Object.prototype.hasOwnProperty.call(limits, 'fieldNestingDepth')) {
if (fieldname.split('[').length - 1 > limits.fieldNestingDepth) {
return abortWithCode('LIMIT_FIELD_NESTING', fieldname)
}
}
appendField(req.body, fieldname, value)
})
}This check splits the field name string by the [ delimiter and subtracts one to determine the exact nesting level. If this level exceeds the user-configured limit, the transaction halts and invokes abortWithCode with the new error code LIMIT_FIELD_NESTING.
An attacker can exploit this vulnerability by transmitting a single HTTP POST request to any endpoint utilizing the affected multer middleware. The request payload must use the multipart/form-data encoding. The malicious payload targets a standard text field instead of a file field, specifying a deeply nested bracket structure inside the name attribute.
No authentication is required to interact with the upload endpoint, making the vulnerability accessible from any network that can reach the application. A typical attack vector uses a payload containing thousands of nested bracket patterns.
POST /upload HTTP/1.1
Host: target-server
Content-Type: multipart/form-data; boundary=----Boundary
Content-Length: 300
------Boundary
Content-Disposition: form-data; name="a[b][c][d][e][f][g][h][i][j][k][l][m][n][o]...[z]"
exploit_payload
------Boundary--When the application processes this payload, the thread-blocking parsing operation begins. In environments without global error handlers, the resulting RangeError causes the process to exit immediately. Even in resilient environments, the single-threaded event loop becomes unresponsive during the parsing attempt, leading to a complete service outage.
The security impact of CVE-2026-5079 is characterized primarily as a complete loss of service availability. In the Node.js ecosystem, applications operate on a single thread. When this thread is blocked or crashed by an unhandled exception, all concurrent and subsequent client connections fail.
Because multer is a foundational middleware across many enterprise Express applications, this vulnerability exposes a broad range of web services to disruption. The CVSS v3.1 base score is 7.5, with high impact on availability, low attack complexity, and no privilege requirements.
The impact is limited to the local process handling the request. There is no direct risk of data exposure, privilege escalation, or unauthorized modifications to the filesystem. However, the ease with which an unauthenticated remote attacker can trigger the crash increases the operational risk of using unpatched versions.
Remediation requires upgrading the multer package and configuring the library to enforce nesting boundaries. To resolve the vulnerability, applications must migrate to version 2.2.0 (for the 2.x release line) or version 3.0.0-alpha.2 (for the 3.x pre-release line).
npm install multer@latestSimply upgrading the package is insufficient to secure the application. The default value for limits.fieldNestingDepth is set to Infinity to preserve backward compatibility. Developers must explicitly define a strict, low threshold for nesting depth when initializing the middleware.
const upload = multer({
dest: 'uploads/',
limits: {
fieldNestingDepth: 3 // Restricts object nesting to a safe limit
}
});For environments where upgrading is delayed, web application firewalls (WAFs) or reverse proxies can implement input validation rules. For example, a rule can scan the Content-Disposition header in multipart requests and block messages containing more than a predefined number of [ characters.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
multer expressjs | >= 1.0.0 < 2.2.0 | 2.2.0 |
multer expressjs | == 3.0.0-alpha.1 | 3.0.0-alpha.2 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-400 |
| Attack Vector | Network |
| CVSS v3.1 | 7.5 |
| EPSS Score | 0.00278 |
| Impact | Denial of Service (DoS) |
| Exploit Status | poc |
| KEV Status | Not Listed |
The program does not properly control the allocation and maintenance of a limited resource, enabling an actor to influence the amount of resources consumed.
A constellation of five distinct security flaws (F1 through F5) in `@zereight/mcp-gitlab` prior to version 2.1.30 allows unauthenticated remote access, read-only policy bypasses, DNS rebinding, and denial-of-service via session exhaustion.
A critical security vulnerability has been identified in the @zereight/mcp-gitlab implementation of the Model Context Protocol (MCP) server. Prior to version 2.1.30, the server lacks HTTP Host and Origin header validation on its Streamable HTTP transport interface (/mcp). This security omission permits remote attackers to bypass the Same-Origin Policy (SOP) via a DNS Rebinding attack. Under this vector, an attacker can route malicious API requests to the victim's local or internal MCP server, thereby gaining unauthorized control over the victim's GitLab account and resources.
A critical Server-Side Request Forgery (SSRF) vulnerability in @zereight/mcp-gitlab allows attackers to leak sensitive GitLab Private-Tokens by supplying an arbitrary external hostname via the X-GitLab-API-URL header when dynamic routing is enabled.
A critical memory leak vulnerability exists in the server-side DigestAuth middleware of the http4s library. Due to a logical inversion in the stale-nonce clean-up routine, the internal cache fails to evict stale nonces while prematurely purging fresh ones. Unauthenticated remote attackers can exploit this behavior by repeatedly prompting the server for authentication challenges, leading to unbounded memory consumption and application crashes via a java.lang.OutOfMemoryError.
An incomplete security fix in Shopper prior to version 2.9.2 exposes a Broken Function Level Authorization (BFLA) vulnerability in the Media component. Low-privileged administrative users with 'browse_products' permissions can bypass role-based access control policies to execute the 'store' action and modify product media.
A critical authorization bypass and insecure direct object reference (IDOR) vulnerability was discovered in Shopper, a Headless e-commerce Admin Panel. Due to missing authorization chains on table actions and the lack of a locked property on the collection state model, authenticated low-privilege staff can detach products from arbitrary collections.