CVE-2026-54297

What it actually does

Faraday's default nested query parameter encoder/decoder can decode attacker-controlled query strings into arbitrarily deep nested Ruby Hash structures. When Faraday later runs its internal recursive dehash logic over that structure, Ruby can raise an uncaught SystemStackError due to excessive recursion depth. In applications that expose Faraday nested parameter parsing or URL-building behavior to untrusted input, this can crash the current Ruby thread, job, or application worker, causing denial of service. The issue affects Faraday versions from 1.0.0 before 1.10.6 and 2.x before 2.14.3, and is fixed in 1.10.6 and 2.14.3.

Why it matters to the business

Successful exploitation can make Ruby services that rely on vulnerable Faraday query handling unavailable or unstable, especially web workers, API gateways, background jobs, or integration services that process externally supplied URLs or query parameters. The vulnerability is network exploitable, requires no authentication or user interaction, and has high availability impact, but it is not currently listed in CISA KEV and the reported EPSS score is low, suggesting no broad confirmed exploitation at this time. Organizations with many Ruby services or shared libraries using Faraday should still prioritize remediation because a small crafted request may be enough to repeatedly crash workers and degrade service reliability.

How an attack unfolds

An attacker identifies an application endpoint, integration workflow, webhook handler, proxy feature, URL previewer, callback processor, or API path that passes user-controlled query strings into Faraday's nested parameter parsing or URL construction logic. The attacker then sends a request containing a query string with extremely deep nested parameter syntax. Faraday decodes the query into a deeply nested Ruby Hash without enforcing a maximum depth. When Faraday's recursive dehash routine walks the nested structure, the Ruby runtime exceeds its call stack limit and raises SystemStackError. If the application does not catch and isolate that exception, the affected thread or worker terminates. Repeating the request can exhaust application workers or create repeated crashes, resulting in denial of service.

How to fix it

Upgrade Faraday to a fixed version: 1.10.6 for the 1.x release line or 2.14.3 for the 2.x release line. Review dependency lockfiles to ensure the resolved Faraday version is not vulnerable, including transitive usage through SDKs, API clients, and internal shared libraries. If immediate upgrade is not possible, mitigate by rejecting or normalizing query strings with excessive bracket nesting before they reach Faraday, enforcing maximum query length and parameter depth at application, framework, reverse proxy, or WAF layers, and avoiding use of Faraday nested query decoding on untrusted input. Add defensive exception handling around URL/query processing so a SystemStackError or parsing failure does not terminate a long-lived worker, while treating this as a temporary control rather than a replacement for patching.

How to confirm the fix worked

Confirm that dependency resolution selects Faraday 1.10.6 or later on the 1.x line, or 2.14.3 or later on the 2.x line. Check Gemfile.lock, gemspec constraints, container images, and deployed artifacts rather than only source manifests. Run `bundle list | grep faraday`, `bundle info faraday`, or equivalent software composition analysis tooling in build and runtime environments. Test representative endpoints with benign and overly nested query strings in a controlled environment and confirm the service returns a handled client or validation error rather than crashing a worker. Review application and process supervision logs after testing to ensure no SystemStackError, worker restart, or abnormal process exit occurs.

Typical attack path

1. Find a Ruby application or service that uses Faraday and accepts externally controlled URLs, query strings, callback parameters, webhook payloads, or proxy targets.
2. Craft a query string with deeply nested parameter names using bracket notation, such as repeated nested keys.
3. Send the crafted request to a path that causes the application to parse or build nested query parameters through Faraday::NestedParamsEncoder.
4. Trigger Faraday to build an excessively deep nested Ruby Hash.
5. Cause the internal recursive dehash routine to exceed the Ruby stack limit and raise SystemStackError.
6. Repeat requests to crash workers, interrupt jobs, or reduce service capacity until denial of service occurs.

How to detect it

Look for evidence of repeated Ruby stack overflow exceptions, worker crashes, or process restarts shortly after requests containing deeply nested bracket-style query parameters. Relevant sources include Ruby application logs, Rails or Rack request logs, reverse proxy access logs, WAF logs, container orchestration events, process supervisor logs, APM error traces, and crash reporting systems. Search for `SystemStackError`, `stack level too deep`, Faraday encoder/decoder stack frames, and abnormal worker exits correlated with long query strings containing many repeated `[` and `]` characters. Because this is a denial-of-service flaw rather than a code execution issue, durable host artifacts may be minimal; the strongest indicators are request patterns followed by application exceptions or worker restarts. No named threat actors or CISA KEV exploitation are currently associated with this vulnerability in the provided data.

• SystemStackError
• stack level too deep
• Faraday::NestedParamsEncoder
• Faraday::NestedParamsEncoder.decode
• Faraday::NestedParamsEncoder.encode
• faraday/encoders/nested_params_encoder
• worker terminated
• worker timeout
• worker restart
• [[][[]
• %5B%5D%5B
• %5B%5B%5B
• stack level too deep (SystemStackError)

What your security team should do

• Inventory Ruby applications, gems, containers, and vendor SDKs that include Faraday, with special attention to internet-facing services and webhook/API integration components.
• Upgrade affected deployments to Faraday 1.10.6 or 2.14.3 or later, and rebuild/redeploy artifacts that vendor or lock dependencies.
• Add request validation or WAF rules to block excessively nested query parameters and unusually long query strings while patch rollout is in progress.
• Search logs for SystemStackError events and worker restarts correlated with requests containing heavily nested bracketed query parameters.
• Add regression tests for maximum query nesting depth in services that accept user-controlled URLs or query strings.
• Monitor Faraday advisories and dependency scanner results because exploitability depends on application-specific exposure of Faraday query parsing paths.