Skip to content

Commit d6f66eb

Browse files
advisory-database[bot]advisory-database[bot]
committed
Publish Advisories
GHSA-qfgr-crr9-7r49 GHSA-rx22-g9mx-qrhv GHSA-v6x5-cg8r-vv6x GHSA-vgpv-f759-9wx3
1 parent 70f9bad commit d6f66eb

4 files changed

Lines changed: 322 additions & 0 deletions

File tree

‎advisories/github-reviewed/2026/04/GHSA-qfgr-crr9-7r49/GHSA-qfgr-crr9-7r49.json‎

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-qfgr-crr9-7r49",
4+
"modified": "2026-04-02T20:31:52Z",
5+
"published": "2026-04-02T20:31:52Z",
6+
"aliases": [
7+
"CVE-2026-32762"
8+
],
9+
"summary": "Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing",
10+
"details": "## Summary\n\n`Rack::Utils.forwarded_values` parses the RFC 7239 `Forwarded` header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\ncan be interpreted by Rack as multiple `Forwarded` directives rather than as a single quoted `for` value.\n\nIn deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted `Forwarded` values differently, this discrepancy can allow an attacker to smuggle `host`, `proto`, `for`, or `by` parameters through a single header value.\n\n## Details\n\n`Rack::Utils.forwarded_values` processes the header using logic equivalent to:\n\n```ruby\nforwarded_header.split(';').each_with_object({}) do |field, values|\n field.split(',').each do |pair|\n pair = pair.split('=').map(&:strip).join('=')\n return nil unless pair =~ /\\A(by|for|host|proto)=\"?([^\"]+)\"?\\Z/i\n (values[$1.downcase.to_sym] ||= []) << $2\n end\nend\n```\n\nThe method splits on `;` before it parses individual `name=value` pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content.\n\nAs a result, a header value such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\nis not treated as a single `for` value. Instead, Rack may interpret it as if the client had supplied separate `for`, `host`, and `proto` directives.\n\nThis creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.\n\n## Impact\n\nApplications that rely on `Forwarded` to derive request metadata may observe attacker-controlled values for `host`, `proto`, `for`, or related URL components.\n\nIn affected deployments, this can lead to host or scheme spoofing in derived values such as `req.host`, `req.scheme`, `req.base_url`, or `req.url`. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact.\n\nThe practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted `Forwarded` parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same `Forwarded` header differently.\n\n## Mitigation\n\n* Update to a patched version of Rack that parses `Forwarded` quoted-string values before splitting on parameter delimiters.\n* Avoid trusting client-supplied `Forwarded` headers unless they are normalized or regenerated by a trusted reverse proxy.\n* Prefer stripping inbound `Forwarded` headers at the edge and reconstructing them from trusted proxy metadata.\n* Avoid using `req.host`, `req.scheme`, `req.base_url`, or `req.url` for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/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": "3.0.0.beta1"
29+
},
30+
{
31+
"fixed": "3.1.21"
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.2.0"
48+
},
49+
{
50+
"fixed": "3.2.6"
51+
}
52+
]
53+
}
54+
]
55+
}
56+
],
57+
"references": [
58+
{
59+
"type": "WEB",
60+
"url": "https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49"
61+
},
62+
{
63+
"type": "ADVISORY",
64+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32762"
65+
},
66+
{
67+
"type": "PACKAGE",
68+
"url": "https://github.com/rack/rack"
69+
}
70+
],
71+
"database_specific": {
72+
"cwe_ids": [
73+
"CWE-436"
74+
],
75+
"severity": "MODERATE",
76+
"github_reviewed": true,
77+
"github_reviewed_at": "2026-04-02T20:31:52Z",
78+
"nvd_published_at": "2026-04-02T18:16:27Z"
79+
}
80+
}

