GHSA-h2jq-g4cq-5ppq
HIGHGHSA-h2jq-g4cq-5ppq is a high-severity (CVSS 7.5) CWE-187 vulnerability in rack. O3 Security confirms whether GHSA-h2jq-g4cq-5ppq is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Rack::Static prefix matching can expose unintended files under the static root
Real-World Exposure
rack💎rack💎rackReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Rack::Static determines whether a request should be served as a static file using a simple string prefix check. When configured with URL prefixes such as "/css", it matches any request path that begins with that string, including unrelated paths such as "/css-config.env" or "/css-backup.sql".
As a result, files under the static root whose names merely share the configured prefix may be served unintentionally, leading to information disclosure.
Details
Rack::Static#route_file performs static-route matching using logic equivalent to:
@urls.any? { |url| path.index(url) == 0 }
This checks only whether the request path starts with the configured prefix string. It does not require a path segment boundary after the prefix.
For example, with:
use Rack::Static, urls: ["/css", "/js"], root: "public"
the following path is matched as intended:
/css/style.css
but these paths are also matched:
/css-config.env
/css-backup.sql
/csssecrets.yml
If such files exist under the configured static root, Rack forwards the request to the file server and serves them as static content.
This means a configuration intended to expose only directory trees such as /css/... and /js/... may also expose sibling files whose names begin with those same strings.
Impact
An attacker can request files under the configured static root whose names share a configured URL prefix and obtain their contents.
In affected deployments, this may expose configuration files, secrets, backups, environment files, or other unintended static content located under the same root directory.
Mitigation
- Update to a patched version of Rack that enforces a path boundary when matching configured static URL prefixes.
- Match only paths that are either exactly equal to the configured prefix or begin with
prefix + "/". - Avoid placing sensitive files under the
Rack::Staticroot directory. - Prefer static URL mappings that cannot overlap with sensitive filenames.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | rack | all versions | 2.2.23 |
| 💎RubyGems | rack | ≥ 3.0.0.beta1&&< 3.1.21 | 3.1.21 |
| 💎RubyGems | rack | ≥ 3.2.0&&< 3.2.6 | 3.2.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rack. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update rack to 2.2.23 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h2jq-g4cq-5ppq 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 pinpoints whether GHSA-h2jq-g4cq-5ppq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h2jq-g4cq-5ppq. 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-h2jq-g4cq-5ppq in your dependencies?
O3 detects GHSA-h2jq-g4cq-5ppq across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.