multer CVE-2026-88932

Exploitation requires multer version 2.2.0 or 2.3.0 with the DiskStorage engine configured (the default when a destination path is supplied). The vulnerable endpoint must be reachable by the attacker without authentication (PR:N per CVSS). The race condition is timing-sensitive - the attacker must abort the connection after a disk write has been initiated but before multer's cleanup routine processes it - however this window is reliably triggerable by aborting at a predictable point in the upload stream. Memory storage (MemoryStorage) configurations are NOT vulnerable. Rate limiting, request size caps, or connection throttling at a reverse proxy layer reduces but does not eliminate the attack surface. No session token, API key, or valid credentials are required.

The CVSS 5.3 Medium score (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) accurately reflects the attack profile: fully remote, unauthenticated, low complexity, but with only limited availability impact because disk exhaustion is gradual rather than instantaneous. No KEV listing exists and no public exploit or POC has been identified at time of analysis, so EPSS-equivalent risk remains low in practice. The primary real-world concern is shared-disk deployments where the upload partition is also used by the OS or database - in such scenarios, A:L understates the blast radius. Even a mid-sized municipal IT team in leszno running a Node.js upload service on a shared volume should treat this as a low-to-medium priority patch, particularly if rate limiting is already in place on upload endpoints. The absence of confidentiality or integrity impact, combined with no confirmed active exploitation, makes this a routine patch-cycle item rather than an emergency response trigger.

An attacker identifies a public Node.js/Express endpoint using multer disk storage and repeatedly initiates multipart/form-data POST requests, sending just enough data to trigger a disk write before sending a TCP RST or closing the connection to abort the upload. Because multer's abort cleanup completes before the asynchronous write finishes, each cycle deposits one orphaned file in the upload directory. By scripting hundreds of such requests per minute, the attacker can fill the target disk partition within minutes to hours depending on upload chunk size and disk capacity, rendering the application and potentially co-located services unavailable.