‎advisories/github-reviewed/2026/04/GHSA-rx22-g9mx-qrhv/GHSA-rx22-g9mx-qrhv.json‎

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-rx22-g9mx-qrhv",
4+
"modified": "2026-04-02T20:31:02Z",
5+
"published": "2026-04-02T20:31:01Z",
6+
"aliases": [
7+
"CVE-2026-26962"
8+
],
9+
"summary": "Rack's improper unfolding of folded multipart headers preserves CRLF in parsed parameter values",
10+
"details": "## Summary\n\n`Rack::Multipart::Parser` unfolds folded multipart part headers incorrectly. When a multipart header contains an obs-fold sequence, Rack preserves the embedded CRLF in parsed parameter values such as `filename` or `name` instead of removing the folded line break during unfolding.\n\nAs a result, applications that later reuse those parsed values in HTTP response headers may be vulnerable to downstream header injection or response splitting.\n\n## Details\n\n`Rack::Multipart::Parser` accepts folded multipart header values and unfolds them during parsing. However, the unfolding behavior does not fully remove the embedded line break sequence from the parsed value.\n\nThis means a multipart part header such as:\n\n```http\nContent-Disposition: form-data; name=\"file\"; filename=\"test\\r\\n foo.txt\"\n```\n\ncan result in a parsed parameter value that still contains CRLF characters.\n\nThe issue is not that Rack creates a second multipart header field. Rather, the problem is that CRLF remains embedded in the parsed metadata value after unfolding. If an application later uses that value in a security-sensitive context, such as constructing an HTTP response header, the preserved CRLF may alter downstream header parsing.\n\nAffected values may include multipart parameters such as `filename`, `name`, or similar parsed header attributes.\n\n## Impact\n\nApplications that accept multipart form uploads may be affected if they later reuse parsed multipart metadata in HTTP headers or other header-sensitive contexts.\n\nIn affected deployments, an attacker may be able to supply a multipart parameter value containing folded line breaks and cause downstream header injection, response splitting, cache poisoning, or related response parsing issues.\n\nThe practical impact depends on application behavior. If parsed multipart metadata is not reused in HTTP headers, the issue may be limited to incorrect parsing behavior rather than a direct exploit path.\n\n## Mitigation\n\n* Update to a patched version of Rack that removes CRLF correctly when unfolding folded multipart header values.\n* Avoid copying upload metadata such as `filename` directly into HTTP response headers without sanitization.\n* Sanitize or reject carriage return and line feed characters in multipart-derived values before reusing them in response headers, logs, or downstream protocol contexts.\n* Where feasible, normalize uploaded filenames before storing or reflecting them.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/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": "3.2.0"
29+
},
30+
{
31+
"fixed": "3.2.6"
32+
}
33+
]
34+
}
35+
]
36+
}
37+
],
38+
"references": [
39+
{
40+
"type": "WEB",
41+
"url": "https://github.com/rack/rack/security/advisories/GHSA-rx22-g9mx-qrhv"
42+
},
43+
{
44+
"type": "ADVISORY",
45+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26962"
46+
},
47+
{
48+
"type": "PACKAGE",
49+
"url": "https://github.com/rack/rack"
50+
}
51+
],
52+
"database_specific": {
53+
"cwe_ids": [
54+
"CWE-93"
55+
],
56+
"severity": "MODERATE",
57+
"github_reviewed": true,
58+
"github_reviewed_at": "2026-04-02T20:31:01Z",
59+
"nvd_published_at": "2026-04-02T18:16:26Z"
60+
}
61+
}

