NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
💎
💎 RubyGems
Not in CISA KEV
MEDIUM severity

CVE-2025-61780 — rack

MEDIUMFix: rack/rack@57277b7

CVE-2025-61780 is a medium-severity (CVSS 5.8) Information Exposure vulnerability in rack. A fix is available for rack — see the affected versions and patch details below.

Rack has Possible Information Disclosure Vulnerability

Also known asGHSA-r657-rxjc-j557
Published
Updated
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2025-61780.

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs46th percentile — riskier than 46% of all scored CVEsHighest risk
0.00%0.35%0.70%1.05%0.0%0.6%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

3 pkgs affected
💎rack💎rack💎rack

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A possible information disclosure vulnerability existed in Rack::Sendfile when running behind a proxy that supports x-sendfile headers (such as Nginx). Specially crafted headers could cause Rack::Sendfile to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.

Details

When Rack::Sendfile received untrusted x-sendfile-type or x-accel-mapping headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was not subject to the proxy's access controls.

An attacker could exploit this by:

  1. Setting a crafted x-sendfile-type: x-accel-redirect header.
  2. Setting a crafted x-accel-mapping header.
  3. Requesting a path that qualifies for proxy-based acceleration.

Impact

Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

  • The application used Rack::Sendfile with a proxy that supports x-accel-redirect (e.g., Nginx).
  • The proxy did not always set or remove the x-sendfile-type and x-accel-mapping headers.
  • The application exposed an endpoint that returned a body responding to .to_path.

Mitigation

  • Upgrade to a fixed version of Rack which requires explicit configuration to enable x-accel-redirect:

    use Rack::Sendfile, "x-accel-redirect"
    
  • Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

    proxy_set_header x-sendfile-type x-accel-redirect;
    proxy_set_header x-accel-mapping /var/www/=/files/;
    
  • Or in Rails applications, disable sendfile completely:

    config.action_dispatch.x_sendfile_header = nil
    

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
💎RubyGemsrackall versions2.2.20bundle update rack --conservative
💎RubyGemsrack≥ 3.0&&< 3.1.183.1.18bundle update rack --conservative
💎RubyGemsrack≥ 3.2&&< 3.2.33.2.3bundle update rack --conservative

Affected Products

1 product · 3 configurations
Application
rackrack
≥ 3.2.0 && < 3.2.3
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rack, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update rack to 2.2.20 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-61780 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

This vulnerability is classified as Moderate severity primarily because exploitation requires a specific deployment scenario meeting all of the following conditions: - The application must use Rack::Sendfile behind a proxy that supports x-accel-redirect (eg. Nginx) - The proxy must not consistently set or remove the…

Workaround published by Red Hat
No mitigation is currently available that meets Red Hat Product Security's standards for usability, deployment, applicability, or stability.
Source: Red Hat security advisory for CVE-2025-61780 (CC BY 4.0)

Frequently Asked Questions

## Summary A possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions. ## Details When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the pro
O3 Security · Impact-Aware SCA

Is CVE-2025-61780 in your dependencies?

Find it across RubyGems, including transitive dependencies.

CVE-2025-61780: rack Info Disclosure — Fixed in 2.2.20