CVE-2026-111181 in body-parser
Summary
by MITRE • 10/22/2026
body-parser is body parsing middleware for Node.js and Express. In versions before 1.20.9 and in versions from 2.0.0 before 2.4.0, a single request can crash any application using body-parser with default options. When a request carries a Content-Encoding such as gzip, body-parser pipes it into a decompression stream and, after reading the body, leaves that stream with no error listener. A payload of one valid compressed frame followed by trailing bytes decodes and the application responds normally, but the trailing bytes then reach the already-finished decoder, which emits an error that is re-thrown as an uncaught exception and terminates the process. No matching route is required because body parsing runs before routing, so any endpoint that parses a body is affected. The issue is fixed in body-parser 2.4.0 and 1.20.9, and users should upgrade to one of those versions or later. As a workaround, disable request-body inflation (set the body-parser inflate option to false) so encoded requests are rejected before any decompression stream is created.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in the body-parser middleware for Node.js and Express represents a critical reliability issue stemming from improper error handling within asynchronous data streams. Body-parser serves as essential infrastructure for web applications, responsible for parsing incoming HTTP request bodies into JavaScript objects or buffers that application logic can consume. In versions prior to 1.20.9 and in the second major release line before version 2.4.0, a specific flaw exists in how the middleware manages compressed payloads. When an incoming request includes a Content-Encoding header indicating compression such as gzip, body-parser initiates a decompression stream to inflate the data back into its original format. The core technical failure occurs after this inflation process completes; specifically, the code fails to attach an error listener to the underlying zlib or similar decompression stream object. This omission violates standard Node.js best practices for handling asynchronous streams, where unhandled errors on readable or transformable streams can propagate unexpectedly and terminate the event loop if not properly caught.
The operational impact of this flaw is severe because it allows a single maliciously crafted request to cause a denial of service by crashing the entire application process. An attacker needs only to send one HTTP POST request with an inflated Content-Encoding header, such as gzip or deflate. The payload must consist of a valid compressed frame followed immediately by trailing bytes that are not part of the compression stream structure. When body-parser processes this input, it successfully decompresses the initial valid portion and allows the application logic to proceed normally, potentially sending a response back to the client. However, once the main parsing flow finishes, the remaining trailing bytes continue to be processed by the already-finished or closed decoder object. This action triggers an internal error event on the stream which is not caught due to the missing listener. Consequently, Node.js throws this as an uncaught exception, leading to immediate process termination and a complete service outage for all users until the application is restarted.
This vulnerability affects any endpoint that utilizes body-parser middleware because request parsing occurs at a lower level in the HTTP handling pipeline than route matching. Therefore, attackers do not need to know specific URL paths or exploit logic within individual routes; simply targeting any active endpoint with a properly formatted compressed payload is sufficient to trigger the crash. This characteristic classifies the issue as a resource exhaustion vulnerability where availability is compromised through simple input manipulation rather than complex exploitation techniques. From a classification perspective, this aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions and CWE-209: Generation of Error Message Containing Sensitive Information if the crash logs expose stack traces to users, though primarily it is an availability issue related to improper resource management. In terms of adversarial tactics, this behavior resembles aspects of ATT&CK technique T1499: Endpoint Denial of Service, specifically where a single action causes system instability or unavailability without requiring privilege escalation or lateral movement.
Mitigation strategies focus on either upgrading the software dependency or applying configuration-level workarounds to prevent the vulnerable code path from executing. The primary and most robust solution is to upgrade body-parser to version 1.20.9 or later, which includes patches that properly attach error handlers to decompression streams ensuring that any malformed data results in a controlled HTTP error response rather than an uncaught exception. For environments where immediate upgrading is not feasible due to dependency conflicts or testing requirements, administrators can disable request body inflation by setting the inflate option to false within the body-parser configuration. This workaround prevents the middleware from attempting to decompress incoming payloads, thereby rejecting any requests with Content-Encoding headers before a vulnerable stream object is instantiated. While this reduces functionality for clients sending compressed data, it effectively neutralizes the crash vector and restores service stability until a permanent patch can be deployed.