CVE-2026-77063: File Size Limit Bypass via Asynchronous Race Condition in Multer

The Node.js library multer is a widely used middleware designed to handle multipart/form-data uploads. It typically acts as an abstraction layer built on top of busboy, which performs the low-level parsing of the incoming stream. Within standard workflows, developers rely on multer to validate file properties (such as file type) and enforce structural constraints (such as maximum file size) before storing the content.

The vulnerability, classified under CWE-362, resides in how multer coordinates the verification steps of user-supplied files against its stream processing loop. When a custom asynchronous filtering hook (fileFilter) is defined, the execution flow yields control back to the Node.js event loop. This transition introduces an asynchronous gap in the execution context.

During this gap, the network parser continues to process the file stream. If the stream exceeds the configured maximum size, the underlying parser fires a limit event. Because the event-handling hook for this size threshold is not yet attached during the asynchronous validation window, the event is lost. Consequently, the request completes without raising an error, bypassing intended size validation constraints.

To understand the root cause of the vulnerability, one must examine the event-driven stream parsing mechanism of the Node.js event loop. The low-level multipart parser, busboy, processes the incoming TCP stream and synchronously fires a file event as soon as a new file field is discovered. Along with this event, it passes a Readable stream representing the file payload.

Under normal circumstances with a synchronous fileFilter, the execution thread remains in the same tick of the event loop. This allows multer to evaluate the file and immediately register its internal listener for the limit event on the file stream. The registration of this listener occurs before any data is consumed from the stream, ensuring that if the threshold is breached, the event handler successfully catches the signal.

However, when the developer provides an asynchronous fileFilter (such as checking database records or validating cryptographic signatures), the execution yields. While the Promise resolves, the incoming data stream is still being ingested by busboy. If the data volume breaches the limits.fileSize threshold within this pending state, the parser fires the limit event synchronously.

Because the listener has not yet been registered, the event is emitted into an empty listener array and silently discarded. Once the asynchronous fileFilter resolves and the registration occurs, the event has already passed. The application continues processing, assuming the file did not violate the size limit constraint.

The vulnerability was resolved in version 2.3.0 via commit ab6aeae650328cf31799dcfa4c3e116ba8faaacc. The core of the fix is located in the file lib/make-middleware.js where the registration timing of the stream listeners was re-architected.

Below is an annotated comparison of the vulnerable vs. patched code path:

// VULNERABLE PATH IN lib/make-middleware.js
busboy.on('file', function (fieldname, fileStream, { filename, encoding, mimeType }) {
  // ... initialization code
  if (fieldname == null) return abortWithCode('MISSING_FIELD_NAME')
 
  // Async fileFilter is executed here
  setup.fileFilter(req, file, function (err, keep) {
    if (err) return abortWithError(err)
    if (!keep) return fileStream.resume()
 
    // The 'limit' listener is attached ONLY AFTER the async filter returns
    fileStream.on('limit', function () {
      aborting = true
      abortWithCode('LIMIT_FILE_SIZE', fieldname)
    })
  })
})

In the patched version, the developers decoupled the creation of the size threshold listener from the resolution of the asynchronous verification. The listener is now established synchronously within the initial event loop tick:

// PATCHED PATH IN lib/make-middleware.js
busboy.on('file', function (fieldname, fileStream, { filename, encoding, mimeType }) {
  var pendingWritesIncremented = false
  var aborting = false
  var accepted = false
  var fileSizeLimitReached = false
 
  // Synchronously register the 'limit' listener to avoid race conditions
  fileStream.on('limit', function () {
    fileSizeLimitReached = true
    if (accepted) {
      aborting = true
      abortWithCode('LIMIT_FILE_SIZE', fieldname)
    }
  })
 
  setup.fileFilter(req, file, function (err, keep) {
    if (err) return abortWithError(err)
    if (!keep) return fileStream.resume()
 
    // Evaluate if the limit was reached while waiting for the filter to resolve
    if (fileSizeLimitReached) {
      appender.removePlaceholder(placeholder)
      return abortWithCode('LIMIT_FILE_SIZE', fieldname)
    }
 
    accepted = true
    // ... standard write handling continues
  })
})

By leveraging state-tracking flags (fileSizeLimitReached and accepted), the updated architecture ensures that even if the limit event occurs while the asynchronous call is unresolved, the state is persisted and handled immediately upon execution resumption.

Exploitation of CVE-2026-77063 requires three primary conditions. First, the application must be running a version of multer below 2.3.0. Second, it must configure a custom, asynchronous implementation of the fileFilter function. Third, it must set a finite fileSize limit in its validation parameters.

An attacker initiates exploitation by crafting a multi-part form-data HTTP request containing a payload larger than the application-defined fileSize limit. The attack is highly reliable when the network connection is fast, as this ensures the size limit is exceeded during the execution window of the server-side asynchronous function.

The timeline of the race condition can be visualized as follows:

When the upload completes, the server does not return a LIMIT_FILE_SIZE error. Instead, it processes the request with a 200 OK status. Although the underlying engine truncates the file to the maximum size allowed, the application logic is forced to handle partial, invalid, or corrupted files without being alerted to the validation failure.

The CVSS v3.1 score of 3.7 (Low) reflects the limited security impact of this vulnerability due to structural mitigations built into the underlying components. While the file limit validation check fails, the underlying busboy parser continues to truncate the file at the defined byte threshold. Consequently, the attack cannot be used to trigger uncontrolled memory exhaustion or fill server disks with arbitrary data.

The real impact is situated in application-level data integrity and functional bypasses. Systems relying on the strict rejection of over-sized files to avoid processing errors will accept truncated files. For example, if an application enforces a 10MB limit on image uploads, an attacker could upload an over-sized or malformed image that is processed as a truncated file, potentially causing downstream processing libraries to fail, hang, or execute logic errors.

Additionally, applications that expect atomic write operations (where a file is either completely valid and stored, or rejected entirely) will suffer from corrupted application states. This can lead to database inconsistencies, where metadata records point to broken or incomplete file resources on disk.

The primary recommendation to mitigate CVE-2026-77063 is to upgrade the multer dependency to version 2.3.0 or higher. This upgrade ensures that size limit listeners are registered synchronously, correcting the race condition across all asynchronous processing paths.

For environments where upgrading is not immediately possible, developers must refactor the file filter hooks to run synchronously. Any validation requiring asynchronous resources (such as database lookups, third-party API queries, or hash computations) should be moved out of the multer execution flow. The application should instead validate the file after the middleware has successfully processed and temporarily stored the payload, deleting the file manually if downstream checks fail.

To detect vulnerable code patterns across enterprise codebases, security teams can employ Static Application Security Testing (SAST) rules. The following Semgrep pattern identifies multer initializations that integrate both file size limits and asynchronous validation handlers:

rules:
  - id: multer-async-filefilter-race
    languages: [javascript, typescript]
    severity: WARNING
    message: "Detected an asynchronous fileFilter used with a configured fileSize limit. This setup is vulnerable to size-limit bypass (CVE-2026-77063)."
    patterns:
      - pattern-either:
          - pattern: |
              multer({
                ...,
                fileFilter: async function (...) { ... },
                ...,
                limits: { ..., fileSize: $VAL, ... }
              })
          - pattern: |
              multer({
                ...,
                fileFilter: (...) => { ... return new Promise(...); },
                ...,
                limits: { ..., fileSize: $VAL, ... }
              })