CVE-2026-8468: Elixir Plug Library DoS Vulnerability

CVE-2026-8468 Overview

CVE-2026-8468 is a denial-of-service vulnerability in the Elixir plug library, a widely used web request abstraction for Erlang/Elixir web applications such as Phoenix. The flaw resides in Elixir.Plug.Conn.read_part_headers/2 within lib/plug/conn.ex, which fails to honor its :length parameter when parsing multipart request headers. An unauthenticated remote attacker can submit a crafted multipart/form-data request that causes the server to accumulate header bytes without bound, exhausting memory and triggering a denial of service. The issue is classified under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact

Unauthenticated remote attackers can exhaust server memory and crash Plug-based applications by sending oversized multipart headers in a single HTTP request.

Affected Products

• plug versions 1.4.0 through versions before 1.15.4
• plug versions before 1.16.3, 1.17.1, and 1.18.2
• plug versions before 1.19.2

Discovery Timeline

• 2026-05-14 - CVE CVE-2026-8468 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-8468

Vulnerability Analysis

The vulnerability resides in Elixir.Plug.Conn.read_part_headers/2, the function responsible for reading headers of a multipart request part. The function accepts a :length option intended to cap the size of accumulated header data, but the implementation does not enforce this bound. As the parser reads incoming bytes from the request stream, it appends them to an in-memory accumulator until a complete header block is parsed or the connection terminates.

The sibling function read_part_body/2 correctly applies a byte_size(acc) > length guard to stop accumulation once the configured limit is reached. The absence of an equivalent guard in read_part_headers/2 allows attacker-controlled data to grow without limit. An attacker sending a multipart part with extremely large header lines, or many header fields, forces the Erlang VM to allocate increasing amounts of memory until the operating system kills the process or the host swaps to unresponsiveness.

Root Cause

The root cause is a missing length check in the header accumulation loop. The function documents support for a :length option but never compares the size of the accumulator buffer against that value. This is an instance of [CWE-770] where a user-controllable input governs resource allocation without an enforced upper bound.

Attack Vector

The attack is delivered over the network with no authentication or user interaction. The attacker sends a single HTTP request with Content-Type: multipart/form-data containing a part whose header section is arbitrarily large, for example a single header line padded with megabytes of data. Because read_part_headers/2 is invoked before any application-level authentication or routing logic on routes that parse multipart bodies, the request reaches the vulnerable code path on most Plug-based deployments.

// Patch excerpt - lib/plug/conn.ex
  @doc """
  Reads the headers of a multipart request.

-  It returns `{:ok, headers, conn}` with the headers or
-  `{:done, conn}` if there are no more parts.
+  It returns `{:ok, headers, conn}` with the headers,
+  `{:error, :too_large, conn}` if the current multipart header block
+  exceeds the configured `:length`, or `{:done, conn}` if there are
+  no more parts.

  Once `read_part_headers/2` is invoked, you may call
  `read_part_body/2` to read the body associated to the headers.

Source: GitHub Commit 2cb7958

// Patch excerpt - lib/plug/parsers/multipart.ex
      parse_multipart(conn, opts_tuple)
    rescue
      # Do not ignore upload errors
-      e in [Plug.UploadError, Plug.Parsers.BadEncodingError] ->
+      e in [Plug.UploadError, Plug.Parsers.BadEncodingError, Plug.Parsers.RequestTooLargeError] ->
        reraise e, __STACKTRACE__

      # All others are wrapped

Source: GitHub Commit 33858427

Detection Methods for CVE-2026-8468

Indicators of Compromise

• Sudden spikes in Erlang VM memory usage (erlang:memory/0) correlated with inbound multipart/form-data requests.
• Beam process crashes or OOM kills on application nodes, especially under low connection counts.
• Web server access logs showing single requests with abnormally large Content-Length values targeting multipart endpoints.

Detection Strategies

• Inspect inbound HTTP requests at a reverse proxy or WAF for multipart/form-data requests with header sections that exceed expected sizes.
• Audit application code for usage of Plug.Conn.read_part_headers/2 or Plug.Parsers.MULTIPART without explicit :length limits enforced by the patched version.
• Compare deployed plug versions against the fixed releases (1.15.4, 1.16.3, 1.17.1, 1.18.2, 1.19.2) using dependency manifests such as mix.lock.

Monitoring Recommendations

• Alert on rapid memory growth in BEAM processes serving HTTP traffic and correlate with request telemetry.
• Enable structured logging of Plug.Parsers.RequestTooLargeError events after patching to identify ongoing exploitation attempts.
• Track 4xx and 5xx error rates on routes that accept file uploads or form submissions.

How to Mitigate CVE-2026-8468

Immediate Actions Required

• Upgrade plug to one of the fixed versions: 1.15.4, 1.16.3, 1.17.1, 1.18.2, or 1.19.2, matching your current minor release line.
• Update mix.exs, regenerate mix.lock, and redeploy all services that depend on plug, including Phoenix applications.
• Audit reverse proxy configurations to enforce a maximum request header and body size in front of Plug-based applications.

Patch Information

The fix adds an explicit length check to read_part_headers/2 and propagates a new Plug.Parsers.RequestTooLargeError when the configured :length is exceeded. See the GitHub Security Advisory GHSA-468c-vq7p-gh64 and the OSV Vulnerability Report for details. Relevant commits include 2cb7958, 3385842, aa69c5e, d5dfffe, and df812a1.

Workarounds

• Place a reverse proxy such as Nginx or HAProxy in front of the application and enforce strict client_max_body_size and header-size limits to bound multipart request size before it reaches Plug.
• Restrict multipart parsing to authenticated routes where feasible, reducing the unauthenticated attack surface until patching is complete.
• Monitor BEAM memory usage and configure OS-level memory limits (e.g., cgroups) so a single runaway process cannot exhaust host memory.

# Update plug in mix.exs to a patched version, then run:
mix deps.update plug
mix deps.get
mix compile

# Verify the installed version
mix deps | grep plug