CVE-2026-88932

What it actually does

multer 2.2.0–2.3.0 disk-storage handling fails to delete files whose writes finish after abort cleanup has already run. Each aborted multipart/form-data upload can therefore leave an orphaned file on disk, leaking storage until the volume is exhausted and the process or host can no longer accept writes (availability impact only; no confidentiality or integrity loss).

Why it matters to the business

Public or otherwise unauthenticated upload endpoints can be driven into disk-full denial of service, stopping legitimate uploads and potentially crashing or hanging Node.js services that share the same volume (including Red Hat Ansible Automation Portal and Red Hat Developer Hub components that bundle the library). EPSS is low and flat (~0.53% over 30 days), the issue is not in KEV, exploit maturity is none, and there is no reported ransomware use, so mass exploitation risk is limited—but a successful fill still causes an outage. The flaw has been public for about 28 days, so patch windows should already be closing.

How an attack unfolds

An unauthenticated remote attacker locates an HTTP endpoint that uses affected multer disk storage, starts a multipart upload, and aborts the connection mid-transfer so that post-cleanup writes are not removed. Repeating start-and-abort cycles accumulates orphaned files until free space is gone and the service fails. No credentials, special privileges, or user interaction are required; no named threat actors are associated with this CVE.

How to fix it

Upgrade multer to 2.4.0 or later in all Node.js services that handle multipart uploads. For Red Hat redistributions, apply RHSA-2026:76788: ansible-automation platform/automation-portal:1790256405, rhdh/red-hat-developer-hub-backstage-plugin orchestrator-backend:1791251282, and rhdh/rhdh hub-rhel9:1791311495. Until patched, restrict or disable unauthenticated disk-backed uploads, impose strict request size and rate limits, isolate upload directories on a dedicated quota-limited volume, and remove leftover files from upload destinations.

How to confirm the fix worked

Confirm installed multer is 2.4.0+ (or the RHSA-2026:76788 package builds above). After upgrade, abort in-flight disk-storage uploads under test and verify no new files remain in the configured destination or OS temp directory. Inventory application lockfiles and container images for multer 2.2.0–2.3.0, and watch disk usage on upload volumes for unexpected growth.

Typical attack path

1. Find a reachable HTTP endpoint that accepts multipart/form-data through multer configured for disk storage.
2. Start an upload and abort the connection before multer finishes handling the request.
3. Repeat aborted uploads so leftover files accumulate on the upload volume.
4. Continue until disk space is exhausted and the application or host becomes unavailable.

How to detect it

There are no public in-the-wild campaigns or named actors for this issue; look for precursor abuse rather than a unique payload. Review reverse-proxy, load-balancer, and application access logs for bursts of short-lived or client-aborted POST/PUT requests with Content-Type multipart/form-data to upload routes. Correlate with host metrics: shrinking free space, inode exhaustion, and sudden growth of files in multer destinations or the process temp directory. Node.js/multer error logs around aborted requests (client abort, ECONNRESET, EPIPE) coinciding with new files that have no matching completed upload record are the strongest artifact. Compare filesystem snapshots before and after traffic spikes to find orphaned files whose timestamps cluster with aborted requests.

• Content-Type: multipart/form-data
• client aborted
• ECONNRESET
• EPIPE
• multer
• unexpected end of form

What your security team should do

• Patch multer to 2.4.0+ or apply RHSA-2026:76788 on Ansible Automation and Developer Hub images as the primary fix.
• Inventory every service that accepts multipart/form-data and confirm disk-storage multer versions.
• Until patched, rate-limit and size-limit unauthenticated uploads and put upload directories on quota-capped volumes.
• Alert on rapid growth of files or shrinking free space in upload and temp directories.
• After patching, purge pre-existing orphaned upload files and re-enable normal capacity monitoring.