GHSA/SYNC: Add 8 new nokogiri advisories.

gems/nokogiri/GHSA-5prr-v3j2-97mh.yml

@@ -0,0 +1,46 @@
+---
+gem: nokogiri
+ghsa: 5prr-v3j2-97mh
+url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-5prr-v3j2-97mh
+title: 'Nokogiri: Possible Out-of-Bounds Read in `Nokogiri::XML::NodeSet#[]`'
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `Nokogiri::XML::NodeSet#[]` (and its alias `#slice`) checked the requested
+  index against the node set's bounds using a 32-bit-truncated copy of the
+  index. A large negative index could pass the check and then be used at full
+  width, reading outside the node set's storage. On CRuby this is an
+  out-of-bounds read that typically crashes the process; on JRuby it is not
+  memory-unsafe but returns an incorrect node.
+
+  Nokogiri 1.19.4 performs the bounds check against the full-width index.
+
+  ### Severity
+
+  The Nokogiri maintainers have evaluated this as medium severity.
+
+  Exploitation requires an application to pass an attacker-controlled integer to
+  `NodeSet#[]`. The primary impact is a controlled crash (denial of service),
+  with potential for memory disclosure on CRuby.
+
+  On JRuby, Nokogiri is not affected by this vulnerability.
+
+  ### Mitigation
+
+  Upgrade to Nokogiri 1.19.4 or later.
+
+  As a workaround, applications that index a `NodeSet` with externally-supplied
+  integers can validate the index against `node_set.length` before use, or avoid
+  passing untrusted values as an index.
+
+  ### Credit
+
+  This issue was responsibly reported by Zheng Yu from depthfirst.com.
+cvss_v4: 6.3
+patched_versions:
+  - ">= 1.19.4"
+related:
+  url:
+    - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-5prr-v3j2-97mh
+    - https://github.com/advisories/GHSA-5prr-v3j2-97mh

gems/nokogiri/GHSA-5v8h-3h3q-446p.yml

@@ -0,0 +1,46 @@
+---
+gem: nokogiri
+ghsa: 5v8h-3h3q-446p
+url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-5v8h-3h3q-446p
+title: 'Nokogiri: Possible Use-After-Free when `Nokogiri::XML::Document#encoding=`
+  raises an exception'
+date: 2026-06-19
+description: |
+  ### Summary
+
+  Calling `Document#encoding=` with an invalid encoding (e.g., a non-string, or
+  a string containing a null byte) raises an exception, but only after freeing
+  the document's current encoding string without replacing it. The document is
+  left referencing freed memory, so the next call to `Document#encoding` reads
+  invalid memory, which can cause a segfault or leak freed bytes into a Ruby
+  `String`.
+
+  Affects the CRuby (libxml2) implementation only; 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 pass an invalid encoding to `Document#encoding=`, rescue
+  the resulting exception, and then continue using the same document. Nokogiri
+  1.19.4 makes this pattern safe with no change to the public API. The document
+  no longer references freed memory after the exception is raised.
+
+  ### Mitigation
+
+  Upgrade to Nokogiri 1.19.4 or later.
+
+  If users are unable to upgrade, avoid passing attacker-controlled values to
+  `Document#encoding=`. Applications that only assign developer-authored
+  encodings are not directly exposed.
+
+  ### Credit
+
+  This issue was responsibly reported by Zheng Yu from depthfirst.com.
+cvss_v4: 1.7
+patched_versions:
+  - ">= 1.19.4"
+related:
+  url:
+    - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-5v8h-3h3q-446p
+    - https://github.com/advisories/GHSA-5v8h-3h3q-446p

gems/nokogiri/GHSA-8678-w3jw-xfc2.yml

@@ -0,0 +1,66 @@
+---
+gem: nokogiri
+ghsa: 8678-w3jw-xfc2
+url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-8678-w3jw-xfc2
+title: 'Nokogiri: XML::Schema on JRuby allows network requests when NONET is set,
+  bypassing CVE-2020-26247'
+date: 2026-06-19
+description: |
+  ### Summary
+
+  The `NONET` parse option, which Nokogiri turns on by default for
+  `Nokogiri::XML::Schema` (see
+  [CVE-2020-26247](https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-vr8q-g5c7-m54m)),
+  was not correctly enforced on the JRuby implementation. As a result, a schema
+  parsed with default options could still cause external resources to be fetched
+  over the network, potentially enabling SSRF or XXE attacks.
+
+  Nokogiri 1.19.4 replaces the scheme denylist with an allowlist. When `NONET`
+  is enabled, only local resources (a `file:` scheme, or a relative or absolute
+  path with no scheme) are resolved, and every network scheme is blocked,
+  case-insensitively. This brings the JRuby behavior in line with CRuby.
+
+  Only the JRuby implementation is affected. CRuby is not affected, because
+  libxml2's `xmlNoNetExternalEntityLoader` blocks all network schemes at the I/O
+  layer regardless of scheme or case.
+
+  ### Severity
+
+  The Nokogiri maintainers have evaluated this as low severity (CVSS 2.6,
+  `CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N`). It is a bypass of
+  CVE-2020-26247, which was scored the same way.
+
+  ### Mitigation
+
+  Upgrade to Nokogiri 1.19.4 or later.
+
+  There are no known workarounds for affected versions.
+
+  This change properly enforces `NONET` on JRuby, which is a breaking change for
+  any code that (perhaps unknowingly) relied on the previous behavior to load
+  network resources with default parse options. If you trust your input and want
+  to allow external resources to be accessed over the network, you can
+  explicitly disable `NONET`, exactly as documented for CVE-2020-26247:
+
+  1. Ensure the input is trusted. Do not enable this option for untrusted input.
+  2. Pass a `Nokogiri::XML::ParseOptions` with the `NONET` flag turned off:
+
+  ``` ruby
+  # allows resources to be accessed over the network for trusted input
+  schema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)
+  ```
+
+  ### References
+
+  - Bypass of: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-vr8q-g5c7-m54m
+
+  ### Credit
+
+  This issue was responsibly reported by @bilerden.
+cvss_v3: 2.6
+patched_versions:
+  - ">= 1.19.4"
+related:
+  url:
+    - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-8678-w3jw-xfc2
+    - https://github.com/advisories/GHSA-8678-w3jw-xfc2

gems/nokogiri/GHSA-9cv2-cfxc-v4v2.yml

@@ -0,0 +1,45 @@
+---
+gem: nokogiri
+ghsa: 9cv2-cfxc-v4v2
+url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-9cv2-cfxc-v4v2
+title: 'Nokogiri: Null Pointer Dereference calling methods on uninitialized wrapper
+  classes'
+date: 2026-06-19
+description: |
+  ### Summary
+
+  Nokogiri contains a bug when calling certain methods on
+  allocated-but-uninitialized native wrapper classes that inherit from
+  `Nokogiri::XML::Node`. This caused a NULL pointer dereference that could crash
+  the process.
+
+  Nokogiri 1.19.4 checks for missing native data pointers and raises a
+  `RuntimeError`.
+
+  JRuby is not affected.
+
+  ### Severity
+
+  The Nokogiri maintainers have evaluated this as low severity. This is only
+  triggered by a programming error. It requires application code to call
+  `.allocate` directly on a native-backed class and then invoke methods on the
+  resulting uninitialized object. It cannot be triggered by untrusted input or
+  through normal use of the public API.
+
+  ### Mitigation
+
+  Upgrade to Nokogiri 1.19.4 or later.
+
+  Avoid calling `.allocate` directly on Nokogiri native-backed classes. Use the
+  documented constructors and factory methods instead.
+
+  ### Credit
+
+  This issue was responsibly reported by Zheng Yu from depthfirst.com.
+cvss_v4: 1.7
+patched_versions:
+  - ">= 1.19.4"
+related:
+  url:
+    - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-9cv2-cfxc-v4v2
+    - https://github.com/advisories/GHSA-9cv2-cfxc-v4v2

gems/nokogiri/GHSA-p67v-3w7g-wjg7.yml

@@ -0,0 +1,52 @@
+---
+gem: nokogiri
+ghsa: p67v-3w7g-wjg7
+url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-p67v-3w7g-wjg7
+title: 'Nokogiri: Possible Use-After-Free when directly using `NokogirI::XML::XPathContext`
+  beyond document lifetime'
+date: 2026-06-19
+description: |
+  ### Summary
+
+  `Nokogiri::XML::XPathContext` did not keep its source document alive for
+  garbage collection. If an `XPathContext` outlived its document and the
+  document was collected, evaluating an XPath expression could read invalid
+  memory and potentially segfault.
+
+  This is only reachable when application code constructs an `XPathContext`
+  directly and lets the document become unreachable while continuing to use the
+  context. The normal `Document#xpath`, `#css`, and related search methods are
+  not affected, and it is not triggerable by malicious document input.
+
+  Nokogiri 1.19.4 makes `XPathContext` keep its source document alive for as
+  long as the context exists.
+
+  Only the CRuby implementation is affected. 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 construct an `XML::XPathContext` directly and continue
+  using it after allowing its source document to be garbage-collected. Nokogiri
+  1.19.4 makes this pattern safe with no change to the public API. The context
+  now keeps its source document alive for as long as it exists.
+
+  ### Mitigation
+
+  Upgrade to Nokogiri 1.19.4 or later.
+
+  As a workaround, ensure the source document remains referenced for as long as
+  any `XPathContext` created from it is in use. The standard `Document#xpath`,
+  `#css`, and related search methods already do this and are unaffected.
+
+  ### Credit
+
+  This issue was responsibly reported by Zheng Yu from depthfirst.com.
+cvss_v4: 1.7
+patched_versions:
+  - ">= 1.19.4"
+related:
+  url:
+    - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-p67v-3w7g-wjg7
+    - https://github.com/advisories/GHSA-p67v-3w7g-wjg7

