CVE-2026-32145: Gleam-Wisp DoS Vulnerability

CVE-2026-32145 Overview

CVE-2026-32145 is a Resource Exhaustion vulnerability in the gleam-wisp wisp web framework that enables denial of service attacks via multipart form body parsing. The vulnerability stems from improper enforcement of configured resource limits during HTTP request processing.

The multipart_body function bypasses configured max_body_size and max_files_size limits. When a multipart boundary is not present in a chunk, the parser takes the MoreRequiredForBody path, which appends the chunk to the output but passes the quota unchanged to the recursive call. Only the final chunk containing the boundary is counted via decrement_quota. The same pattern exists in multipart_headers, where MoreRequiredForHeaders recurses without calling decrement_body_quota.

An unauthenticated attacker can exhaust server memory or disk by sending arbitrarily large multipart form submissions in a single HTTP request.

Critical Impact

Unauthenticated attackers can exhaust server memory or disk resources through a single malicious HTTP request containing an arbitrarily large multipart form submission, leading to complete service unavailability.

Affected Products

• wisp versions from 0.2.0 before 2.2.2

Discovery Timeline

• 2026-04-02 - CVE CVE-2026-32145 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-32145

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue lies in the recursive multipart form parsing logic where quota enforcement is inconsistently applied across different code paths.

When processing multipart HTTP requests, the wisp framework is designed to enforce body size limits through a quota system. However, the implementation contains a flaw in the recursive parsing functions. Specifically, when the multipart boundary is not found within a chunk, the parser follows the MoreRequiredForBody code path. In this path, the chunk data is appended to the accumulated output, but critically, the quota value is passed unchanged to the subsequent recursive call rather than being decremented.

This means that only when the final chunk containing the multipart boundary is processed does the decrement_quota function get called. All intermediate chunks—regardless of their size—are accumulated without any quota accounting, effectively bypassing the intended size restrictions.

Root Cause

The root cause is a logic error in quota decrement handling within the recursive multipart parsing functions. The multipart_body function fails to call decrement_quota when taking the MoreRequiredForBody path, and similarly, multipart_headers fails to call decrement_body_quota when recursing via MoreRequiredForHeaders. This inconsistent quota enforcement allows unbounded data accumulation during the parsing process.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can craft a malicious HTTP POST request with a multipart form body that is structured to avoid including the boundary marker in intermediate chunks. By sending extremely large chunks without boundaries, the attacker forces the parser into the vulnerable recursive path repeatedly, causing unbounded memory allocation on the target server.

The attack can be sustained with a single HTTP connection, making it highly efficient for resource exhaustion. Server memory or disk resources can be consumed until the service becomes unavailable or crashes.

     http.MoreRequiredForBody(chunk, parse) -> {
       let parse = fn_with_bad_request_error(parse, invalid_form)
       let reader = BufferedReader(reader, <<>>)
+      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)
     }

Source: GitHub Commit Change

The patch adds the critical decrement_quota call before appending data and recursing, ensuring that every chunk is properly counted against the configured limits.

Detection Methods for CVE-2026-32145

Indicators of Compromise

• Abnormally large HTTP POST requests with multipart/form-data content types
• Rapid memory consumption on servers running wisp-based applications
• HTTP connections that remain open for extended periods while transmitting large request bodies
• Server crashes or out-of-memory errors correlated with incoming multipart form submissions

Detection Strategies

• Monitor HTTP request body sizes at the network perimeter and alert on requests exceeding expected thresholds
• Implement application-level logging to track multipart form parsing operations and resource consumption
• Deploy anomaly detection for unusual patterns in HTTP POST request characteristics
• Review web server access logs for requests with abnormally long processing times

Monitoring Recommendations

• Configure infrastructure monitoring to alert on rapid memory growth in application processes
• Set up disk space monitoring with appropriate thresholds for temporary file storage locations
• Enable request timeout enforcement at load balancer and reverse proxy layers
• Monitor connection duration metrics for web application servers

How to Mitigate CVE-2026-32145

Immediate Actions Required

• Upgrade wisp to version 2.2.2 or later immediately
• Review application logs for evidence of exploitation attempts
• Implement request body size limits at the reverse proxy or load balancer level as defense-in-depth
• Consider temporarily disabling multipart form endpoints if upgrade is not immediately possible

Patch Information

The vulnerability is fixed in wisp version 2.2.2. The fix adds proper quota decrement calls in the MoreRequiredForBody and MoreRequiredForHeaders code paths, ensuring that all accumulated data is properly counted against configured limits. The security patch is available via the GitHub commit and documented in the GitHub Security Advisory GHSA-8645-p2v4-73r2.

Workarounds

• Deploy a reverse proxy (nginx, HAProxy) with strict request body size limits in front of wisp applications
• Implement rate limiting on endpoints accepting multipart form submissions
• Configure connection timeouts at the infrastructure level to prevent long-running malicious requests
• Use web application firewall rules to restrict maximum content-length headers

# Example nginx configuration to limit request body size
# Add to server or location block for wisp application
client_max_body_size 10m;
client_body_timeout 30s;
client_body_buffer_size 128k;