Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀 crates.io
Not in CISA KEV

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

Also known asCVE-2026-33241
Published
Mar 19, 2026
Updated
Mar 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs37th percentile — riskier than 37% of all scored CVEsHighest risk

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

1 pkg affected
🦀salvo

Real-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:

  1. URL-encoded form data (application/x-www-form-urlencoded)

    • Request::form_data() calls BodyExt::collect(body) which reads the entire body into memory without size checking
    • Affects handlers using req.form_data().await directly
  2. Multipart form data (multipart/form-data)

    • Similar unbounded memory allocation during parsing
    • Affects handlers processing multipart uploads
  3. Extractible macro

    • #[derive(Extractible)] with #[salvo(extract(default_source(from = "body")))] internally calls form_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

  1. run Extract data from request example in readme.md in docker file with limited memory say 100mb.
  2. Send application/x-www-form-urlencoded OR multipart/form-data payload to the endpoint.
  3. 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

  1. Public API endpoints accepting form data
  2. User registration/profile update handlers
  3. File upload endpoints using multipart forms
  4. 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:

  1. Unintended File Storage: Developers may unknowingly accept file uploads when they only intended to handle text fields
  2. Disk Space Exhaustion: Automatic file buffering to disk can fill storage without proper limits
  3. Resource Cleanup: Temporary files may not be properly cleaned up if handlers don't expect them
  4. Attack Surface: Endpoints inadvertently become file upload targets

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iosalvoall versions0.89.3cargo update -p salvo --precise 0.89.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

## 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: 1. **URL-encoded form data** (`application/x-www-form-urlencoded`) - `Request::form_data()` calls `BodyExt::collect(body)` which reads the entire body into memory without siz
O3 Security · Impact-Aware SCA

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.

GHSA-pp9r-xg4c-8j4x: salvo DoS | O3 Security