CVE-2026-33637

What it actually does

Faraday versions 2.0.0 through 2.14.1 can allow a protocol-relative URI object to override the intended host when building a request from a fixed-base Faraday::Connection. If application code accepts or constructs attacker-influenced URI objects and passes them to Faraday::Connection#build_exclusive_url or related request-building paths, the request can be sent to an unintended attacker-controlled host. Connection-scoped values, including Authorization headers, default headers, cookies, and default query parameters configured on the Faraday connection, may be forwarded off-host. This is an off-host request forgery / SSRF-style issue focused primarily on unintended outbound requests and credential or token disclosure rather than direct code execution.

Why it matters to the business

Applications using vulnerable Faraday versions may unintentionally send sensitive API credentials or authenticated requests to an attacker-controlled service. This can lead to third-party account compromise, unauthorized API usage, exposure of tokens or bearer credentials, and downstream data access depending on what the leaked credentials can reach. The issue is not currently listed in CISA KEV, has low EPSS, and has no known mature public exploitation in the provided data, but Faraday is a common Ruby HTTP library, so organizations should prioritize review and patching where it is used in services that call internal APIs, cloud services, identity providers, payment systems, or other authenticated endpoints.

How an attack unfolds

An attacker looks for an application feature that causes the server to make outbound HTTP requests using Faraday, especially where part of the request target can be influenced by user input, webhook configuration, redirect-like parameters, imported URLs, callback URLs, or integration metadata. Instead of supplying a normal relative path, the attacker supplies or causes creation of a protocol-relative URI object that begins with a double slash and specifies an attacker-controlled host. In vulnerable Faraday versions, this URI object can bypass the intended fixed base host on the connection. The application then sends the outbound request to the attacker’s host while retaining connection-level headers or parameters such as Authorization values. The attacker captures the request on their server and extracts any leaked tokens, API keys, headers, cookies, or default query parameters. They may then attempt to reuse those credentials against the intended upstream service or other services where the same secret is valid.

How to fix it

Upgrade Faraday to version 2.14.3 or later. If immediate upgrade is not possible, avoid passing attacker-influenced URI objects into Faraday request-building APIs and normalize request targets to safe relative strings before use. Reject protocol-relative inputs beginning with double slashes, enforce strict destination allowlists, and validate both scheme and host after URL construction but before dispatch. Do not attach broadly scoped Authorization headers, cookies, or API keys to generic Faraday connections used with user-influenced request paths. Prefer per-destination clients with minimal credentials. Add outbound egress controls so application servers can only connect to expected upstream hosts.

How to confirm the fix worked

Confirm dependency resolution shows Faraday 2.14.3 or later in all Ruby applications, lockfiles, containers, build artifacts, and deployed packages. Review Gemfile.lock, bundler output, SBOMs, and container image package inventories for Faraday versions 2.0.0 through 2.14.1. Add or run regression tests that pass a protocol-relative URI object to the relevant request-building path and verify the request remains constrained to the intended host or is rejected. Validate application-level URL handling rejects inputs beginning with double slashes where only relative paths are expected. Confirm outbound network policy prevents unexpected connections to arbitrary internet hosts from services that use authenticated Faraday clients.

Typical attack path

1. Identify an application endpoint or workflow that triggers server-side outbound HTTP requests through Faraday.
2. Determine whether the request target can be influenced through a URL, path, callback, webhook, import source, integration setting, or similar input.
3. Submit input that results in a protocol-relative URI object, such as a target beginning with double slashes and an attacker-controlled host.
4. Cause the application to build the request using a vulnerable Faraday connection with a fixed base URL and connection-scoped headers or parameters.
5. Receive the forged outbound request on attacker-controlled infrastructure.
6. Extract leaked Authorization headers, cookies, API keys, or default query parameters from the captured request.
7. Attempt to reuse the leaked values against the intended upstream service or related APIs.

How to detect it

To determine whether exploitation already occurred, review application logs, outbound proxy logs, DNS resolver logs, firewall logs, HTTP client telemetry, and APM traces for Ruby services using Faraday. Focus on requests from services that normally contact fixed upstream API hosts but instead made outbound connections to unusual external domains or IP addresses. Look for request paths or parameters containing protocol-relative values beginning with double slashes, especially in webhook, callback, import, integration, or URL-fetching features. Compare observed outbound destinations against the expected allowlist for each service. Inspect reverse proxy and application access logs for user-supplied values that later correlate with outbound requests to the same domain. If available, review egress logs for requests that included Authorization headers, cookies, API keys, or sensitive query parameters when sent to unrecognized hosts. There are no known threat actors or public exploitation campaigns in the provided data, so detection should be behavior-based rather than signature-only.

• URI.parse("//
• URI("//
• Addressable::URI.parse("//
• Faraday::Connection#build_exclusive_url
• build_exclusive_url
• Authorization: Bearer
• Authorization: Basic
• api_key=
• access_token=
• client_secret=
• callback=//
• url=//
• target=//
• redirect=//
• webhook=//

What your security team should do

• Inventory all Ruby applications and services that include Faraday and identify versions 2.0.0 through 2.14.1.
• Upgrade affected applications to Faraday 2.14.3 or later and redeploy dependent services.
• Prioritize services that use Faraday with Authorization headers, API keys, cookies, default query parameters, or access to sensitive internal or cloud APIs.
• Search code for user-influenced URI object construction passed into Faraday request methods and replace it with strict relative-path handling or destination allowlists.
• Add application tests for protocol-relative URL inputs beginning with double slashes.
• Review outbound proxy, DNS, and firewall logs for unexpected external destinations contacted by Ruby services using Faraday.
• Rotate any credentials found to have been sent to unexpected hosts.
• Implement egress allowlisting for production services that should only call known upstream APIs.