Salvo Rust Web Framework Flaw Enables DoS via Unbounded Form Parsing
A CVSSv4 8.7 flaw in Salvo's form parser let unauthenticated attackers crash any pre-0.89.3 service with a single oversized payload.

A flaw in Salvo, the Rust web framework maintained by Salvo-rs, left every version before 0.89.3 open to denial-of-service attacks: the `form_data()` method and `Extractible` macro, which back body extractors across the framework, did not enforce payload size limits before reading request bodies into memory, allowing attackers to trigger Out-of-Memory (OOM) conditions by sending extremely large payloads and crash the service outright.
The vulnerability carries a CVSSv4 base score of 8.7 HIGH, with a vector of CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N, reflecting a network-reachable attack that requires no privileges and no user interaction. The GitLab advisory separately scores it 7.5 HIGH under CVSSv3.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Both scoring systems land the issue firmly in the high-severity tier, with the availability impact component maxed out in each.
The weakness is classified as CWE-770: Allocation of Resources Without Limits or Throttling. The attack surface is deceptively broad: any Salvo handler that calls `form_data()` directly or uses the `Extractible` macro for body extraction is affected, meaning the vulnerability is not confined to a narrow edge-case endpoint but touches a core ergonomic feature the framework actively promotes.
The form data parsing implementations do not enforce payload size limits before reading request bodies into memory, allowing attackers to cause OOM conditions by sending extremely large payloads, leading to service crashes and denial of service. The attack requires nothing beyond network access: no authenticated session, no crafted token, no prior foothold in the application. A single oversized multipart or form-encoded request is sufficient to exhaust server memory.
The GitHub Security Advisory GHSA-pp9r-xg4c-8j4x was dated March 19, 2026 on the GitLab advisory record, with MITRE recording a last-updated timestamp of March 23, 2026, and OpenCVE and Vulmon both logging the entry on March 24, 2026. Version 0.89.3 contains a patch. The GitLab advisory is explicit: "Upgrade to version 0.89.3 or above." One metadata discrepancy is worth noting: OpenCVE's structured solution field reads "No solution given by the vendor," while every other tracker, including MITRE, Vulmon, and OpenCVE's own descriptive text, cites 0.89.3 as the fix. Teams relying on automated OpenCVE feeds for remediation status should verify directly against the GitHub advisory GHSA-pp9r-xg4c-8j4x rather than the structured field alone.
The broader context of Salvo's multipart handling is also worth watching: the framework's multipart form data parsing automatically handles file uploads without explicit developer intent, which creates separate concerns around unintended file storage, disk space exhaustion from automatic file buffering, and endpoints inadvertently becoming file upload targets. CVE-2026-33241 is the unbounded-memory variant of that same class of resource-limit gap, and it arrived alongside a second Salvo CVE, CVE-2026-33242, which covers a path traversal and access control bypass in the `salvo-proxy` component, also patched in 0.89.3.
Pinning Salvo to 0.89.3 or later in `Cargo.toml` closes the exposure tracked under CVE-2026-33241. Projects that cannot upgrade immediately should consider placing a reverse proxy or gateway in front with strict request body size limits as a compensating control until the upgrade can be scheduled.
Know something we missed? Have a correction or additional information?
Submit a Tip
