Skip to content

Commit 583ff06

Browse files
jasnowpostmodern
jasnow
authored and
postmodern
committed
GHSA SYNC: 3 brand new advisories
1 parent e80dfb0 commit 583ff06

File tree

3 files changed

+182
-0
lines changed

3 files changed

+182
-0
lines changed

‎gems/rack/CVE-2025-61780.yml‎

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
---
2+
gem: rack
3+
cve: 2025-61780
4+
ghsa: r657-rxjc-j557
5+
url: https://github.com/rack/rack/security/advisories/GHSA-r657-rxjc-j557
6+
title: Rack has a Possible Information Disclosure Vulnerability
7+
date: 2025-10-10
8+
description: |
9+
## Summary
10+
11+
A possible information disclosure vulnerability existed in
12+
`Rack::Sendfile` when running behind a proxy that supports
13+
`x-sendfile` headers (such as Nginx). Specially crafted headers
14+
could cause `Rack::Sendfile` to miscommunicate with the proxy and
15+
trigger unintended internal requests, potentially bypassing
16+
proxy-level access restrictions.
17+
18+
## Details
19+
20+
When `Rack::Sendfile` received untrusted `x-sendfile-type` or
21+
`x-accel-mapping` headers from a client, it would interpret them
22+
as proxy configuration directives. This could cause the middleware
23+
to send a "redirect" response to the proxy, prompting it to reissue
24+
a new internal request that was
25+
**not subject to the proxy's access controls**.
26+
27+
An attacker could exploit this by:
28+
1. Setting a crafted `x-sendfile-type: x-accel-redirect` header.
29+
2. Setting a crafted `x-accel-mapping` header.
30+
3. Requesting a path that qualifies for proxy-based acceleration.
31+
32+
## Impact
33+
34+
Attackers could bypass proxy-enforced restrictions and access internal
35+
endpoints intended to be protected (such as administrative pages).
36+
The vulnerability did not allow arbitrary file reads but could
37+
expose sensitive application routes.
38+
39+
This issue only affected systems meeting all of the following conditions:
40+
41+
* The application used `Rack::Sendfile` with a proxy that supports
42+
`x-accel-redirect` (e.g., Nginx).
43+
* The proxy did **not** always set or remove the `x-sendfile-type`
44+
and `x-accel-mapping` headers.
45+
* The application exposed an endpoint that returned a body
46+
responding to `.to_path`.
47+
48+
## Mitigation
49+
50+
* Upgrade to a fixed version of Rack which requires explicit
51+
configuration to enable `x-accel-redirect`:
52+
53+
```ruby
54+
use Rack::Sendfile, "x-accel-redirect"
55+
```
56+
57+
* Alternatively, configure the proxy to always set or strip
58+
the headers (you should be doing this!):
59+
60+
```nginx
61+
proxy_set_header x-sendfile-type x-accel-redirect;
62+
proxy_set_header x-accel-mapping /var/www/=/files/;
63+
```
64+
65+
* Or in Rails applications, disable sendfile completely:
66+
67+
```ruby
68+
config.action_dispatch.x_sendfile_header = nil
69+
```
70+
cvss_v3: 5.8
71+
patched_versions:
72+
- "~> 2.2.20"
73+
- "~> 3.1.18"
74+
- ">= 3.2.3"
75+
related:
76+
url:
77+
- https://github.com/rack/rack/security/advisories/GHSA-r657-rxjc-j557
78+
- https://github.com/rack/rack/commit/57277b7741581fa827472c5c666f6e6a33abd784
79+
- https://github.com/rack/rack/commit/7e69f65eefe9cd2868df9f9f3b0977b86f93523a
80+
- https://github.com/rack/rack/commit/fba2c8bc63eb787ff4b19bc612d315fda6126d85
81+
- https://github.com/advisories/GHSA-r657-rxjc-j557

