GHSA-pp9r-xg4c-8j4x — salvo
GHSA-pp9r-xg4c-8j4x is a CWE-770 vulnerability in salvo. A fix is available for salvo — see the affected versions and patch details below.
Salvo Affected by Denial of Service via Unbounded Memory Allocation in Form Data Parsing
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-pp9r-xg4c-8j4x.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
salvoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Salvo's form data parsing implementations (form_data() method and Extractible macro) do not enforce payload size limits before reading request bodies into memory. This allows attackers to cause Out-of-Memory (OOM) conditions by sending extremely large payloads, leading to service crashes and denial of service.
Details
Vulnerability Description
Three attack vectors exist in Salvo's form handling:
-
URL-encoded form data (
application/x-www-form-urlencoded)Request::form_data()callsBodyExt::collect(body)which reads the entire body into memory without size checking- Affects handlers using
req.form_data().awaitdirectly
-
Multipart form data (
multipart/form-data)- Similar unbounded memory allocation during parsing
- Affects handlers processing multipart uploads
-
Extractible macro
#[derive(Extractible)]with#[salvo(extract(default_source(from = "body")))]internally callsform_data()- Vulnerabilities propagate to all extractors using body sources
Root Cause
The FormData::read() implementation prioritizes convenience over safety by reading entire request bodies before validation. Even when Request::payload_with_max_size() is available, it's not automatically applied in the form parsing path.
PoC
- run
Extract data from requestexample in readme.md in docker file with limited memory say 100mb. - Send
application/x-www-form-urlencodedORmultipart/form-datapayload to the endpoint. - The server process OOM-crashes, instead of returning 413 error.
Impact
Immediate Effects
- Service Unavailability: Servers crash under memory pressure
- Resource Exhaustion: Single request can consume all available memory
- Cascading Failures: In containerized environments, OOM can affect other services
Attack Characteristics
- Low Cost: Attacker needs minimal bandwidth (header only, body can be streamed)
- No Authentication: Exploitable on public endpoints
- Difficult to Rate-Limit: Traditional rate limiting may not prevent single large request
- Amplification: Small network cost → large memory consumption
Real-World Scenarios
- Public API endpoints accepting form data
- User registration/profile update handlers
- File upload endpoints using multipart forms
- Any endpoint using
#[derive(Extractible)]with body sources
Suggestion: Make Multipart File Upload Handling Explicit Opt-In
Problem Statement
Currently, Salvo's multipart form data parsing automatically handles file uploads without explicit developer intent. This creates several security and usability concerns:
- Unintended File Storage: Developers may unknowingly accept file uploads when they only intended to handle text fields
- Disk Space Exhaustion: Automatic file buffering to disk can fill storage without proper limits
- Resource Cleanup: Temporary files may not be properly cleaned up if handlers don't expect them
- Attack Surface: Endpoints inadvertently become file upload targets
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | salvo | all versions | 0.89.3cargo update -p salvo --precise 0.89.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for salvo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update salvo to 0.89.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pp9r-xg4c-8j4x is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-pp9r-xg4c-8j4x can be triaged on real exposure rather than presence alone.
Tailored to GHSA-pp9r-xg4c-8j4x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-pp9r-xg4c-8j4x in your dependencies?
O3 Security finds GHSA-pp9r-xg4c-8j4x across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.