GHSA-pp9r-xg4c-8j4x

Suggest an improvement
Source
https://github.com/advisories/GHSA-pp9r-xg4c-8j4x
Import Source
https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/03/GHSA-pp9r-xg4c-8j4x/GHSA-pp9r-xg4c-8j4x.json
JSON Data
https://api.osv.dev/v1/vulns/GHSA-pp9r-xg4c-8j4x
Aliases
Published
2026-03-19T12:44:56Z
Modified
2026-03-25T21:04:54Z
Severity
  • 8.7 (High) CVSS_V4 - 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 CVSS Calculator
Summary
Salvo Affected by Denial of Service via Unbounded Memory Allocation in Form Data Parsing
Details

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
Database specific
{
    "cwe_ids":  [
        "CWE-770"
    ],
    "github_reviewed":  true,
    "github_reviewed_at":  "2026-03-19T12:44:56Z",
    "nvd_published_at":  "2026-03-24T00:16:29Z",
    "severity":  "HIGH"
}
References

Affected packages

crates.io / salvo

Package

Affected ranges

Type
SEMVER
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
0.89.3

Database specific

source
"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/03/GHSA-pp9r-xg4c-8j4x/GHSA-pp9r-xg4c-8j4x.json"