GHSA-22f2-v57c-j9cx CVE-2024-25126

Rack vulnerable to ReDoS in content type parsing (2nd degree polynomial)

High RubyGems

Severity: 5.3 / 10; High · CVSS 3.1
Exploit chance (EPSS): 35.38%; Chance of exploitation in the next 30 days. Higher than 98.45% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-1333 Inefficient Regular Expression Complexity
Fix: 3.0.9.1; Upgrade rack to this version or later

Description

Summary

module Rack
  class MediaType
    SPLIT_PATTERN = %r{\s*[;,]\s*}

The above regexp is subject to ReDos. 50K blank characters as a prefix to the header will take over 10s to split.

PoC

A simple HTTP request with lots of blank characters in the content-type header:

request["Content-Type"] = (" " * 50_000) + "a,"

Impact

It's a very easy to craft ReDoS. Like all ReDoS the impact is debatable.

Affected versions

RubyGems

Package	Vulnerable	Fixed in
rack	`>= 3.0.0, < 3.0.9.1`	`3.0.9.1`
rack	`>= 0.4, < 2.2.8.1`	`2.2.8.1`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

rack RubyGems → `3.0.9.1`

bundler

bundle update rack # Gemfile: gem "rack", ">= 3.0.9.1"

Severity breakdown

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: None
Availability: Low

Weakness

CWE-1333: Inefficient Regular Expression Complexity

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

How to prevent it

Architecture and Design: Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
System Configuration: Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
Implementation: Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
Implementation: Limit the length of the input that the regular expression will process.

References

Advisories

Packages

github.com/rack/rack

Timeline

Feb 28, 2024 Published
Sep 10, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-g2pf-xv49-m2h5 Rack::Request accepts invalid Host characters, enabling host allowlist bypass	Medium	Also affects rack
GHSA-v6x5-cg8r-vv6x Rack's multipart header parsing allows Denial of Service via escape-heavy quoted parameters	High	Also affects rack
GHSA-qfgr-crr9-7r49 Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing	Medium	Also affects rack
GHSA-rx22-g9mx-qrhv Rack's improper unfolding of folded multipart headers preserves CRLF in parsed parameter values	Medium	Also affects rack
GHSA-q2ww-5357-x388 Rack has Content-Length mismatch in Rack::Files error responses	Medium	Also affects rack
GHSA-qv7j-4883-hwh7 Rack::Sendfile header-based X-Accel-Mapping regex injection enables unauthorized X-Accel-Redirect	High	Also affects rack
GHSA-8vqr-qjwx-82mw Rack's multipart parsing without Content-Length header allows unbounded chunked file uploads	High	Also affects rack
GHSA-x8cg-fq8g-mxfx Rack's multipart byte range processing allows denial of service via excessive overlapping ranges	High	Also affects rack

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor