Package Instance

Rack session gets restored after deletion
### Summary

When using the `Rack::Session::Pool` middleware, simultaneous rack
requests can restore a deleted rack session, which allows the
unauthenticated user to occupy that session.

### Details

[Rack session middleware](https://github.com/rack/rack/blob/v2.2.13/lib/rack/session/abstract/id.rb#L263-L270)
prepares the session at the beginning of request, then saves is back
to the store with possible changes applied by host rack application.
This way the session becomes to be a subject of race conditions in
general sense over concurrent rack requests.

### Impact

When using the `Rack::Session::Pool` middleware, and provided the
attacker can acquire a session cookie (already a major issue), the
session may be restored if the attacker can trigger a long running
request (within that same session) adjacent to the user logging out,
in order to retain illicit access even after a user has attempted to logout.

## Mitigation

- Update to the latest version of `rack`, or
- Ensure your application invalidates sessions atomically by marking
  them as logged out e.g., using a `logged_out` flag, instead of
  deleting them, and check this flag on every request to prevent reuse, or
- Implement a custom session store that tracks session invalidation
  timestamps and refuses to accept session data if the session was
  invalidated after the request began.

### Related

As this code was moved to `rack-session` in Rack 3+, see
<https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj>
for the equivalent advisory in `rack-session` (affecting Rack 3+ only).

Rack has a Possible Information Disclosure Vulnerability
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.

Rack's greedy multipart boundary parsing can cause parser differentials and WAF bypass.
## Summary

`Rack::Multipart::Parser` extracts the `boundary` parameter from
`multipart/form-data` using a greedy regular expression. When a
`Content-Type` header contains multiple `boundary` parameters,
Rack selects the last one rather than the first.

In deployments where an upstream proxy, WAF, or intermediary
interprets the first `boundary` parameter, this mismatch can
allow an attacker to smuggle multipart content past upstream
inspection and have Rack parse a different body structure than
the intermediary validated.

## Details

Rack identifies the multipart boundary using logic equivalent to:

```ruby
MULTIPART = %r|\Amultipart/.*boundary=\"?([^\";,]+)\"?|ni
```

Because the expression is greedy, it matches the last `boundary=`
parameter in a header such as:

```http
Content-Type: multipart/form-data; boundary=safe; boundary=malicious
```

As a result, Rack parses the request body using `malicious`, while
another component may interpret the same header using `safe`.

This creates an interpretation conflict. If an upstream WAF or proxy
inspects multipart parts using the first boundary and Rack later
parses the body using the last boundary, a client may be able to
place malicious form fields or uploaded content in parts that Rack
accepts but the upstream component did not inspect as intended.

This issue is most relevant in layered deployments where security
decisions are made before the request reaches Rack.

## Impact

Applications that accept `multipart/form-data` uploads behind an
inspecting proxy or WAF may be affected.

In such deployments, an attacker may be able to bypass upstream
filtering of uploaded files or form fields by sending a request
with multiple `boundary` parameters and relying on the intermediary
and Rack to parse the request differently.

The practical impact depends on deployment architecture. If no
upstream component relies on a different multipart interpretation,
this behavior may not provide meaningful additional attacker capability.

## Mitigation

* Update to a patched version of Rack that rejects ambiguous multipart
  `Content-Type` headers or parses duplicate `boundary` parameters
  consistently.
* Reject requests containing multiple `boundary` parameters.
* Normalize or regenerate multipart metadata at the trusted edge
  before forwarding requests to Rack.
* Avoid relying on upstream inspection of malformed multipart
  requests unless duplicate parameter handling is explicitly
  consistent across components.

Rack Header Parsing leads to Possible Denial of Service Vulnerability
# Possible Denial of Service Vulnerability in Rack Header Parsing

There is a possible denial of service vulnerability in the header parsing
routines in Rack.  This vulnerability has been assigned the CVE identifier
CVE-2024-26146.

Versions Affected:  All.
Not affected:       None
Fixed Versions:     2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1

Impact
------
Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept and Forwarded
headers are impacted.

Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2
or newer are unaffected.

Releases
--------
The fixed releases are available at the normal locations.

Workarounds
-----------
There are no feasible workarounds for this issue.

Patches
-------
To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

* 2-0-header-redos.patch - Patch for 2.0 series
* 2-1-header-redos.patch - Patch for 2.1 series
* 2-2-header-redos.patch - Patch for 2.2 series
* 3-0-header-redos.patch - Patch for 3.0 series

Credits
-------

Thanks to [svalkanov](https://hackerone.com/svalkanov) for reporting this and
providing patches!

Rack has quadratic complexity in Rack::Utils.select_best_encoding via wildcard Accept-Encoding header
## Summary

`Rack::Utils.select_best_encoding` processes `Accept-Encoding` values
with quadratic time complexity when the header contains many
wildcard (`*`) entries. Because this method is used by `Rack::Deflater`
to choose a response encoding, an unauthenticated attacker can send
a single request with a crafted `Accept-Encoding` header and cause
disproportionate CPU consumption on the compression middleware path.

This results in a denial of service condition for applications
using `Rack::Deflater`.

## Details

`Rack::Utils.select_best_encoding` expands parsed `Accept-Encoding`
values into a list of candidate encodings. When an entry is `*`,
the method computes the set of concrete encodings by subtracting
the encodings already present in the request:

```ruby
if m == "*"
  (available_encodings - accept_encoding.map(&:first)).each do |m2|
    expanded_accept_encoding << [m2, q, preference]
  end
else
  expanded_accept_encoding << [m, q, preference]
end
```

Because `accept_encoding.map(&:first)` is evaluated inside the loop,
it is recomputed for each wildcard entry. If the request contains
`N` wildcard entries, this produces repeated scans over the full
parsed header and causes quadratic behavior.

After expansion, the method also performs additional work over
`expanded_accept_encoding`, including per-entry deletion, which
further increases the cost for large inputs.

`Rack::Deflater` invokes this method for each request when the
middleware is enabled:

```ruby
Utils.select_best_encoding(ENCODINGS, Utils.parse_encodings(accept_encoding))
```

As a result, a client can trigger this expensive code path simply
by sending a large `Accept-Encoding` header containing many
repeated wildcard values.

For example, a request with an approximately 8 KB `Accept-Encoding`
header containing about 1,000 `*;q=0.5` entries can cause roughly
170 ms of CPU time in a single request on the `Rack::Deflater`
path, compared to a negligible baseline for a normal header.

This issue is distinct from CVE-2024-26146. That issue concerned
regular expression denial of service during `Accept` header parsing,
whereas this issue arises later during encoding selection after
the header has already been parsed.

## Impact

Any Rack application using `Rack::Deflater` may be affected.

An unauthenticated attacker can send requests with crafted
`Accept-Encoding` headers to trigger excessive CPU usage in the
encoding selection logic. Repeated requests can consume worker
time disproportionately and reduce application availability.

The attack does not require invalid HTTP syntax or large payload
bodies. A single header-sized request is sufficient to reach the
vulnerable code path.

## Mitigation

* Update to a patched version of Rack in which encoding selection
  does not repeatedly rescan the parsed header for wildcard entries.
* Avoid enabling `Rack::Deflater` on untrusted traffic.
* Apply request filtering or header size / format restrictions
  at the reverse proxy or application boundary to limit abusive
  `Accept-Encoding` values.

ReDoS Vulnerability in Rack::Multipart handle_mime_head
### Summary

There is a denial of service vulnerability in the
Content-Disposition parsing component of Rack. This is very
similar to the previous security issue CVE-2022-44571.

### Details

Carefully crafted input can cause Content-Disposition header
parsing in Rack to take an unexpected amount of time, possibly
resulting in a denial of service attack vector. This header is
used typically used in multipart parsing. Any applications that
parse multipart posts using Rack (virtually all Rails applications)
are impacted.

### Credits

Thanks to [scyoon](https://hackerone.com/scyoon) for reporting
this to the Rails security team

Denial of Service Vulnerability in Rack Multipart Parsing
There is a possible denial of service vulnerability in the multipart parsing
component of Rack.  This vulnerability has been assigned the CVE identifier
CVE-2022-30122.

Versions Affected:  >= 1.2
Not affected:       < 1.2
Fixed Versions:     2.0.9.1, 2.1.4.1, 2.2.3.1

## Impact
Carefully crafted multipart POST requests can cause Rack's multipart parser to
take much longer than expected, leading to a possible denial of service
vulnerability.

Impacted code will use Rack's multipart parser to parse multipart posts.  This
includes directly using the multipart parser like this:

```
params = Rack::Multipart.parse_multipart(env)
```

But it also includes reading POST data from a Rack request object like this:

```
p request.POST # read POST data
p request.params # reads both query params and POST data
```

All users running an affected release should either upgrade or use one of the
workarounds immediately.

## Workarounds
There are no feasible workarounds for this issue.