Add nokogiri, loofah and rails-html-sanitizer advisories

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 `<textPath>` and `<mpath>` 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:
+
+  - `<textPath>`: `SVG_ALLOW_LOCAL_HREF` listed it in lowercase as `textpath`,
+    but the HTML5 parser names the element `textPath` inside `<svg>`, so the
+    check never matched on the HTML5 path.
+  - `<mpath>`: 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 `<textPath>` or `<mpath>` 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

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

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

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

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

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&#x3a 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&#x3a 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
+  `&#x3a alert` decodes as `&#x3aa` (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 `&#x6a\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

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