CVE-2026-32145
Resource Exhaustion DoS in gleam-wisp via Multipart Parsing
Publication date: 2026-04-02
Last updated on: 2026-04-06
Assigner: EEF
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| gleam | wisp | From 0.2.0 (inc) to 2.2.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-32145 is a vulnerability in the Gleam Wisp web server's multipart form data parsing. The issue arises because the parser does not correctly enforce configured maximum body size limits when processing multipart form data sent in multiple chunks. Specifically, when chunks of data do not contain a multipart boundary, the parser appends the data but does not decrement the quota that limits the allowed size. This allows an attacker to send arbitrarily large multipart form submissions without triggering size limits.
The vulnerability exists in the multipart_body and multipart_headers functions, where recursive calls occur without properly reducing the allowed quota for incoming data chunks. As a result, the server can accumulate large amounts of data in memory or on disk without restriction.
An unauthenticated attacker can exploit this by sending a single HTTP request with a large multipart form body split across many chunks that avoid boundaries, causing resource exhaustion.
How can this vulnerability impact me? :
This vulnerability can lead to a denial of service (DoS) condition by exhausting server memory or disk resources. Because the server does not enforce limits on the size of multipart form data received in chunks, an attacker can send very large requests that consume all available resources.
The impact includes application unavailability or termination by the operating system due to resource exhaustion, potentially disrupting service for legitimate users.
Since the attack requires no authentication and has low complexity, it poses a significant risk to any application using the vulnerable versions of the wisp package.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the server accepting arbitrarily large multipart form submissions split across many chunks without enforcing configured maximum body size limits.
To detect exploitation attempts on your network or system, you can monitor HTTP requests for unusually large multipart/form-data POST requests, especially those that are chunked and lack proper multipart boundaries in early chunks.
Commands or methods to detect this include:
- Using network packet capture tools like tcpdump or Wireshark to filter HTTP POST requests with 'Content-Type: multipart/form-data' and analyze chunk sizes and boundaries.
- Using web server access logs to identify requests with large Content-Length headers or repeated chunked transfer encoding with large payloads.
- Example tcpdump command to capture HTTP traffic on port 80 or 443: tcpdump -i any -s 0 -A 'tcp port 80 or tcp port 443' | grep -i 'multipart/form-data'
- Using application-level logging or instrumentation to detect requests exceeding expected body sizes or unusually long multipart form submissions.
What immediate steps should I take to mitigate this vulnerability?
The recommended immediate mitigation is to deploy a reverse proxy such as nginx or HAProxy in front of the vulnerable wisp application.
This reverse proxy should enforce strict request body size limits to reject large multipart form submissions before they reach the vulnerable multipart parser.
Additionally, upgrading the wisp package to version 2.2.2 or later will apply the fix that correctly enforces maximum body size limits even for chunked multipart requests.
- Configure nginx with client_max_body_size to limit the maximum allowed request body size.
- Use HAProxy's tune.maxrewrite or similar settings to limit request sizes.
- Apply the patch or upgrade to wisp version 2.2.2 or later where the quota enforcement on chunked multipart bodies and headers is fixed.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an unauthenticated attacker to exhaust server memory or disk by sending arbitrarily large multipart form submissions, leading to denial of service or application unavailability.
Such denial of service conditions can impact the availability aspect of common standards and regulations like GDPR and HIPAA, which require systems to ensure availability and resilience of personal and sensitive data processing.
Because the vulnerability enables resource exhaustion without proper limits or throttling, it may cause interruptions in service or data processing, potentially violating compliance requirements related to system availability and reliability.
Mitigation recommendations include deploying reverse proxies to enforce request size limits, which can help maintain compliance by preventing resource exhaustion attacks.