Skip to content

Commit e2555d2

Browse files
advisory-database[bot]advisory-database[bot]
committed
Publish Advisories
GHSA-7mqq-6cf9-v2qp GHSA-8vqr-qjwx-82mw GHSA-v569-hp3g-36wr
1 parent d6f66eb commit e2555d2

3 files changed

Lines changed: 299 additions & 0 deletions

File tree

‎advisories/github-reviewed/2026/04/GHSA-7mqq-6cf9-v2qp/GHSA-7mqq-6cf9-v2qp.json‎

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-7mqq-6cf9-v2qp",
4+
"modified": "2026-04-02T20:32:42Z",
5+
"published": "2026-04-02T20:32:42Z",
6+
"aliases": [
7+
"CVE-2026-34763"
8+
],
9+
"summary": "Rack has a root directory disclosure via unescaped regex interpolation in Rack::Directory",
10+
"details": "## Summary\n\n`Rack::Directory` interpolates the configured `root` path directly into a regular expression when deriving the displayed directory path. If `root` contains regex metacharacters such as `+`, `*`, or `.`, the prefix stripping can fail and the generated directory listing may expose the full filesystem path in the HTML output.\n\n## Details\n\n`Rack::Directory::DirectoryBody#each` computes the visible path using code equivalent to:\n\n```ruby\nshow_path = Utils.escape_html(path.sub(/\\A#{root}/, ''))\n```\n\nHere, `root` is a developer-configured filesystem path. It is normalized earlier with `File.expand_path(root)` and then inserted directly into a regular expression without escaping.\n\nBecause the value is treated as regex syntax rather than as a literal string, metacharacters in the configured path can change how the prefix match behaves. When that happens, the expected root prefix is not removed from `path`, and the absolute filesystem path is rendered into the HTML directory listing.\n\n## Impact\n\nIf `Rack::Directory` is configured to serve a directory whose absolute path contains regex metacharacters, the generated directory listing may disclose the full server filesystem path instead of only the request-relative path.\n\nThis can expose internal deployment details such as directory layout, usernames, mount points, or naming conventions that would otherwise not be visible to clients.\n\n## Mitigation\n\n* Update to a patched version of Rack in which the root prefix is removed using an escaped regular expression.\n* Avoid using `Rack::Directory` with a root path that contains regular expression metacharacters.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "RubyGems",
21+
"name": "rack"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "2.2.23"
32+
}
33+
]
34+
}
35+
]
36+
},
37+
{
38+
"package": {
39+
"ecosystem": "RubyGems",
40+
"name": "rack"
41+
},
42+
"ranges": [
43+
{
44+
"type": "ECOSYSTEM",
45+
"events": [
46+
{
47+
"introduced": "3.0.0.beta1"
48+
},
49+
{
50+
"fixed": "3.1.21"
51+
}
52+
]
53+
}
54+
]
55+
},
56+
{
57+
"package": {
58+
"ecosystem": "RubyGems",
59+
"name": "rack"
60+
},
61+
"ranges": [
62+
{
63+
"type": "ECOSYSTEM",
64+
"events": [
65+
{
66+
"introduced": "3.2.0"
67+
},
68+
{
69+
"fixed": "3.2.6"
70+
}
71+
]
72+
}
73+
]
74+
}
75+
],
76+
"references": [
77+
{
78+
"type": "WEB",
79+
"url": "https://github.com/rack/rack/security/advisories/GHSA-7mqq-6cf9-v2qp"
80+
},
81+
{
82+
"type": "ADVISORY",
83+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34763"
84+
},
85+
{
86+
"type": "PACKAGE",
87+
"url": "https://github.com/rack/rack"
88+
}
89+
],
90+
"database_specific": {
91+
"cwe_ids": [
92+
"CWE-625"
93+
],
94+
"severity": "MODERATE",
95+
"github_reviewed": true,
96+
"github_reviewed_at": "2026-04-02T20:32:42Z",
97+
"nvd_published_at": "2026-04-02T17:16:24Z"
98+
}
99+
}

