CVE-2026-54297 is a high-severity security vulnerability in faraday (rubygems), affecting versions <= 2.14.2. It is fixed in 2.14.3.
Uncontrolled Recursion in NestedParamsEncoder Allows Stack Exhaustion DoS via Deeply Nested Query Parameters Summary Faraday::NestedParamsEncoder, the default nested query parameter encoder/decoder in Faraday, decodes nested query strings without enforcing a maximum nesting depth. A crafted query string such as: causes Faraday to build a deeply nested Ruby Hash structure. The internal dehash routine then recursively walks this attacker-controlled structure without a depth limit. At sufficient depth, Ruby raises an uncaught SystemStackError (stack level too deep), crashing the calling thread or worker. This can lead to denial of service in applications that pass attacker-controlled query strings to Faraday's nested query parsing or URL-building paths. Affected Product Product: Faraday Repository: https://github.com/lostisland/faraday Tested version: v2.14.2-2-g59334e0 Tested commit: 59334e0e9b19 Ruby version: ruby 3.2.3 Tested component: Faraday::NestedParamsEncoder / Faraday::Utils.parsenestedquery Date tested: 2026-05-24 Vulnerability Type Denial of Service Uncontrolled Recursion Stack Exhaustion Preconditions An application must pass attacker-controlled or attacker-influenced query strings to one of Faraday's nested parameter parsing/building paths. Confirmed reachable paths include: Direct use of the public utility: Normal Faraday request URL building: In the second case, the crash occurs during URL construction before any network request is sent. Impact A relatively small query string can trigger a SystemStackError and crash the calling Ruby thread or worker. In my local test environment, a payload of approximately 9.4 KB was sufficient: Repeated requests with such payloads may cause a denial of service against applications whose request path forwards, parses, or rebuilds attacker-controlled query strings through Faraday. This issue does not provide remote code execution, authentication bypass, or data disclosure. The confirmed impact is availability loss. Technical Details Faraday supports nested query parameters such as: which are decoded into nested Ruby structures. However, Faraday also accepts arbitrarily deep nesting such as: This creates a deeply nested structure similar to: The recursive dehash routine then walks the structure without a maximum depth check. Affected file: Relevant logic: Although the function accepts a depth argument, the value is not used to enforce a maximum depth. Therefore, recursion depth is fully controlled by the input query string. Proof of Concept PoC 1: Direct parser crash Observed result: PoC 2: Normal URL-building crash Observed result: No network request is required; the crash occurs during URL construction. Local Reproduction Results The issue was reproduced locally against Faraday commit 59334e0e9b19. Environment: Full PoC result Minimal depth test URL-building test These results confirm that both direct parsing and normal Faraday URL construction can trigger the stack exhaustion condition. Expected Behavior Faraday should reject excessively deep nested query parameters with a controlled and rescuable exception. For example, behavior similar to Rack's parameter depth limit would prevent stack exhaustion: Actual Behavior Faraday recursively processes attacker-controlled nesting depth and eventually raises: This exception indicates stack exhaustion and can crash the calling worker/thread. Suggested Fix Add a configurable maximum nesting depth to Faraday::NestedParamsEncoder, similar to Rack's paramdepthlimit. Suggested behavior: Set a default maximum depth, for example 100. Reject keys whose subkey chain exceeds the maximum depth. Raise a normal Faraday::Error or another controlled exception rather than allowing Ruby stack exhaustion. Example patch concept: Then in decodepair: A local patch implementing this approach was tested. With the patch applied: The crash payloads raise a controlled Faraday::Error instead of SystemStackError. Normal nested query parsing still works. Existing encoder/utils tests passed in the local test set: Security Policy Fit Faraday's SECURITY.md states that the 2.x branch is supported for security updates and that vulnerabilities should be reported privately. This issue was reproduced on the current tested 2.x codebase: The report is intended for private disclosure through GitHub Security Advisories and should not be opened as a public issue before maintainer triage. Related Public Discussions / Duplicate Check I searched the public issue tracker, pull requests, changelog, and GitHub Advisory Database for similar reports using terms including: I did not find a public report or fix for this specific NestedParamsEncoder depth-limit / SystemStackError denial-of-service issue. The closest unrelated public items I found were: lostisland/faraday#1107, Infinite recursion (SystemStackError) on load when running with -rdebug with breakpoints This appears unrelated to nested query parameter parsing and Faraday::NestedParamsEncoder. GHSA-33mh-2634-fwr2 / CVE-2026-25765 This concerns a protocol-relative URL / host override issue and does not address nested query parameter recursion or depth limiting. Repo-local checks also found no existing paramdepthlimit or equivalent mitigation in lib/faraday/encoders/nestedparams_encoder.rb. Severity Suggested severity: Medium Rationale: The attack can be triggered over the network in applications that pass attacker-controlled query strings into Faraday's parsing/building paths. The payload is small enough to be practical, approximately 9.4 KB in the local reproduction. No authentication or user interaction is required in affected application patterns. The confirmed impact is availability only. Because Faraday is a library, the exact severity depends on how an application exposes the affected parsing/building path to attacker-controlled input. If the maintainers prefer conservative scoring for library reachability, the availability impact could be adjusted accordingly. Notes This report does not claim remote code execution, authentication bypass, or information disclosure. The confirmed issue is an uncontrolled-recursion denial of service condition caused by missing nesting-depth enforcement in Faraday's nested parameter decoder. No third-party live services were tested. Reproduction was performed only in a local lab environment. Reporter Reported by: Emre Koca Please let me know if you need additional reproduction details, logs, or a patch proposal.
CVE-2026-54297 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.
A fixed version is available (2.14.3). Upgrading removes the vulnerable code path.
rubygems
faraday (<= 2.14.2)faraday → 2.14.3 (rubygems)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-54297 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-54297 is reachable in your applications. Get a demo
Upgrade faraday to 2.14.3 or later to resolve this vulnerability.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-54297 is a high-severity security vulnerability in faraday (rubygems), affecting versions <= 2.14.2. It is fixed in 2.14.3.
CVE-2026-54297 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
faraday (rubygems) versions <= 2.14.2 is affected.
Yes. CVE-2026-54297 is fixed in 2.14.3. Upgrade to this version or later.
Whether CVE-2026-54297 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
Upgrade faraday to 2.14.3 or later.