‎gems/rack/CVE-2025-61919.yml‎

Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
---
2+
gem: rack
3+
cve: 2025-61919
4+
ghsa: 6xw4-3v39-52mm
5+
url: https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm
6+
title: Rack is vulnerable to a memory-exhaustion DoS through
7+
unbounded URL-encoded body parsing
8+
date: 2025-10-10
9+
description: |
10+
## Summary
11+
12+
`Rack::Request#POST` reads the entire request body into memory for
13+
`Content-Type: application/x-www-form-urlencoded`, calling
14+
`rack.input.read(nil)` without enforcing a length or cap. Large
15+
request bodies can therefore be buffered completely into process
16+
memory before parsing, leading to denial of service (DoS) through
17+
memory exhaustion.
18+
19+
## Details
20+
21+
When handling non-multipart form submissions, Rack’s request
22+
parser performs:
23+
24+
```ruby
25+
form_vars = get_header(RACK_INPUT).read
26+
```
27+
28+
Since `read` is called with no argument, the entire request body is
29+
loaded into a Ruby `String`. This occurs before query parameter
30+
parsing or enforcement of any `params_limit`. As a result, Rack
31+
applications without an upstream body-size limit can experience
32+
unbounded memory allocation proportional to request size.
33+
34+
## Impact
35+
36+
Attackers can send large `application/x-www-form-urlencoded` bodies
37+
to consume process memory, causing slowdowns or termination by the
38+
operating system (OOM). The effect scales linearly with request
39+
size and concurrency. Even with parsing limits configured, the
40+
issue occurs *before* those limits are enforced.
41+
42+
## Mitigation
43+
44+
* Update to a patched version of Rack that enforces form parameter
45+
limits using `query_parser.bytesize_limit`, preventing unbounded
46+
reads of `application/x-www-form-urlencoded` bodies.
47+
* Enforce strict maximum body size at the proxy or web server layer
48+
(e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).
49+
cvss_v3: 7.5
50+
patched_versions:
51+
- "~> 2.2.20"
52+
- "~> 3.1.18"
53+
- ">= 3.2.3"
54+
related:
55+
url:
56+
- https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm
57+
- https://github.com/rack/rack/commit/4e2c903991a790ee211a3021808ff4fd6fe82881
58+
- https://github.com/rack/rack/commit/cbd541e8a3d0c5830a3c9a30d3718ce2e124f9db
59+
- https://github.com/rack/rack/commit/e179614c4a653283286f5f046428cbb85f21146f
60+
- https://github.com/advisories/GHSA-6xw4-3v39-52mm

‎gems/sinatra/CVE-2025-61921.yml‎

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
---
2+
gem: sinatra
3+
cve: 2025-61921
4+
ghsa: mr3q-g2mv-mr4q
5+
url: https://github.com/sinatra/sinatra/security/advisories/GHSA-mr3q-g2mv-mr4q
6+
title: Sinatra is vulnerable to ReDoS through ETag header value generation
7+
date: 2025-10-10
8+
description: |
9+
### Summary
10+
11+
There is a denial of service vulnerability in the `If-Match` and
12+
`If-None-Match` header parsing component of Sinatra, if the `etag`
13+
method is used when constructing the response and you are using Ruby < 3.2.
14+
15+
### Details
16+
17+
Carefully crafted input can cause `If-Match` and `If-None-Match`
18+
header parsing in Sinatra to take an unexpected amount of time,
19+
possibly resulting in a denial of service attack vector. This header
20+
is typically involved in generating the `ETag` header value. Any
21+
applications that use the `etag` method when generating a response
22+
are impacted if they are using Ruby below version 3.2.
23+
24+
### Resources
25+
26+
* https://github.com/sinatra/sinatra/issues/2120 (report)
27+
* https://github.com/sinatra/sinatra/pull/2121 (fix)
28+
* https://github.com/sinatra/sinatra/pull/1823 (older ReDoS vulnerability)
29+
* https://bugs.ruby-lang.org/issues/19104 (fix in Ruby >= 3.2)
30+
patched_versions:
31+
- ">= 4.2.0"
32+
related:
33+
url:
34+
- https://github.com/sinatra/sinatra/security/advisories/GHSA-mr3q-g2mv-mr4q
35+
- https://github.com/sinatra/sinatra/issues/2120
36+
- https://github.com/sinatra/sinatra/pull/1823
37+
- https://github.com/sinatra/sinatra/pull/2121
38+
- https://github.com/sinatra/sinatra/commit/3fe8c38dc405586f7ad8f2ac748aa53e9c3615bd
39+
- https://github.com/sinatra/sinatra/commit/8ff496bd4877520599e1479d6efead39304edceb
40+
- https://bugs.ruby-lang.org/issues/19104
41+
- https://github.com/advisories/GHSA-mr3q-g2mv-mr4q

0 commit comments

Comments
 (0)