CVE-2026-32145 gleam-wisp CVE debrief

Who should care

Operators and developers running gleam-wisp/wisp services that accept multipart form submissions, especially file-upload or form-processing endpoints that depend on max_body_size or max_files_size to constrain resource use.

Technical summary

The issue is in multipart_body and multipart_headers. When a multipart boundary is not present in an input chunk, the parser follows a MoreRequired path that appends the chunk but recurses without decrementing the quota first. As a result, intermediary chunks are not counted against the configured limits, and only the final chunk containing the boundary is reduced via decrement_quota. The same recursive accounting gap exists in multipart_headers via MoreRequiredForHeaders and decrement_body_quota. This lets an attacker send a single large multipart request that bypasses throttling and exhausts resources.

Defensive priority

High. The attack is network-reachable, requires no authentication, and can be used to exhaust memory or disk through request handling alone.

Recommended defensive actions

• Upgrade wisp to version 2.2.2 or later, which the advisory identifies as the fixed release boundary.
• Verify all deployed services using wisp are not pinned to versions from 0.2.0 through 2.2.1.
• Review any custom forks or backports to confirm multipart parsing now decrements quota on every recursive path.
• Add or tighten edge and application-layer request size limits for multipart uploads.
• Monitor for abnormal memory, disk, or request-processing spikes on any service that accepts multipart form submissions.
• Re-test upload and form endpoints after patching to confirm configured max_body_size and max_files_size enforcement behaves as expected.

Evidence notes

The supplied CVE description states that multipart_body bypasses max_body_size and max_files_size when a boundary is absent in a chunk, and that multipart_headers has the same recursive quota-accounting flaw. The CNA advisory, GitHub security advisory, OSV entry, and upstream commit are the linked references for the affected range and remediation context. The provided timeline places publication on 2026-04-02 and a later CVE record modification on 2026-04-06; NVD's snapshot status was 'Undergoing Analysis'.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.