Skip to content

Commit f939ab8

Browse files
authored
Merge branch 'rubysec:master' into ghsa-syncbot-2026-02-15-10_46_39
2 parents 1d4b180 + ff594be commit f939ab8

File tree

4 files changed

+143
-0
lines changed

4 files changed

+143
-0
lines changed
Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
---
2+
gem: nokogiri
3+
ghsa: wx95-c6cv-8532
4+
url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-wx95-c6cv-8532
5+
title: Nokogiri does not check the return value from xmlC14NExecute
6+
date: 2026-02-18
7+
description: |
8+
## Summary
9+
10+
Nokogiri's CRuby extension fails to check the return value from
11+
`xmlC14NExecute` in the method `Nokogiri::XML::Document#canonicalize`
12+
and `Nokogiri::XML::Node#canonicalize`. When canonicalization fails,
13+
an empty string is returned instead of raising an exception. This
14+
incorrect return value may allow downstream libraries to accept
15+
invalid or incomplete canonicalized XML, which has been demonstrated
16+
to enable signature validation bypass in SAML libraries.
17+
18+
JRuby is not affected, as the Java implementation correctly
19+
raises `RuntimeError` on canonicalization failure.
20+
21+
## Mitigation
22+
23+
Upgrade to Nokogiri `>= 1.19.1`.
24+
25+
## Severity
26+
27+
The maintainers have assessed this as **Medium** severity. Nokogiri
28+
itself is a parsing library without a clear security boundary
29+
related to canonicalization, so the direct impact is that a method
30+
returns incorrect data on invalid input. However, this behavior
31+
was exploited in practice to bypass SAML signature validation
32+
in downstream libraries (see References).
33+
34+
## Credit
35+
36+
This vulnerability was responsibly reported by HackerOne
37+
researcher `d4d`.
38+
cvss_v3: 5.3
39+
unaffected_versions:
40+
- "< 1.5.1"
41+
patched_versions:
42+
- ">= 1.19.1"
43+
related:
44+
url:
45+
- https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-wx95-c6cv-8532
46+
- https://github.com/advisories/GHSA-wx95-c6cv-8532

gems/rack/CVE-2026-22860.yml

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
---
2+
gem: rack
3+
cve: 2026-22860
4+
ghsa: mxw3-3hh2-x2mh
5+
url: https://github.com/rack/rack/security/advisories/GHSA-mxw3-3hh2-x2mh
6+
title: Rack has a Directory Traversal via Rack:Directory
7+
date: 2026-02-17
8+
description: |-
9+
## Summary
10+
11+
`Rack::Directory`’s path check used a string prefix match
12+
on the expanded path. A request like `/../root_example/` can escape the configured
13+
root if the target path starts with the root string, allowing directory listing
14+
outside the intended root.
15+
16+
## Details
17+
18+
In `directory.rb`, `File.expand_path(File.join(root,
19+
path_info)).start_with?(root)` does not enforce a path boundary. If the server root
20+
is `/var/www/root`, a path like `/var/www/root_backup` passes the check because
21+
it shares the same prefix, so `Rack::Directory` will list that directory also.
22+
23+
## Impact
24+
25+
Information disclosure via directory listing outside the configured root
26+
when `Rack::Directory` is exposed to untrusted clients and a directory shares the
27+
root prefix (e.g., `public2`, `www_backup`).
28+
29+
## Mitigation
30+
31+
* Update to a patched
32+
version of Rack that correctly checks the root prefix.\n* Don't name directories
33+
with the same prefix as one which is exposed via `Rack::Directory`."
34+
cvss_v3: 7.5
35+
patched_versions:
36+
- "~> 2.2.22"
37+
- "~> 3.1.20"
38+
- ">= 3.2.5"
39+
related:
40+
url:
41+
- https://github.com/rack/rack/security/advisories/GHSA-mxw3-3hh2-x2mh
42+
- https://github.com/rack/rack/commit/75c5745c286637a8f049a33790c71237762069e7
43+
- https://github.com/advisories/GHSA-mxw3-3hh2-x2mh

gems/rack/CVE-2026-25500.yml

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
---
2+
gem: rack
3+
cve: 2026-25500
4+
ghsa: whrj-4476-wvmp
5+
url: https://github.com/rack/rack/security/advisories/GHSA-whrj-4476-wvmp
6+
title: 'Stored XSS in Rack::Directory via javascript: filenames rendered into anchor
7+
href'
8+
date: 2026-02-17
9+
description: |-
10+
## Summary
11+
12+
`Rack::Directory` generates an HTML directory index where each file entry is rendered as a clickable link. If a file exists on disk whose basename begins with the `javascript:` scheme (e.g. `javascript:alert(1)`), the generated index includes an anchor whose `href` attribute is exactly `javascript:alert(1)`. Clicking this entry executes arbitrary JavaScript in the context of the hosting application.
13+
14+
This results in a client-side XSS condition in directory listings generated by `Rack::Directory`.
15+
16+
## Details
17+
18+
`Rack::Directory` renders directory entries using an HTML row template similar to:
19+
20+
```html
21+
<a href='%s'>%s</a>
22+
```
23+
24+
The `%s` placeholder is populated directly with the file’s basename. If the basename begins with `javascript:`, the resulting HTML contains an executable JavaScript URL:
25+
26+
```html
27+
<a href='javascript:alert(1)'>javascript:alert(1)</a>
28+
```
29+
30+
Because the value is inserted directly into the `href` attribute without scheme validation or normalization, browsers interpret it as a JavaScript URI. When a user clicks the link, the JavaScript executes in the origin of the Rack application.
31+
32+
## Impact
33+
34+
If `Rack::Directory` is used to expose filesystem contents over HTTP, an attacker who can create or upload files within that directory may introduce a malicious filename beginning with `javascript:`.
35+
36+
When a user visits the directory listing and clicks the entry, arbitrary JavaScript executes in the application's origin. Exploitation requires user interaction (clicking the malicious entry).
37+
38+
## Mitigation
39+
40+
* Update to a patched version of Rack in which `Rack::Directory` prefixes generated anchors with a relative path indicator (e.g. `./filename`).
41+
* Avoid exposing user-controlled directories via `Rack::Directory`.
42+
* Apply a strict Content Security Policy (CSP) to reduce impact of potential client-side execution issues.
43+
* Where feasible, restrict or sanitize uploaded filenames to disallow dangerous URI scheme prefixes.
44+
cvss_v3: 5.4
45+
patched_versions:
46+
- "~> 2.2.22"
47+
- "~> 3.1.20"
48+
- ">= 3.2.5"
49+
related:
50+
url:
51+
- https://github.com/rack/rack/security/advisories/GHSA-whrj-4476-wvmp
52+
- https://github.com/rack/rack/commit/f2f225f297b99fbee3d9f51255d41f601fc40aff
53+
- https://github.com/advisories/GHSA-whrj-4476-wvmp

gems/sisimai/CVE-2022-4891.yml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,7 @@ description: |
1212
has been disclosed to the public and may be used. Upgrading to version 4.25.14p12
1313
is able to address this issue. The name of the patch is 51fe2e6521c9c02b421b383943dc9e4bbbe65d4e.
1414
It is recommended to upgrade the affected component.
15+
cvss_v3: 4.3
1516
patched_versions:
1617
- ">= 4.25.14p12"
1718
related:

0 commit comments

Comments
 (0)