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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

Summary

The function list_html generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
        let mut link = "".to_owned();
        format!(
            r#"<a href="/">{}</a>{}"#,
            HOME_ICON,
            segments
                .map(|seg| {
                    link = format!("{link}/{seg}");
                    format!("/<a href=\"{link}\">{seg}</a>")
                })
                .collect::<Vec<_>>()
                .join("")
        )
// ...

PoC

https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4

Here is the example app we used:

mian.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use std::path::PathBuf;
use tokio::fs;

const INDEX_HTML: &str = r#"<!doctype html>
<html>
  <head><meta charset="utf-8"><title>StaticDir PoC</title></head>
  <body>
    <h2>Upload a file</h2>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload</button>
    </form>

    <p>Browse uploads:</p>
    <ul>
      <li><a href="/files">/files</a></li>
      <li><a href="/files/">/files/</a></li>
    </ul>
  </body>
</html>
"#;

#[handler]
async fn index(res: &mut Response) {
    res.render(Text::Html(INDEX_HTML));
}

#[handler]
async fn upload(req: &mut Request, res: &mut Response) {
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let form = match req.form_data().await {
        Ok(v) => v,
        Err(e) => {
            res.status_code(StatusCode::BAD_REQUEST);
            res.render(Text::Plain(format!("form_data parse failed: {e}")));
            return;
        }
    };

    let Some(file_part) = form.files.get("file") else {
        res.status_code(StatusCode::BAD_REQUEST);
        res.render(Text::Plain("missing file field (name=\"file\")"));
        return;
    };

    let original_name = file_part.name().unwrap_or("upload.bin");

    let mut dest = PathBuf::from("uploads");
    dest.push(original_name);

    let tmp_path = file_part.path();
    if let Err(e) = fs::copy(tmp_path, &dest).await {
        res.status_code(StatusCode::INTERNAL_SERVER_ERROR);
        res.render(Text::Plain(format!("save failed: {e}")));
        return;
    }

    res.render(Text::Plain(format!(
        "Uploaded as: {original_name}\nNow open: http://127.0.0.1:5800/files/\n"
    )));
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .get(index)
        .push(Router::with_path("upload").post(upload))
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).

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

Details

A Path Traversal and Access Control Bypass vulnerability was discovered in the salvo-proxy component of the Salvo Rust framework (v0.89.2). The vulnerability allows an unauthenticated external attacker to bypass proxy routing constraints and access unintended backend paths (e.g., protected endpoints or administrative dashboards). This issue stems from the encode_url_path function, which fails to normalize "../" sequences and inadvertently forwards them verbatim to the upstream server by not re-encoding the "." character.

Technical Details

If someone tries to attack by sending a special code like %2e%2e, Salvo changes it back to ../ when it first checks the path. The proxy then gets this plain ../ value. When making the new URL to send forward, the encode_url_path function tries to change the path again, but its normal settings do not include the . (dot) character. Because of this, the proxy puts ../ straight into the new URL and sends a request like GET /api/../admin HTTP/1.1 to the backend server.

// crates/proxy/src/lib.rs (Lines 100-105)

pub(crate) fn encode_url_path(path: &str) -> String {
    path.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

PoC

1 - Setup an Nginx Backend Server for example 2 - Start Salvo Proxy Gateway in other port routing to /api/ 3 - Run the curl to test the bypass:

curl -s http://127.0.0.1:8080/gateway/api/%2e%2e%2fadmin/index.html

Impact

If attackers take advantage of this problem, they can get past API Gateway security checks and route limits without logging in. This could accidentally make internal services, admin pages, or folders visible.

The attack works because the special path is sent as-is to the backend, which often happens in systems that follow standard web address rules. Attackers might also use different ways of writing URLs or add extra parts to the web address to get past simple security checks that only look for exact ../ patterns.

Remediation

Instead of changing the text of the path manually, the proxy should use a standard way to clean up the path according to RFC 3986 before adding it to the main URL. It is better to use a trusted tool like the URL crate to join paths, or to block any path parts with “..” after decoding them. But a custom implementation maybe looks like:

pub(crate) fn encode_url_path(path: &str) -> String {
    let normalized = normalize_path(path);
    normalized.split('/')
        .map(|s| utf8_percent_encode(s, PATH_ENCODE_SET).to_string())
        .collect::<Vec<_>>()
        .join("/")
}

fn normalize_path(path: &str) -> String {
    let mut stack = Vec::new();
    for part in path.split('/') {
        match part {
            "" | "." => (), 
            ".." => { let _ = stack.pop(); },
            _ => stack.push(part),
        }
    }
    stack.join("/")
}

Vulnerable code introduced in: https://github.com/salvo-rs/salvo/commit/7bac30e6960355c58e358e402072d4a3e5c4e1bb#diff-e319bf7afcb577f7e9f4fb767005072f6335d23f306dd52e8c94f3d222610d02R20

Author: Tomas Illuminati

Summary

The function list_html generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

Details

The vulnerable snippet of code is the following: dir.rs

// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...

As seen here <title>{}</title> it is inserted unsafely.

PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

main.rs

use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Cargo.toml

[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"

Setup commands:

mkdir uploads
mkdir uploads/bla