‎advisories/github-reviewed/2026/04/GHSA-8vqr-qjwx-82mw/GHSA-8vqr-qjwx-82mw.json‎

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-8vqr-qjwx-82mw",
4+
"modified": "2026-04-02T20:34:48Z",
5+
"published": "2026-04-02T20:34:48Z",
6+
"aliases": [
7+
"CVE-2026-34829"
8+
],
9+
"summary": "Rack's multipart parsing without Content-Length header allows unbounded chunked file uploads",
10+
"details": "## Summary\n\n`Rack::Multipart::Parser` only wraps the request body in a `BoundedIO` when `CONTENT_LENGTH` is present. When a `multipart/form-data` request is sent without a `Content-Length` header, such as with HTTP chunked transfer encoding, multipart parsing continues until end-of-stream with no total size limit.\n\nFor file parts, the uploaded body is written directly to a temporary file on disk rather than being constrained by the buffered in-memory upload limit. An unauthenticated attacker can therefore stream an arbitrarily large multipart file upload and consume unbounded disk space.\n\nThis results in a denial of service condition for Rack applications that accept multipart form data.\n\n## Details\n\n`Rack::Multipart::Parser.parse` applies `BoundedIO` only when `content_length` is not `nil`:\n\n```ruby\nio = BoundedIO.new(io, content_length) if content_length\n```\n\nWhen `CONTENT_LENGTH` is absent, the parser reads the multipart body until EOF without a global byte limit.\n\nAlthough Rack enforces `BUFFERED_UPLOAD_BYTESIZE_LIMIT` for retained non-file parts, file uploads are handled differently. When a multipart part includes a filename, the body is streamed to a `Tempfile`, and the retained-size accounting is not applied to that file content. As a result, file parts are not subject to the same upload size bound.\n\nAn attacker can exploit this by sending a chunked `multipart/form-data` request containing a file part and continuously streaming data without declaring a `Content-Length`. Rack will continue writing the uploaded data to disk until the client stops or the server exhausts available storage.\n\n## Impact\n\nAny Rack application that accepts `multipart/form-data` uploads may be affected if no upstream component enforces a request body size limit.\n\nAn unauthenticated attacker can send a large chunked file upload to consume disk space on the application host. This may cause request failures, application instability, or broader service disruption if the host runs out of available storage.\n\nThe practical impact depends on deployment architecture. Reverse proxies or application servers that enforce upload limits may reduce or eliminate exploitability, but Rack itself does not impose a total multipart upload limit in this code path when `CONTENT_LENGTH` is absent.\n\n## Mitigation\n\n* Update to a patched version of Rack that enforces a total multipart upload size limit even when `CONTENT_LENGTH` is absent.\n* Enforce request body size limits at the reverse proxy or application server.\n* Isolate temporary upload storage and monitor disk consumption for multipart endpoints.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "RubyGems",
21+
"name": "rack"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "2.2.23"
32+
}
33+
]
34+
}
35+
]
36+
},
37+
{
38+
"package": {
39+
"ecosystem": "RubyGems",
40+
"name": "rack"
41+
},
42+
"ranges": [
43+
{
44+
"type": "ECOSYSTEM",
45+
"events": [
46+
{
47+
"introduced": "3.0.0.beta1"
48+
},
49+
{
50+
"fixed": "3.1.21"
51+
}
52+
]
53+
}
54+
]
55+
},
56+
{
57+
"package": {
58+
"ecosystem": "RubyGems",
59+
"name": "rack"
60+
},
61+
"ranges": [
62+
{
63+
"type": "ECOSYSTEM",
64+
"events": [
65+
{
66+
"introduced": "3.2.0"
67+
},
68+
{
69+
"fixed": "3.2.6"
70+
}
71+
]
72+
}
73+
]
74+
}
75+
],
76+
"references": [
77+
{
78+
"type": "WEB",
79+
"url": "https://github.com/rack/rack/security/advisories/GHSA-8vqr-qjwx-82mw"
80+
},
81+
{
82+
"type": "ADVISORY",
83+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34829"
84+
},
85+
{
86+
"type": "PACKAGE",
87+
"url": "https://github.com/rack/rack"
88+
}
89+
],
90+
"database_specific": {
91+
"cwe_ids": [
92+
"CWE-400",
93+
"CWE-770"
94+
],
95+
"severity": "HIGH",
96+
"github_reviewed": true,
97+
"github_reviewed_at": "2026-04-02T20:34:48Z",
98+
"nvd_published_at": "2026-04-02T17:16:26Z"
99+
}
100+
}

