Elixir Plug EUVD-2026-30266

Exploitation requires the target application to use Plug.Parsers.MULTIPART parser in its connection pipeline to handle multipart/form-data requests, typically indicating file upload functionality. The vulnerable code path is only reached when processing Content-Type: multipart/form-data requests against endpoints configured to parse multipart bodies. Applications using only Plug.Parsers.JSON, Plug.Parsers.URLENCODED, or custom parsers are not exposed. Network access to the upload endpoint is required (AV:N), but no authentication (PR:N) or user interaction (UI:N) is needed per CVSS vector. The CVSS AT:P (Attack Requirements:Present) flag reflects this: while the vulnerability is present in all affected Plug versions, real-world exploitability depends on deployment configuration enabling multipart parsing. Default Plug installations do not automatically parse multipart bodies without explicit Plug.Parsers configuration. Limiting factors: some deployments may front Plug applications with reverse proxies (nginx, HAProxy) that enforce their own request size limits, potentially blocking malformed uploads before they reach Plug. However, proxies configured to stream request bodies without buffering will pass malicious requests through unchanged.

CVSS 4.0 score of 8.2 (High) reflects network attack vector (AV:N), low complexity (AC:L), no privileges required (PR:N), and high availability impact (VA:H). The AT:P (Attack Requirements:Present) modifier indicates specific conditions must exist, which the description confirms: the application must process multipart/form-data uploads. EPSS data not provided, but risk signals are mixed: no CISA KEV listing and no public exploit code identified, suggesting limited observed exploitation despite the conceptual simplicity of the attack. However, the attack requires only basic HTTP tools to craft malformed multipart requests, making it highly automatable once discovered. Real-world risk depends heavily on deployment context: internet-facing file upload endpoints processing untrusted multipart data are high-priority targets, while APIs using only JSON or applications behind authentication have reduced exposure surface. The CVSS AT:P flag is critical here - not all Plug deployments parse multipart bodies, significantly narrowing the real attack surface compared to the raw score. Remediation priority is high for public-facing upload services, moderate for authenticated file handling, and low for JSON-only APIs. The availability of vendor patches across all affected branches since May 2026 makes delayed patching the primary residual risk.

An unauthenticated remote attacker identifies a web application built with vulnerable Plug versions that accepts file uploads via multipart/form-data POST requests. The attacker crafts an HTTP request with Content-Type: multipart/form-data and a declared boundary string, then streams a request body that begins the boundary sequence but never includes the terminating \r\n\r\n delimiter required to complete the header section. The victim server's read_part_headers/2 function enters an unbounded accumulation loop, consuming 64KB per iteration as it waits for headers that never arrive. The attacker opens 5-10 concurrent connections sending such malformed bodies, each accumulating gigabytes of buffered data within minutes. The BEAM VM process exhausts available memory and crashes, causing denial of service to all users of that application instance. The attack requires no authentication, no special tools beyond curl or a basic HTTP client, and leaves minimal forensic evidence beyond memory exhaustion logs.