‎advisories/github-reviewed/2026/04/GHSA-v6x5-cg8r-vv6x/GHSA-v6x5-cg8r-vv6x.json‎

Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-v6x5-cg8r-vv6x",
4+
"modified": "2026-04-02T20:30:12Z",
5+
"published": "2026-04-02T20:30:12Z",
6+
"aliases": [
7+
"CVE-2026-34827"
8+
],
9+
"summary": "Rack's multipart header parsing allows Denial of Service via escape-heavy quoted parameters",
10+
"details": "## Summary\n\n`Rack::Multipart::Parser#handle_mime_head` parses quoted multipart parameters such as `Content-Disposition: form-data; name=\"...\"` using repeated `String#index` searches combined with `String#slice!` prefix deletion. For escape-heavy quoted values, this causes super-linear processing.\n\nAn unauthenticated attacker can send a crafted `multipart/form-data` request containing many parts with long backslash-escaped parameter values to trigger excessive CPU usage during multipart parsing.\n\nThis results in a denial of service condition in Rack applications that accept multipart form data.\n\n## Details\n\n`Rack::Multipart::Parser#handle_mime_head` parses quoted parameter values by repeatedly:\n\n1. Searching for the next quote or backslash,\n2. Copying the preceding substring into a new buffer, and\n3. Removing the processed prefix from the original string with `slice!`.\n\nAn attacker can exploit this by sending a multipart request with many parts whose `name` parameters contain long escape-heavy values such as:\n\n```text\nname=\"a\\\\a\\\\a\\\\a\\\\a\\\\...\"\n```\n\nUnder default Rack limits, a request can contain up to 4095 parts. If many of those parts use long quoted values with dense escape characters, the parser performs disproportionately expensive CPU work while remaining within normal request size and part-count limits.\n\n## Impact\n\nAny Rack application that accepts `multipart/form-data` requests may be affected, including file upload endpoints and standard HTML form handlers.\n\nAn unauthenticated attacker can send crafted multipart requests that consume excessive CPU time during request parsing. Repeated requests can tie up application workers, reduce throughput, and degrade or deny service availability.\n\n## Mitigation\n\n* Update to a patched version of Rack that parses quoted multipart parameters without repeated rescanning and destructive prefix deletion.\n* Apply request throttling or rate limiting to multipart upload endpoints.\n* Where operationally feasible, restrict or isolate multipart parsing on untrusted high-volume 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": "3.0.0.beta1"
29+
},
30+
{
31+
"fixed": "3.1.21"
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.2.0"
48+
},
49+
{
50+
"fixed": "3.2.6"
51+
}
52+
]
53+
}
54+
]
55+
}
56+
],
57+
"references": [
58+
{
59+
"type": "WEB",
60+
"url": "https://github.com/rack/rack/security/advisories/GHSA-v6x5-cg8r-vv6x"
61+
},
62+
{
63+
"type": "ADVISORY",
64+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34827"
65+
},
66+
{
67+
"type": "PACKAGE",
68+
"url": "https://github.com/rack/rack"
69+
}
70+
],
71+
"database_specific": {
72+
"cwe_ids": [
73+
"CWE-400",
74+
"CWE-407",
75+
"CWE-770"
76+
],
77+
"severity": "HIGH",
78+
"github_reviewed": true,
79+
"github_reviewed_at": "2026-04-02T20:30:12Z",
80+
"nvd_published_at": "2026-04-02T18:16:33Z"
81+
}
82+
}

‎advisories/github-reviewed/2026/04/GHSA-vgpv-f759-9wx3/GHSA-vgpv-f759-9wx3.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-vgpv-f759-9wx3",
4+
"modified": "2026-04-02T20:30:40Z",
5+
"published": "2026-04-02T20:30:40Z",
6+
"aliases": [
7+
"CVE-2026-26961"
8+
],
9+
"summary": "Rack's greedy multipart boundary parsing can cause parser differentials and WAF bypass.",
10+
"details": "## Summary\n\n`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.\n\nIn 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.\n\n## Details\n\nRack identifies the multipart boundary using logic equivalent to:\n\n```ruby\nMULTIPART = %r|\\Amultipart/.*boundary=\\\"?([^\\\";,]+)\\\"?|ni\n```\n\nBecause the expression is greedy, it matches the last `boundary=` parameter in a header such as:\n\n```http\nContent-Type: multipart/form-data; boundary=safe; boundary=malicious\n```\n\nAs a result, Rack parses the request body using `malicious`, while another component may interpret the same header using `safe`.\n\nThis 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.\n\nThis issue is most relevant in layered deployments where security decisions are made before the request reaches Rack.\n\n## Impact\n\nApplications that accept `multipart/form-data` uploads behind an inspecting proxy or WAF may be affected.\n\nIn 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.\n\nThe 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.\n\n## Mitigation\n\n* Update to a patched version of Rack that rejects ambiguous multipart `Content-Type` headers or parses duplicate `boundary` parameters consistently.\n* Reject requests containing multiple `boundary` parameters.\n* Normalize or regenerate multipart metadata at the trusted edge before forwarding requests to Rack.\n* Avoid relying on upstream inspection of malformed multipart requests unless duplicate parameter handling is explicitly consistent across components.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/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-vgpv-f759-9wx3"
80+
},
81+
{
82+
"type": "ADVISORY",
83+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26961"
84+
},
85+
{
86+
"type": "PACKAGE",
87+
"url": "https://github.com/rack/rack"
88+
}
89+
],
90+
"database_specific": {
91+
"cwe_ids": [
92+
"CWE-436"
93+
],
94+
"severity": "LOW",
95+
"github_reviewed": true,
96+
"github_reviewed_at": "2026-04-02T20:30:40Z",
97+
"nvd_published_at": "2026-04-02T17:16:21Z"
98+
}
99+
}

0 commit comments

Comments
 (0)