CVE-2026-25765

What it actually does

Faraday versions prior to 2.14.1 can incorrectly combine a configured base URL with a user-supplied request path using Ruby URI merge behavior. When the supplied path is a protocol-relative URL beginning with double slashes, such as //example.com/path, the host component of the original base URL can be replaced. In applications that pass untrusted input into Faraday request methods such as get(), post(), build_url(), or similar helpers, this enables server-side request forgery by causing the application server to initiate outbound HTTP requests to attacker-chosen hosts. The primary technical risk is unauthorized outbound request routing and potential exposure of response data from reachable internal or external services; integrity and availability impact are not inherent to the library flaw but may arise depending on what the vulnerable application does with the response.

Why it matters to the business

An affected application may be tricked into connecting to unintended systems, including internal services, cloud metadata endpoints, partner APIs, or attacker-controlled infrastructure. This can lead to disclosure of limited sensitive information, leakage of tokens or request metadata, bypass of network access controls, and abuse of trusted application egress paths. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score with no reported public exploit maturity, so urgency is generally lower than actively exploited vulnerabilities; however, applications that expose Faraday-backed URL or path parameters to unauthenticated users should still prioritize remediation because exploitation requires little complexity.

How an attack unfolds

An attacker first identifies an application feature that accepts a path, endpoint, callback destination, import URL, webhook-like value, or other input that is later passed to Faraday as a request path while the application expects requests to stay under a fixed base URL. Instead of supplying a normal relative path, the attacker supplies a protocol-relative value beginning with //. In vulnerable Faraday versions, the URL-building logic treats that value as a network-path reference and replaces the base URL host with the attacker-supplied host while preserving the scheme. The application then sends the outbound request from the server to the attacker-selected destination. The attacker may point the request at infrastructure they control to confirm exploitability and capture headers, tokens, or request metadata, or may attempt to reach internal-only resources and infer or retrieve sensitive data if the application returns or processes the response.

How to fix it

Upgrade Faraday to version 2.14.1 or later wherever it is used, including transitive dependency paths in Ruby applications. The upstream fix is associated with commit 16cbd38ef252d25dedf416a4d2510a2f3db10c87. Refresh lockfiles and rebuild/redeploy affected services so the patched gem is actually loaded at runtime. As defense in depth, do not pass raw user input directly to Faraday request methods; reject protocol-relative inputs beginning with //, backslash variants, encoded double slashes, absolute URLs where not expected, and unexpected schemes. Enforce an allowlist of permitted destination hosts and paths before making server-side HTTP requests. Add egress controls so application workloads can only reach required external services and cannot access cloud metadata endpoints or internal administrative services unless explicitly needed.

How to confirm the fix worked

Confirm dependency state by checking Gemfile.lock, software composition analysis results, container image SBOMs, and runtime gem inventories for Faraday versions older than 2.14.1. Validate that all deployed artifacts were rebuilt after the dependency update and are not still packaging an older gem. Perform a safe functional test in a non-production or controlled environment by passing a protocol-relative value such as //controlled-test-host.example/path to any relevant application input and confirming the application does not make an outbound request to that host. Review outbound proxy, DNS, and firewall logs during testing to verify the intended base host is preserved or the request is rejected. Also add unit or integration tests around URL construction to ensure user-controlled path values cannot override the configured authority component.

Typical attack path

1. Find an externally reachable feature that accepts user-controlled input used in a Faraday request path or URL construction flow.
2. Submit a protocol-relative path beginning with double slashes, such as //host.example/path, instead of a normal relative path.
3. Rely on vulnerable URL merging behavior to replace the intended base host with the supplied host.
4. Observe an outbound request from the application server to the attacker-controlled or otherwise unintended host.
5. Iterate with internal addresses, cloud metadata endpoints, or sensitive service names if outbound network controls and application behavior allow it.
6. Use any returned response data, error messages, timing differences, or captured request headers to gather information or access secrets.

How to detect it

To determine whether exploitation already occurred, correlate inbound application requests with outbound HTTP, DNS, proxy, firewall, and cloud flow logs from services that use Faraday versions prior to 2.14.1. Look for user-supplied parameters or request paths beginning with //, encoded variants such as %2f%2f, or unusual host-like values in fields that normally contain relative paths. Review outbound connections made immediately after those inbound requests for destinations outside the expected API allowlist, especially attacker-controlled domains, newly registered domains, public IPs not associated with business partners, internal RFC1918 addresses, localhost-style addresses, and cloud metadata endpoints. If Faraday logging, HTTP client debug logs, APM traces, or distributed tracing are enabled, search for requests where the configured logical integration should target one host but the actual URI host differs. Examine whether any responses from unintended destinations were returned to users, stored, or used in downstream workflows. Because there are no universal actor-specific indicators for this issue, detection should focus on payload shape, unexpected egress, DNS lookups, and request/response correlation.

• GET //
• POST //
• PUT //
• PATCH //
• DELETE //
• %2f%2f169.254.169.254
• %2F%2F169.254.169.254
• //169.254.169.254/latest/meta-data
• //169.254.169.254/metadata
• //metadata.google.internal/
• //metadata/computeMetadata/v1
• //localhost/
• //127.0.0.1/
• //0.0.0.0/
• //[::1]/
• //10.
• //172.16.
• //172.17.
• //172.18.
• //172.19.
• //172.20.
• //172.21.
• //172.22.
• //172.23.
• //172.24.
• //172.25.
• //172.26.
• //172.27.
• //172.28.
• //172.29.
• //172.30.
• //172.31.
• //192.168.
• faraday (2.14.0)
• faraday (2.13.
• faraday (2.12.
• lib/faraday/connection.rb
• build_exclusive_url

What your security team should do

• Inventory Ruby applications and services that include Faraday and identify versions prior to 2.14.1.
• Prioritize internet-facing features where unauthenticated or low-privileged users can influence paths, endpoints, import locations, callbacks, webhooks, or proxy-like request parameters.
• Upgrade Faraday to 2.14.1 or later, refresh lockfiles, rebuild images, and redeploy affected services.
• Add input validation that rejects protocol-relative URLs, encoded double slashes, absolute URLs, unexpected schemes, and host override attempts in fields intended to be relative paths.
• Implement destination allowlists and outbound egress restrictions for application workloads that perform server-side HTTP requests.
• Block access from application workloads to cloud metadata services and sensitive internal address ranges unless there is a documented business requirement.
• Search historical application, DNS, proxy, and firewall logs for protocol-relative payloads and unexpected outbound requests from affected services.
• Add regression tests and SAST/dependency checks to prevent reintroduction of unsafe Faraday URL construction patterns.