CVE-2026-32145: Denial of Service via Multipart Parsing Limit Bypass in Wisp

CVE-2026-32145 is a high-severity resource exhaustion vulnerability affecting the Wisp web framework for the Gleam programming language. The vulnerability resides within the framework's multipart/form-data parsing implementation, specifically located in src/wisp.gleam. Wisp applications utilize max_body_size and max_files_size configuration parameters to constrain incoming requests and prevent resource monopolization.

A flaw in the parsing state machine allows unauthenticated remote attackers to bypass these limits entirely. This condition constitutes an "Allocation of Resources Without Limits or Throttling" vulnerability, classified under CWE-770. By circumventing the framework-level size boundaries, an attacker can force the server to allocate unbounded amounts of memory or disk space.

The primary impact of this vulnerability is a denial of service (DoS). When exploited, the application consumes host resources until the process crashes via an Out-Of-Memory (OOM) exception or exhausts all available file system storage. This disruption strictly affects application availability, with no direct impact on data confidentiality or integrity.

Wisp's multipart parser utilizes a recursive state machine to process incoming data chunks from the HTTP request stream. The parser evaluates each chunk to determine if it contains a required multipart boundary delimiter. When the parser identifies a boundary, it processes the segment and correctly decrements the configured resource quota by subtracting the bytes processed.

If the incoming chunk does not contain a boundary, the parser transitions into the MoreRequiredForBody or MoreRequiredForHeaders states. In these states, the parser appends the incoming data to an internal buffer for form fields or writes it to a temporary file for larger payloads. It then recursively calls itself to wait for the subsequent chunk from the network stream.

The root cause of CVE-2026-32145 lies in the execution path of these incomplete-chunk states. Prior to the fix, the recursive branches for MoreRequiredForBody and MoreRequiredForHeaders omitted the mandatory calls to the quota-management functions (decrement_quota or decrement_body_quota). Because the quota logic only executed upon encountering a boundary delimiter, an attacker streaming contiguous data without a boundary bypassed the size tracking mechanism completely.

The vulnerability was addressed in commit 7a978748e12ab29db232c222254465890e1a4a90. The patch ensures that the framework evaluates every chunk of data read from the connection against the remaining quota before any buffering or recursion occurs. This guarantees that limits are enforced continuously during stream processing rather than solely at segment boundaries.

In the vulnerable implementation, the multipart_body function directly appended incoming chunks and recursed without verifying the allocation constraints. The parser only invoked the quota reduction after successfully validating a complete multipart segment.

// Vulnerable pre-patch logic
http.MoreRequiredForBody(chunk, parse) -> {
  let parse = fn_with_bad_request_error(parse, invalid_form)
  let reader = BufferedReader(reader, <<>>)
  // Flaw: Data is appended and function recurses without decrementing quota
  use data <- result.try(append(data, chunk))
  multipart_body(reader, parse, boundary, chunk_size, quota, append, data)
}

The patched implementation calculates the incoming chunk size and applies the decrement_quota function immediately. If the incoming chunk exceeds the remaining allowed quota, the result.try block intercepts the error and aborts the operation, returning an error response to the client and halting further allocation.

// Patched logic
http.MoreRequiredForBody(chunk, parse) -> {
  let parse = fn_with_bad_request_error(parse, invalid_form)
  let reader = BufferedReader(reader, <<>>)
  let size_read = bit_array.byte_size(chunk)
  // Fix: Quota is decremented and enforced before appending data
  use quota <- result.try(decrement_quota(quota, size_read))
  use data <- result.try(append(data, chunk))
  multipart_body(reader, parse, boundary, chunk_size, quota, append, data)
}

Exploitation of CVE-2026-32145 requires an unauthenticated attacker to possess network access to the target Wisp application. The attacker initiates a standard HTTP POST request, setting the Content-Type header to multipart/form-data. The target application routes this request to the vulnerable parsing logic based on the specified content type.

The exploit payload consists of an infinite or exceptionally large stream of bytes that deliberately omits the multipart boundary string. As the attacker streams data into the open connection, the Wisp server recursively calls the buffering functions. Because the boundary is absent, the quota validation code never executes, and the server continuously consumes network input.

Depending on the specific Wisp application routing and configuration, this incoming data accumulates either in volatile memory or on the host filesystem via temporary files. The attack concludes when the target process crashes from memory exhaustion or the underlying filesystem reaches maximum capacity, effectively halting all application operations.

The vulnerability is assessed with a CVSS v4.0 base score of 8.7 (High). The impact vector highlights a high severity for availability (VA:H), reflecting the trivial nature of the denial of service condition. The target application becomes entirely unresponsive, discarding legitimate user requests and failing critical business logic.

An unmitigated exploit leading to disk space exhaustion introduces secondary availability impacts to the host infrastructure. If the Wisp application shares a filesystem with databases, logging services, or other co-located applications, those services will also experience degraded functionality or complete failure when storage capacity reaches zero.

This vulnerability does not permit the attacker to achieve arbitrary code execution or access restricted data. The scope of impact is strictly confined to resource availability. The Exploit Prediction Scoring System (EPSS) currently assigns a low probability of active exploitation in the wild (0.00015), and there are no public weaponized exploit tools documented at this time.

The vendor addressed CVE-2026-32145 in the Wisp library version 2.2.2. Application developers must update their wisp dependency to 2.2.2 or later and recompile their Gleam projects to incorporate the fix. The patched version enforces quota limits on every received chunk, safely terminating oversized requests regardless of boundary presence.

If updating the application dependency is not immediately feasible, operators should implement mitigation strategies at the network edge. Deploying a reverse proxy, such as Nginx or HAProxy, in front of the Wisp application provides a robust defense layer. Administrators must configure strict incoming request size limits on the proxy.

For example, configuring the client_max_body_size directive in Nginx ensures that oversized payloads are terminated by the proxy server before they reach the vulnerable Gleam application. Additionally, security teams should configure monitoring alerts for anomalous spikes in application memory usage or rapid depletion of temporary storage partitions.