‎advisories/github-reviewed/2026/04/GHSA-v569-hp3g-36wr/GHSA-v569-hp3g-36wr.json‎

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-v569-hp3g-36wr",
4+
"modified": "2026-04-02T20:32:19Z",
5+
"published": "2026-04-02T20:32:19Z",
6+
"aliases": [
7+
"CVE-2026-34230"
8+
],
9+
"summary": "Rack has quadratic complexity in Rack::Utils.select_best_encoding via wildcard Accept-Encoding header",
10+
"details": "## Summary\n\n`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.\n\nThis results in a denial of service condition for applications using `Rack::Deflater`.\n\n## Details\n\n`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:\n\n```ruby\nif m == \"*\"\n (available_encodings - accept_encoding.map(&:first)).each do |m2|\n expanded_accept_encoding << [m2, q, preference]\n end\nelse\n expanded_accept_encoding << [m, q, preference]\nend\n```\n\nBecause `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.\n\nAfter expansion, the method also performs additional work over `expanded_accept_encoding`, including per-entry deletion, which further increases the cost for large inputs.\n\n`Rack::Deflater` invokes this method for each request when the middleware is enabled:\n\n```ruby\nUtils.select_best_encoding(ENCODINGS, Utils.parse_encodings(accept_encoding))\n```\n\nAs a result, a client can trigger this expensive code path simply by sending a large `Accept-Encoding` header containing many repeated wildcard values.\n\nFor 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.\n\nThis 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.\n\n## Impact\n\nAny Rack application using `Rack::Deflater` may be affected.\n\nAn 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.\n\nThe attack does not require invalid HTTP syntax or large payload bodies. A single header-sized request is sufficient to reach the vulnerable code path.\n\n## Mitigation\n\n* Update to a patched version of Rack in which encoding selection does not repeatedly rescan the parsed header for wildcard entries.\n* Avoid enabling `Rack::Deflater` on untrusted traffic.\n* Apply request filtering or header size / format restrictions at the reverse proxy or application boundary to limit abusive `Accept-Encoding` values.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "RubyGems",
21+
"name": "rack"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "2.2.23"
32+
}
33+
]
34+
}
35+
]
36+
},
37+
{
38+
"package": {
39+
"ecosystem": "RubyGems",
40+
"name": "rack"
41+
},
42+
"ranges": [
43+
{
44+
"type": "ECOSYSTEM",
45+
"events": [
46+
{
47+
"introduced": "3.0.0.beta1"
48+
},
49+
{
50+
"fixed": "3.1.21"
51+
}
52+
]
53+
}
54+
]
55+
},
56+
{
57+
"package": {
58+
"ecosystem": "RubyGems",
59+
"name": "rack"
60+
},
61+
"ranges": [
62+
{
63+
"type": "ECOSYSTEM",
64+
"events": [
65+
{
66+
"introduced": "3.2.0"
67+
},
68+
{
69+
"fixed": "3.2.6"
70+
}
71+
]
72+
}
73+
]
74+
}
75+
],
76+
"references": [
77+
{
78+
"type": "WEB",
79+
"url": "https://github.com/rack/rack/security/advisories/GHSA-v569-hp3g-36wr"
80+
},
81+
{
82+
"type": "ADVISORY",
83+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34230"
84+
},
85+
{
86+
"type": "PACKAGE",
87+
"url": "https://github.com/rack/rack"
88+
}
89+
],
90+
"database_specific": {
91+
"cwe_ids": [
92+
"CWE-400",
93+
"CWE-407"
94+
],
95+
"severity": "MODERATE",
96+
"github_reviewed": true,
97+
"github_reviewed_at": "2026-04-02T20:32:19Z",
98+
"nvd_published_at": "2026-04-02T17:16:23Z"
99+
}
100+
}

0 commit comments

Comments
 (0)