EUVD-2026-42873Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable, unauthenticated, zero-complexity attack; A:H because a single request can fully exhaust inodes, disk, and memory, crashing the application.
Primary rating from Vendor (6b3ad84c-e1a6-4bf7-a703-f496b71e49db).
CVSS VectorVendor: 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
Lifecycle Timeline
2DescriptionCVE.org
Plug.Parsers.MULTIPART, the multipart request-body parser used to handle file uploads and multipart forms, does not enforce its :length budget against all consumed resources, allowing an unauthenticated remote attacker to cause denial of service. The parser charges the :length limit only for part body bytes; part header bytes are never counted, and a part with an empty body costs zero.
Because every part whose Content-Disposition carries a non-empty filename creates a fresh temporary file (via Plug.Upload) and retains a Plug.Upload struct for the duration of the request, an attacker can send a single request composed of many empty-body file parts. Such a request stays well under the configured :length limit (8,000,000 bytes by default) while creating one temporary file per part, leading to inode and disk exhaustion and unbounded memory growth. Any application using Plug.Parsers with the :multipart parser is affected, and no authentication is required, only reachability of a multipart endpoint over HTTP.
This vulnerability is associated with program files lib/plug/parsers/multipart.ex and program routines Plug.Parsers.MULTIPART.parse_multipart/2, Plug.Parsers.MULTIPART.parse_multipart_headers/5, Plug.Parsers.MULTIPART.parse_multipart_body/4, and Plug.Parsers.MULTIPART.parse_multipart_file/4.
This issue affects plug: from 1.4.0 before 1.16.6, from 1.17.0 before 1.17.4, from 1.18.0 before 1.18.5, from 1.19.0 before 1.19.5, and from 1.20.0 before 1.20.3.
AnalysisAI
Denial of service in Elixir's Plug library (versions 1.4.0 through 1.20.2) allows unauthenticated remote attackers to exhaust filesystem inodes, disk space, and server memory via a single crafted multipart HTTP request. The Plug.Parsers.MULTIPART component charges its configurable :length limit only against part body bytes, meaning part headers are never counted and parts with empty bodies cost exactly zero - yet each such part with a filename triggers creation of a Plug.Upload struct and a real temporary file on disk. No public exploit has been identified at time of analysis, though the technique is trivially reproducible from the description alone against any application exposing a multipart endpoint.
Technical ContextAI
Plug is the de facto HTTP middleware specification and toolkit for Elixir web applications; the Phoenix framework, which dominates Elixir web development, depends on it directly. The affected component, Plug.Parsers.MULTIPART (lib/plug/parsers/multipart.ex), handles multipart/form-data request bodies - the MIME format used for file uploads and rich form submissions. CWE-770 (Allocation of Resources Without Limits or Throttling) describes the root cause: the parser's resource accounting is incomplete. Per the description, the functions parse_multipart/2, parse_multipart_headers/5, parse_multipart_body/4, and parse_multipart_file/4 all participate in the flaw. The default :length limit of 8,000,000 bytes was intended to bound memory and disk consumption per request, but because part header bytes are excluded from this accounting and empty-body parts cost zero, the limit can be trivially bypassed. Each part with a non-empty Content-Disposition filename field creates a temporary file via Plug.Upload regardless of whether the body contains any data.
RemediationAI
Upgrade to a patched release: plug 1.16.6, 1.17.4, 1.18.5, 1.19.5, or 1.20.3, depending on your current minor line. Six upstream commits address the issue across affected branches: 0ee8afcc61, 56edca2ce3, 981597d3a4, cae360533, df97d3f17f, and f7effaed81 (https://github.com/elixir-plug/plug). The full advisory at https://github.com/elixir-plug/plug/security/advisories/GHSA-95qv-c9g9-rm63 should be consulted for branch-specific guidance. If an immediate upgrade is not possible, compensating controls include: placing a reverse proxy (nginx, Caddy) in front of the application configured to enforce a per-request maximum number of multipart parts (e.g., nginx client_max_body_size combined with limiting multipart field counts at the WAF layer) - note this adds operational complexity and may break legitimate large-form submissions; alternatively, requiring authentication before any multipart endpoint is reachable eliminates unauthenticated exploitation but does not protect against malicious authenticated users.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today