diff --git a/gems/loofah/GHSA-345x-3rq2-jfrm.yml b/gems/loofah/GHSA-345x-3rq2-jfrm.yml new file mode 100644 index 0000000000..cd808e938f --- /dev/null +++ b/gems/loofah/GHSA-345x-3rq2-jfrm.yml @@ -0,0 +1,50 @@ +--- +gem: loofah +ghsa: 345x-3rq2-jfrm +url: https://github.com/flavorjones/loofah/security/advisories/GHSA-345x-3rq2-jfrm +title: "SVG `` and `` bypass local-reference restriction in + Loofah" +date: 2026-11-02 +description: | + ## Summary + + Loofah restricts `href` and `xlink:href` on certain SVG elements to + same-document references. Two elements escaped the restriction: + + - ``: `SVG_ALLOW_LOCAL_HREF` listed it in lowercase as `textpath`, + but the HTML5 parser names the element `textPath` inside ``, so the + check never matched on the HTML5 path. + - ``: absent from `SVG_ALLOW_LOCAL_HREF`, so its references were never + restricted on either path. + + `rails-html-sanitizer` reuses this safelist in its `PermitScrubber`, so it is + affected too. + + ## Impact + + An external `href` or `xlink:href` on `` or `` survives + sanitization. Firefox fetches the URL when rendering the content, which leaks + the viewer's IP address, user agent, and referrer, and can reach hosts + routable only from the viewer's network. Chrome and WebKit do not fetch + external references on these elements. The impact is a network request to an + attacker-chosen URL, not script execution. + + Applications that sanitize user-supplied SVG, directly or inside HTML, with + Loofah's default allowlist or with `rails-html-sanitizer` with SVG elements + permitted are affected. + + ## Mitigation + + Upgrade to Loofah >= 2.25.3. +cvss_v3: 4.7 +patched_versions: + - ">= 2.25.3" +related: + url: + - https://rubygems.org/gems/loofah/versions/2.25.3 + - https://github.com/flavorjones/loofah/releases/tag/v2.25.3 + - https://github.com/flavorjones/loofah/blob/main/CHANGELOG.md#2253--2026-11-01 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-345x-3rq2-jfrm +notes: | + - No CVE. + - cvss_v3 from GHSA diff --git a/gems/loofah/GHSA-h6v6-rg66-fqj4.yml b/gems/loofah/GHSA-h6v6-rg66-fqj4.yml new file mode 100644 index 0000000000..68c7086585 --- /dev/null +++ b/gems/loofah/GHSA-h6v6-rg66-fqj4.yml @@ -0,0 +1,49 @@ +--- +gem: loofah +ghsa: h6v6-rg66-fqj4 +url: https://github.com/flavorjones/loofah/security/advisories/GHSA-h6v6-rg66-fqj4 +title: "Mutation XSS in Loofah HTML5 scrubbers through unescaped attribute + values" +date: 2026-11-02 +description: | + ## Summary + + Loofah's HTML5 scrubbers could emit output that a browser parses into + different markup, allowing mutation XSS. Nokogiri < 1.19.5 did not escape `<` + and `>` in attribute values. When the output contained certain MathML, a + browser treated markup inside an allowed attribute as live HTML. The `:strip` + scrubber is affected in every browser. The `:prune` and `:escape` scrubbers + are affected in WebKit browsers such as Safari. + + Nokogiri 1.19.5 escapes `<` and `>` in attribute values, as the HTML standard + requires. Loofah 2.25.3 requires Nokogiri >= 1.19.5. + + ## Impact + + Applications that sanitize untrusted HTML with Loofah's HTML5 API + (`Loofah.html5_fragment`, `Loofah.html5_document` and the `scrub_html5_*` + methods) and display the result to other people are affected, including with + the default allowlist. + + Not affected: Loofah's HTML4 API (including `Loofah::Helpers.sanitize`), the + `:whitewash` scrubber, rails-html-sanitizer's default configuration, and + JRuby. + + ## Mitigation + + Upgrade to Loofah >= 2.25.3, or upgrade Nokogiri to >= 1.19.5. +cvss_v3: 6.1 +unaffected_versions: + - "< 2.21.0" +patched_versions: + - ">= 2.25.3" +related: + url: + - https://rubygems.org/gems/loofah/versions/2.25.3 + - https://github.com/flavorjones/loofah/releases/tag/v2.25.3 + - https://github.com/flavorjones/loofah/blob/main/CHANGELOG.md#2253--2026-11-01 + - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-4p39-36wj-23h4 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-h6v6-rg66-fqj4 +notes: | + - No CVE. + - cvss_v3 from GHSA diff --git a/gems/loofah/GHSA-jcff-cj73-4w4f.yml b/gems/loofah/GHSA-jcff-cj73-4w4f.yml new file mode 100644 index 0000000000..bbaf32d3d7 --- /dev/null +++ b/gems/loofah/GHSA-jcff-cj73-4w4f.yml @@ -0,0 +1,61 @@ +--- +gem: loofah +ghsa: jcff-cj73-4w4f +url: https://github.com/flavorjones/loofah/security/advisories/GHSA-jcff-cj73-4w4f +title: "Loofah allowed_uri? treats data:text/html as safe text/plain" +date: 2026-11-02 +description: | + ## Summary + + `Loofah::HTML5::Scrub.allowed_uri?` returns `true` for a `data:` URI whose + mediatype is written with the HTML5 named character reference `/` in place + of the solidus. Loofah reads that mediatype as malformed and falls back to the + allowed `text/plain`, while a browser decodes the reference and reads the same + URI as `text/html`. + + ## Details + + `allowed_uri?` decodes HTML entities with `CGI.unescapeHTML`, which handles + numeric character references but not HTML5 named character references. `/` + therefore survives normalization, so the mediatype carries no `/`, fails the + MIME grammar, and falls back to the allowed `text/plain` under the WHATWG rule + for a malformed mediatype. + + `:`, `/`, ` ` and ` ` are the only named character + references in the HTML5 table that decode to characters that change how a URI + parses (U+003A, U+002F, U+0009 and U+000A; there is no named reference for + U+000D), so this closes the set. + + Loofah's default `sanitize()` path is **not** affected, because Nokogiri + decodes the entity during parsing before Loofah evaluates the URI. This issue + affects only callers of the public `allowed_uri?` string-level helper that + pass it HTML-encoded strings. + + ## Impact + + Applications that validate a user-controlled URL with + `Loofah::HTML5::Scrub.allowed_uri?` and then render the approved value into an + `href` or another browser-interpreted URI attribute may be vulnerable to + cross-site scripting. `Rails::HTML::Sanitizer.allowed_uri?` re-exports the + same helper. + + ## Mitigation + + Upgrade to Loofah >= 2.25.3. + + ## Credit + + Responsibly reported by GitHub user @ngpestelos. +unaffected_versions: + - "< 2.25.2" +patched_versions: + - ">= 2.25.3" +related: + url: + - https://rubygems.org/gems/loofah/versions/2.25.3 + - https://github.com/flavorjones/loofah/releases/tag/v2.25.3 + - https://github.com/flavorjones/loofah/blob/main/CHANGELOG.md#2253--2026-11-01 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-jcff-cj73-4w4f +notes: | + - No CVE. + - No CVSS score on GHSA diff --git a/gems/loofah/GHSA-m3x9-938q-5767.yml b/gems/loofah/GHSA-m3x9-938q-5767.yml new file mode 100644 index 0000000000..a5f307e6a1 --- /dev/null +++ b/gems/loofah/GHSA-m3x9-938q-5767.yml @@ -0,0 +1,49 @@ +--- +gem: loofah +ghsa: m3x9-938q-5767 +url: https://github.com/flavorjones/loofah/security/advisories/GHSA-m3x9-938q-5767 +title: "CSS url() sanitization bypass via escaped parentheses in Loofah" +date: 2026-11-02 +description: | + ## Summary + + `Loofah::HTML5::Scrub.scrub_css` rejected any property whose top-level Crass + tokens included a `:url` or `:bad_url`, and left `url` out of the allowed CSS + functions. Both checks ran only against the first parse of the `style` + attribute. When `scrub_css` rebuilt each property it emitted identifiers with + their CSS escapes decoded, so parentheses written as escapes — `url\28 …\29` — + hid the `url` token from the checks, and the rebuilt value was re-parsed into + a live `url()` that nothing checked again. An escaped property name, six-digit + escapes, escaped comments and escaped quotes all reached the same place. + + ## Impact + + A sanitized `style` attribute could make a viewer's browser issue a request to + an attacker-chosen URL. `list-style` fetches on render with no interaction, + `cursor` on hover. That leaks the viewer's IP address, user agent and access + timing, and can reach hosts routable only from the viewer's network. No script + survives sanitization and the attacker cannot read the response, so the + request itself is the whole impact. + + Applications that sanitize user-supplied HTML with Loofah's default allowlist + and display it to other people are affected. + + ## Mitigation + + Upgrade to Loofah >= 2.25.3. + + ## Credit + + Reported by NotAFlightRisk through GitHub's private vulnerability reporting. +cvss_v3: 4.7 +patched_versions: + - ">= 2.25.3" +related: + url: + - https://rubygems.org/gems/loofah/versions/2.25.3 + - https://github.com/flavorjones/loofah/releases/tag/v2.25.3 + - https://github.com/flavorjones/loofah/blob/main/CHANGELOG.md#2253--2026-11-01 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-m3x9-938q-5767 +notes: | + - No CVE. + - cvss_v3 from GHSA diff --git a/gems/loofah/GHSA-mf2j-8f84-cc9q.yml b/gems/loofah/GHSA-mf2j-8f84-cc9q.yml new file mode 100644 index 0000000000..65da3aa011 --- /dev/null +++ b/gems/loofah/GHSA-mf2j-8f84-cc9q.yml @@ -0,0 +1,57 @@ +--- +gem: loofah +ghsa: mf2j-8f84-cc9q +url: https://github.com/flavorjones/loofah/security/advisories/GHSA-mf2j-8f84-cc9q +title: "Regular expression denial of service in Loofah's SVG local-reference + check" +date: 2026-11-02 +description: | + ## Summary + + Loofah's HTML5 sanitizer restricts the `href` and `xlink:href` attributes of + SVG reference elements to local references. That check matched the attribute + value against `/^\s*[^#\s].*/m`. In Ruby `^` anchors to every line start and + `\s` matches newlines, so an all-whitespace value made the engine rescan the + value from each of its line starts, taking time quadratic in its length. + + CRuby 3.1 and earlier, and JRuby, are affected. CRuby 3.2 added linear-time + regexp matching, which makes the pattern linear. JRuby's regexp engine does + not. + + ## Impact + + An attacker who supplies HTML to be sanitized can consume CPU out of + proportion to the input size, by sending an SVG reference element whose `href` + or `xlink:href` is a long run of whitespace. + + The default safelist allows the elements in `SVG_ALLOW_LOCAL_HREF`, so no + configuration change is required. + + ## Mitigation + + Upgrade to Loofah >= 2.25.3. Applications on CRuby that cannot upgrade should + run CRuby 3.2 or later, which matches the pattern in linear time. + + ## References + + - [CWE-1333: Inefficient Regular Expression + Complexity](https://cwe.mitre.org/data/definitions/1333.html) + - [Ruby 3.2.0 release + notes](https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/) + + ## Credit + + Reported by scyoon through the Rails HackerOne program. +cvss_v3: 5.3 +patched_versions: + - ">= 2.25.3" +related: + url: + - https://rubygems.org/gems/loofah/versions/2.25.3 + - https://github.com/flavorjones/loofah/releases/tag/v2.25.3 + - https://github.com/flavorjones/loofah/blob/main/CHANGELOG.md#2253--2026-11-01 + - https://github.com/rails/rails-html-sanitizer/security/advisories/GHSA-cpgf-5mjf-73p7 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-mf2j-8f84-cc9q +notes: | + - No CVE. + - cvss_v3 from GHSA diff --git a/gems/loofah/GHSA-p9wj-w8xq-vjx6.yml b/gems/loofah/GHSA-p9wj-w8xq-vjx6.yml new file mode 100644 index 0000000000..d3945737ea --- /dev/null +++ b/gems/loofah/GHSA-p9wj-w8xq-vjx6.yml @@ -0,0 +1,57 @@ +--- +gem: loofah +ghsa: p9wj-w8xq-vjx6 +url: https://github.com/flavorjones/loofah/security/advisories/GHSA-p9wj-w8xq-vjx6 +title: "Loofah allowed_uri? treats javascript: alert(1) as safe" +date: 2026-11-02 +description: | + ## Summary + + `Loofah::HTML5::Scrub.allowed_uri?` returns `true` for a `javascript:` or + `vbscript:` URI whose scheme is split by a numeric character reference without + a trailing semicolon, followed by a character that `allowed_uri?` strips, such + as a space or tab. A browser ends the reference at that character and reads + `javascript: alert(1)` as `javascript: alert(1)`. + + ## Details + + `allowed_uri?` strips control characters and whitespace before it decodes + numeric character references. Removing the character that ends a + semicolon-less reference lets the reference run on into the following text, so + `: alert` decodes as `Ϊ` (U+03AA) instead of a colon, and no scheme + is detected. The same applies to decimal references and to references that + encode a scheme letter, as in `j\tavascript:alert(1)`. + + Loofah's default `sanitize()` path is **not** affected, because Nokogiri + decodes the entity during parsing before Loofah evaluates the URI. This issue + affects only callers of the public `allowed_uri?` string-level helper that + pass it HTML-encoded strings. + + ## Impact + + Applications that validate a user-controlled URL with + `Loofah::HTML5::Scrub.allowed_uri?` and then render the approved value into an + `href` or another browser-interpreted URI attribute may be vulnerable to + cross-site scripting. `Rails::HTML::Sanitizer.allowed_uri?` re-exports the + same helper. + + ## Mitigation + + Upgrade to Loofah >= 2.25.3. + + ## Credit + + Responsibly reported by GitHub user @manus-pi. +unaffected_versions: + - "< 2.25.0" +patched_versions: + - ">= 2.25.3" +related: + url: + - https://rubygems.org/gems/loofah/versions/2.25.3 + - https://github.com/flavorjones/loofah/releases/tag/v2.25.3 + - https://github.com/flavorjones/loofah/blob/main/CHANGELOG.md#2253--2026-11-01 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-p9wj-w8xq-vjx6 +notes: | + - No CVE. + - No CVSS score on GHSA diff --git a/gems/nokogiri/GHSA-3w22-6jfg-527w.yml b/gems/nokogiri/GHSA-3w22-6jfg-527w.yml new file mode 100644 index 0000000000..ac6b42b475 --- /dev/null +++ b/gems/nokogiri/GHSA-3w22-6jfg-527w.yml @@ -0,0 +1,55 @@ +--- +gem: nokogiri +ghsa: 3w22-6jfg-527w +url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-3w22-6jfg-527w +title: "Use-After-Free in Nokogiri when replacing an attribute value" +date: 2026-11-02 +description: | + ### Summary + + Nokogiri's CRuby native extension could leave a Ruby wrapper pointing to freed + memory when replacing the value of an existing XML attribute via + `Nokogiri::XML::Node#[]=` or `Nokogiri::XML::Node#lang=`. If Ruby code had + already accessed the attribute's child nodes, replacing the value could free + those native child nodes while their wrappers remained reachable. Using one of + those child nodes afterwards could cause an invalid read and a possible + segfault. + + This is the same class of issue as + [GHSA-phwj-rprq-35pp](https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-phwj-rprq-35pp), + which was fixed for `Attr#value=` in Nokogiri 1.19.4. + + Nokogiri 1.19.5 preserves all already-wrapped attribute child nodes before + replacing the attribute value. + + JRuby is not affected. + + ### Severity + + The Nokogiri maintainers have evaluated this as low severity. Reaching it + requires an unusual API-usage pattern that does not arise during normal use. + The application must directly access an attribute's child nodes and then + replace that same attribute's value via `Node#[]=` or `Node#lang=`. Nokogiri + 1.19.5 makes this pattern safe with no change to the public API. + + ### Mitigation + + Upgrade to Nokogiri 1.19.5 or later. + + As a workaround, avoid accessing attribute child nodes directly via + `Attr#children` or similar before replacing the same attribute's value. + + ### Credit + + This issue was responsibly reported by zx (@manus-pi). +patched_versions: + - ">= 1.19.5" +related: + url: + - https://rubygems.org/gems/nokogiri/versions/1.19.5 + - https://github.com/sparklemotion/nokogiri/releases/tag/v1.19.5 + - https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md#v1195--2026-11-01 + - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-3w22-6jfg-527w +notes: | + - No CVE. + - No CVSS score on GHSA diff --git a/gems/nokogiri/GHSA-4p39-36wj-23h4.yml b/gems/nokogiri/GHSA-4p39-36wj-23h4.yml new file mode 100644 index 0000000000..9574f9fd04 --- /dev/null +++ b/gems/nokogiri/GHSA-4p39-36wj-23h4.yml @@ -0,0 +1,60 @@ +--- +gem: nokogiri +ghsa: 4p39-36wj-23h4 +url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-4p39-36wj-23h4 +title: "Possible Mutation XSS when serializing `noscript` content in + `Nokogiri::HTML5` documents" +date: 2026-11-02 +description: | + ### Summary + + Nokogiri's HTML5 serializer did not escape text inside `noscript` elements, or + `<` and `>` inside attribute values. When a document parsed with the default + options is serialized, a browser with scripting enabled can parse the output + into markup that Nokogiri's parser never produced. This is a mutation XSS for + applications that sanitize untrusted HTML with `Nokogiri::HTML5`, allow + `noscript` elements, and send the serialized output to browsers. + + Nokogiri 1.19.5 escapes both, as the HTML standard's serialization algorithm + requires. Text inside `noscript` is still emitted unescaped for documents + parsed with `parse_noscript_content_as_text: true`. + + Only the C extension (CRuby and TruffleRuby) is affected. JRuby does not + implement `Nokogiri::HTML5`. + + ### Severity + + The Nokogiri maintainers have evaluated this as low severity (CVSS 2.3, + `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N`). + Exploitation requires an application that allows `noscript` in sanitized HTML. + Loofah and rails-html-sanitizer do not allow it by default, and Sanitize + always removes it. + + ### Mitigation + + Upgrade to Nokogiri 1.19.5 or later. + + Applications that sanitize HTML and allow `noscript` should parse with + `parse_noscript_content_as_text: true` (available since Nokogiri 1.17.0), or + remove `noscript` elements. This is the workaround for earlier versions, and + it is recommended on every version: some content inside `noscript` is + serialized unchanged, as the standard requires. + + ### Credit + + This issue was responsibly reported by @a-zara-n. +cvss_v4: 2.3 +unaffected_versions: + - "< 1.12.0" +patched_versions: + - ">= 1.19.5" +related: + url: + - https://rubygems.org/gems/nokogiri/versions/1.19.5 + - https://github.com/sparklemotion/nokogiri/releases/tag/v1.19.5 + - https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md#v1195--2026-11-01 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-h6v6-rg66-fqj4 + - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-4p39-36wj-23h4 +notes: | + - No CVE. + - cvss_v4 from GHSA diff --git a/gems/nokogiri/GHSA-v995-44v6-5fqm.yml b/gems/nokogiri/GHSA-v995-44v6-5fqm.yml new file mode 100644 index 0000000000..de184cf9c5 --- /dev/null +++ b/gems/nokogiri/GHSA-v995-44v6-5fqm.yml @@ -0,0 +1,48 @@ +--- +gem: nokogiri +platform: jruby +ghsa: v995-44v6-5fqm +url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-v995-44v6-5fqm +title: "Possible SSRF on JRuby when resolving external DTDs or entities with + `NONET` set" +date: 2026-11-02 +description: | + ### Summary + + On JRuby, the `NONET` parse option did not block an external DTD or entity + whose system identifier used a short-form IPv4 host, such as `http://127.1/` + or `http://169.254.43518/`, or was an absolute path such as `/x.dtd` in a + document parsed from a network URL. An application that parses untrusted XML + with `DTDLOAD`, `DTDVALID` or `NOENT` could be made to send network requests, + potentially enabling SSRF. + + Nokogiri 1.19.5 applies the `XML::Schema` check from + [GHSA-8678-w3jw-xfc2](https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-8678-w3jw-xfc2): + with `NONET` set, only local resources are loaded. + + Only JRuby is affected. Default parse options are not affected. + + ### Severity + + The Nokogiri maintainers have evaluated this as low severity (CVSS 3.7). + + ### Mitigation + + Upgrade to Nokogiri 1.19.5 or later, or do not enable `DTDLOAD`, `DTDVALID` or + `NOENT` for untrusted input. + + ### Credit + + This issue was responsibly reported by @arpitjain099. +cvss_v3: 3.7 +patched_versions: + - ">= 1.19.5" +related: + url: + - https://rubygems.org/gems/nokogiri/versions/1.19.5 + - https://github.com/sparklemotion/nokogiri/releases/tag/v1.19.5 + - https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md#v1195--2026-11-01 + - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-v995-44v6-5fqm +notes: | + - No CVE. + - cvss_v3 from GHSA diff --git a/gems/rails-html-sanitizer/GHSA-cpgf-5mjf-73p7.yml b/gems/rails-html-sanitizer/GHSA-cpgf-5mjf-73p7.yml new file mode 100644 index 0000000000..d6cbfaeaa9 --- /dev/null +++ b/gems/rails-html-sanitizer/GHSA-cpgf-5mjf-73p7.yml @@ -0,0 +1,72 @@ +--- +gem: rails-html-sanitizer +framework: rails +ghsa: cpgf-5mjf-73p7 +url: https://github.com/rails/rails-html-sanitizer/security/advisories/GHSA-cpgf-5mjf-73p7 +title: "Possible regular expression denial of service with certain + configurations of rails-html-sanitizer" +date: 2026-11-02 +description: | + ## Summary + + `Rails::HTML::PermitScrubber` restricts the `href` and `xlink:href` attributes + of SVG reference elements to local references. That check matched the + attribute value against `/^\s*[^#\s].*/m`. In Ruby `^` anchors to every line + start and `\s` matches newlines, so an all-whitespace value made the engine + rescan the value from each of its line starts, taking time quadratic in its + length. + + - Versions affected: `>= 1.0.3, < 1.7.2` + - Not affected: `< 1.0.3` + - Fixed versions: `1.7.2` + + CRuby 3.1 and earlier, and JRuby, are affected. CRuby 3.2 added linear-time + regexp matching, which makes the pattern linear. JRuby's regexp engine does + not. + + ## Impact + + An attacker who supplies HTML to be sanitized can consume CPU out of + proportion to the input size, by sending an SVG reference element whose `href` + or `xlink:href` is a long run of whitespace. + + Applications are affected only when the allowed tags are overridden to include + an SVG reference element such as `use`, along with `href` or `xlink:href` in + the allowed attributes. The default allowed tags include no SVG elements, so + the default configuration is not affected. Applications that use Loofah + directly are exposed through its own copy of the check, fixed in Loofah + 2.25.3. + + ## Workarounds + + On CRuby, run 3.2 or later, which matches the pattern in linear time. + Alternatively, remove the SVG reference elements from the overridden allowed + tags. + + ## References + + - [GHSA-mf2j-8f84-cc9q: the same flaw in + Loofah](https://github.com/flavorjones/loofah/security/advisories/GHSA-mf2j-8f84-cc9q) + - [CWE-1333: Inefficient Regular Expression + Complexity](https://cwe.mitre.org/data/definitions/1333.html) + - [Ruby 3.2.0 release + notes](https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/) + + ## Credit + + Reported by scyoon through the Rails HackerOne program. +cvss_v3: 5.3 +unaffected_versions: + - "< 1.0.3" +patched_versions: + - ">= 1.7.2" +related: + url: + - https://rubygems.org/gems/rails-html-sanitizer/versions/1.7.2 + - https://github.com/rails/rails-html-sanitizer/releases/tag/v1.7.2 + - https://github.com/rails/rails-html-sanitizer/blob/main/CHANGELOG.md#v172--2026-11-02 + - https://github.com/flavorjones/loofah/security/advisories/GHSA-mf2j-8f84-cc9q + - https://github.com/rails/rails-html-sanitizer/security/advisories/GHSA-cpgf-5mjf-73p7 +notes: | + - No CVE. + - cvss_v3 from GHSA diff --git a/gems/rails-html-sanitizer/GHSA-h7wh-q2qr-458c.yml b/gems/rails-html-sanitizer/GHSA-h7wh-q2qr-458c.yml new file mode 100644 index 0000000000..77a40a230b --- /dev/null +++ b/gems/rails-html-sanitizer/GHSA-h7wh-q2qr-458c.yml @@ -0,0 +1,70 @@ +--- +gem: rails-html-sanitizer +framework: rails +ghsa: h7wh-q2qr-458c +url: https://github.com/rails/rails-html-sanitizer/security/advisories/GHSA-h7wh-q2qr-458c +title: "Possible XSS via shared scrubber state in concurrent + rails-html-sanitizer calls" +date: 2026-11-02 +description: | + ## Summary + + `Rails::HTML::SafeListSanitizer` (both the HTML4 and HTML5 variants) shares + one `Rails::HTML::PermitScrubber` across every `sanitize` call on the same + instance, assigning its `tags` and `attributes` on each call without + synchronization. Two concurrent `sanitize` calls with different `tags:` or + `attributes:` options can interleave, so one call is scrubbed with the other + call's allowlist. + + - Versions affected: `< 1.7.2` + - Not affected: none + - Fixed versions: `1.7.2` + + ## Impact + + Action View memoizes a single `SafeListSanitizer` per helper module and uses + it for every `sanitize` call in the process, so in a multi-threaded server + (for example Puma) all requests share the same `PermitScrubber`. If any code + path calls `sanitize` with a more permissive allowlist, an attacker who can + trigger that path concurrently with another request can cause the other + request to be sanitized with the permissive allowlist. If the permissive + allowlist admits `script` or an event-handler attribute, the strict call emits + it unchanged, which is a cross-site scripting vector when the strict output is + stored or rendered to other users. + + Applications are affected only if they run more than one thread per process + and some `sanitize` call passes `tags:` or `attributes:` options that differ + from another call's, including a call that passes no options and so uses the + defaults. Applications that use a single configuration everywhere, pass their + own `scrubber:`, or run single-threaded are not affected. + + ## Workarounds + + Use the same allowlist for every `sanitize` call, or pass a `scrubber:` built + per call (`Rails::HTML::PermitScrubber.new` with `tags=` and `attributes=` + set) instead of `tags:` and `attributes:` options. + + ## References + + - [CWE-362: Concurrent Execution using Shared Resource with Improper + Synchronization ('Race + Condition')](https://cwe.mitre.org/data/definitions/362.html) + - [CWE-79: Improper Neutralization of Input During Web Page Generation + ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) + - [rails/rails-html-sanitizer#228](https://github.com/rails/rails-html-sanitizer/issues/228) + + ## Credit + + Reported by hiumee via HackerOne. +cvss_v3: 4.7 +patched_versions: + - ">= 1.7.2" +related: + url: + - https://rubygems.org/gems/rails-html-sanitizer/versions/1.7.2 + - https://github.com/rails/rails-html-sanitizer/releases/tag/v1.7.2 + - https://github.com/rails/rails-html-sanitizer/blob/main/CHANGELOG.md#v172--2026-11-02 + - https://github.com/rails/rails-html-sanitizer/security/advisories/GHSA-h7wh-q2qr-458c +notes: | + - No CVE. + - cvss_v3 from GHSA