GHSA-f842-phm9-p4v4 is a high-severity (CVSS 7.5) Path Traversal vulnerability in salvo. A fix is available for salvo — see the affected versions and patch details below.
Salvo has a Path Traversal in salvo-proxy::encode_url_path allows API Gateway Bypass
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-f842-phm9-p4v4.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-f842-phm9-p4v4 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
salvoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | salvo | ≥ 0.39.0&&< 0.89.3 | 0.89.3cargo update -p salvo --precise 0.89.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for salvo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update salvo to 0.89.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f842-phm9-p4v4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-f842-phm9-p4v4 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-f842-phm9-p4v4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-f842-phm9-p4v4 in your dependencies?
O3 Security finds GHSA-f842-phm9-p4v4 across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.