CVE-2026-56814 in plug
Summary
by MITRE • 07/10/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability in Plug.Parsers.MULTIPART represents a critical denial of service weakness that exploits the improper enforcement of resource consumption limits during multipart request processing. This flaw resides in the core parsing logic responsible for handling file uploads and form data submissions within web applications built using the elixir plug framework. The technical implementation fails to account for all consumed resources when evaluating the configured :length budget, creating a fundamental mismatch between resource tracking and actual system impact.
The root cause stems from how the parser handles part header versus body byte accounting during multipart processing. Specifically, the system only charges the configured :length limit against part body bytes while completely ignoring part header bytes in the budget calculation. This design flaw becomes particularly dangerous when combined with the behavior of Plug.Upload which creates a fresh temporary file for every part that contains a non-empty filename field. The consequence is that an attacker can construct requests with numerous empty-body parts, each triggering file system operations without consuming significant byte count toward the configured limit.
This vulnerability operates under the ATT&CK framework as a resource exhaustion attack pattern, specifically targeting system resources through manipulation of input processing logic. The weakness aligns with CWE-400 which describes "Uncontrolled Resource Consumption" and more specifically CWE-1321 which addresses "Improper Enforcement of File Name Length Limitations". The attack requires only network reachability to a vulnerable multipart endpoint without any authentication requirements, making it particularly dangerous for publicly accessible web applications.
The operational impact of this vulnerability manifests through multiple system exhaustion vectors including inode depletion, disk space exhaustion, and unbounded memory growth. Each malicious part with a filename field triggers creation of temporary files that persist throughout the request lifecycle, consuming file system inodes and disk space rapidly. The default :length limit of 8,000,000 bytes provides inadequate protection since empty body parts contribute nothing to this budget while generating substantial system overhead through their associated file operations.
The affected code paths include multiple core routines within lib/plug/parsers/multipart.ex that handle different aspects of multipart parsing. The parse_multipart/2 function orchestrates the overall process, while parse_multipart_headers/5 and parse_multipart_body/4 manage individual component processing. The parse_multipart_file/4 routine specifically handles file creation operations that trigger the vulnerable behavior. All applications utilizing Plug.Parsers with the :multipart configuration are susceptible to this attack vector regardless of application complexity or security measures implemented at higher layers.
Mitigation strategies should focus on implementing proper resource accounting within the multipart parser logic and establishing stricter limits on file upload parameters. The most effective immediate solution involves upgrading to patched versions of the plug framework where version 1.16.6, 1.17.4, 1.18.5, 1.19.5, and 1.20.3 contain the necessary fixes that properly account for all consumed resources during multipart processing. Organizations should also consider implementing additional application-level controls including explicit limits on the number of file parts allowed in a single request, enforced maximum file sizes, and monitoring for unusual patterns in temporary file creation behavior.