gems/nokogiri/GHSA-phwj-rprq-35pp.yml

@@ -0,0 +1,50 @@
+---
+gem: nokogiri
+ghsa: phwj-rprq-35pp
+url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-phwj-rprq-35pp
+title: 'Nokogiri: Possible Use-After-Free when setting an attribute value via `Nokogiri::XML::Attr#value=`
+  or `#content=`'
+date: 2026-06-19
+description: |
+  ### Summary
+
+  Nokogiri's CRuby native extension could leave a Ruby wrapper pointing to freed
+  memory when replacing the value of an XML attribute. If Ruby code had already
+  accessed an attribute child node, `Nokogiri::XML::Attr#value=` could free the
+  underlying native child node while the wrapper remained reachable through the
+  document node cache. A later use of the freed child node or a Ruby GC mark
+  could dereference an invalid pointer, causing an invalid read and a possible
+  segfault.
+
+  Nokogiri 1.19.4 preserves any 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 node and then
+  replace that same attribute's value via `Attr#value=` or `#content=`. Nokogiri
+  1.19.4 makes this pattern safe with no change to the public API.
+  Already-wrapped attribute child nodes are preserved before the value is
+  replaced.
+
+  ### Mitigation
+
+  Upgrade to Nokogiri 1.19.4 or later.
+
+  As a workaround, avoid accessing attribute child nodes directly via
+  `Attr#child` or similar before mutating the same attribute’s value.
+
+  ### Credit
+
+  This issue was responsibly reported by Zheng Yu from depthfirst.com.
+cvss_v4: 1.7
+patched_versions:
+  - ">= 1.19.4"
+related:
+  url:
+    - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-phwj-rprq-35pp
+    - https://github.com/advisories/GHSA-phwj-rprq-35pp

gems/nokogiri/GHSA-wfpw-mmfh-qq69.yml

@@ -0,0 +1,52 @@
+---
+gem: nokogiri
+ghsa: wfpw-mmfh-qq69
+url: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-wfpw-mmfh-qq69
+title: 'Nokogiri: Possible Use-After-Free in XInclude Processing'
+date: 2026-06-19
+description: |
+  ### Summary
+
+  XInclude substitution performed by `Nokogiri::XML::Node#do_xinclude` replaced
+  each `<xi:include>` in place, freeing the include node along with its children
+  (such as `<xi:fallback>` and its descendants) and any namespaces declared on
+  them. If an application had already exposed one of those nodes or namespaces
+  to Ruby, the corresponding Ruby object was left pointing at freed memory.
+  Using the object could result in invalid reads or writes to memory.
+
+  Nokogiri 1.19.4 substitutes each `<xi:include>` on a defensive copy by
+  default, so the structures libxml2 frees are never the ones bound to live Ruby
+  objects.
+
+  Only the CRuby implementation is affected; 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 parse a document without XInclude, traverse into an
+  `<xi:include>` subtree to expose its nodes or namespaces to Ruby, and only
+  then invoke XInclude processing. The common case, requesting XInclude at parse
+  time, operates on a freshly parsed document whose nodes are not yet exposed to
+  Ruby and is not affected. Nokogiri 1.19.4 makes this pattern safe by default
+  and requires no change to application code.
+
+  ### Mitigation
+
+  Upgrade to Nokogiri 1.19.4 or later.
+
+  As a workaround for earlier versions, perform XInclude substitution at parse
+  time (with the `xinclude` parse option) rather than calling `#do_xinclude` on
+  a document that has already been traversed. A freshly parsed document has no
+  nodes exposed to Ruby, so the substitution is safe.
+
+  ### Credit
+
+  This issue was responsibly reported by Zheng Yu from depthfirst.com.
+patched_versions:
+  - ">= 1.19.4"
+related:
+  url:
+    - https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-wfpw-mmfh-qq69
+    - https://github.com/advisories/GHSA-wfpw-mmfh-qq69
+notes: "No CVSS score was provided in the GHSA."