🚨 [security] [ruby] Update nokogiri 1.18.9 → 1.19.4 (minor)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ nokogiri (1.18.9 → 1.19.4) · Repo · Changelog

Security Advisories 🚨

🚨 Nokogiri: Possible Use-After-Free when setting an attribute value via `Nokogiri::XML::Attr#value=` or `#content=`

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.

🚨 Nokogiri: Possible Use-After-Free when setting `Document#root=` to an invalid node type

Summary

Nokogiri::XML::Document#root= validated only that the new root was a Nokogiri::XML::Node, allowing a DTD node to be set as the document root. The result is a heap use-after-free during garbage collection or finalization, leading to an invalid memory read or potentially a segfault.

Nokogiri 1.19.4 restricts Document#root= to element nodes, raising TypeError for any other node type.

This memory-safety issue affects only the CRuby implementation (libxml2). The JRuby implementation was not affected; the same input validation was added there for behavioral parity.

Severity

The Nokogiri maintainers have evaluated this as low severity. This is only triggered by a programming error. It requires application code to assign a non-element node such as a DTD as the document root via Document#root=. Nokogiri 1.19.4 now raises TypeError instead of allowing a use-after-free. It cannot be triggered by untrusted input or through normal use of the public API.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

As a workaround, applications that cannot upgrade should avoid assigning a DTD (or any non-element node) via Document#root=.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: Possible Use-After-Free when directly using `NokogirI::XML::XPathContext` beyond document lifetime

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.

🚨 Nokogiri: Possible Use-After-Free in XInclude Processing

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.

🚨 Nokogiri: Possible Use-After-Free when `Nokogiri::XML::Document#encoding=` raises an exception

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.

🚨 Nokogiri: XML::Schema on JRuby allows network requests when NONET is set, bypassing CVE-2020-26247

Summary

The NONET parse option, which Nokogiri turns on by default for Nokogiri::XML::Schema (see CVE-2020-26247), 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:

# 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: GHSA-vr8q-g5c7-m54m

Credit

This issue was responsibly reported by @bilerden.

🚨 Nokogiri: Null Pointer Dereference calling methods on uninitialized wrapper classes

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.

🚨 Nokogiri: Possible Out-of-Bounds Read in `Nokogiri::XML::NodeSet#[]`

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.

🚨 Nokogiri CSS selector tokenizer has regular expression backtracking

Summary

Nokogiri's CSS selector tokenizer contains regular expressions whose construction may result in exponential regex backtracking on adversarial selectors. Three ReDoS vectors are addressed in this release:

1. String-literal tokenization on certain unterminated quoted-string input.
2. String-literal tokenization on a separate class of hex-escape-rich input.
3. Identifier tokenization on hex-escape-rich input.

The public CSS selector methods that funnel through the affected tokenizer are Nokogiri::CSS.xpath_for, Node#css, Node#at_css, Searchable#search, and CSS::Parser#parse.

Mitigation

Upgrade to Nokogiri >= 1.19.3.

If users are unable to upgrade, two options are available:

• Avoid the use of attacker-controlled text in CSS selectors. Applications that only pass developer-authored selectors to Nokogiri are not directly exposed.
• Set global Regexp.timeout (Ruby 3.2+, JRuby 9.4+) to bound parse time.

Severity

The Nokogiri maintainers have evaluated this as High Severity (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

An attacker able to inject user-supplied text into a CSS selector parse method can cause exponential backtracking, resulting in a potential denial of service.

Resources

• CWE-1333: Inefficient Regular Expression Complexity

Credit

Vector 1 was responsibly reported by @colby-swandale. Vectors 2 and 3 were discovered by @flavorjones during the response to the original report.

🚨 Nokogiri XSLT transform has a memory leak

Summary

Nokogiri's Nokogiri::XSLT::Stylesheet#transform leaks a small heap allocation when passed a Ruby string parameter containing a null byte.

For applications that pass attacker-controlled input through XSLT.transform parameters, this may be a vector for a denial of service attack against long-running processes.

Mitigation

Upgrade to Nokogiri >= 1.19.3.

Users may also be able to mitigate this issue without upgrading by validating untrusted transform parameters before passing them to Nokogiri::XSLT::Stylesheet#transform.

Severity

The Nokogiri maintainers have evaluated this as Moderate Severity, CVSS 5.3.

Each leaked allocation is approximately 24–32 bytes, so meaningful memory growth requires sustained attacker-controlled traffic at high call rates. The bug does not cause memory corruption, information disclosure, or any change in the behavior of the transform itself, and the string-handling exception is raised as expected.

Applications that do not pass raw attacker-controlled bytes to XSLT parameters are unlikely to be affected in practice.

Resources

• CWE-401: Missing Release of Memory after Effective Lifetime

Credit

This vulnerability was responsibly reported by @Captainjack-kor.

🚨 Nokogiri does not check the return value from xmlC14NExecute

Summary

Nokogiri's CRuby extension fails to check the return value from xmlC14NExecute in the method Nokogiri::XML::Document#canonicalize and Nokogiri::XML::Node#canonicalize. When canonicalization fails, an empty string is returned instead of raising an exception. This incorrect return value may allow downstream libraries to accept invalid or incomplete canonicalized XML, which has been demonstrated to enable signature validation bypass in SAML libraries.

JRuby is not affected, as the Java implementation correctly raises RuntimeError on canonicalization failure.

Mitigation

Upgrade to Nokogiri >= 1.19.1.

Severity

The maintainers have assessed this as Medium severity. Nokogiri itself is a parsing library without a clear security boundary related to canonicalization, so the direct impact is that a method returns incorrect data on invalid input. However, this behavior was exploited in practice to bypass SAML signature validation in downstream libraries (see References).

Credit

This vulnerability was responsibly reported by HackerOne researcher d4d.

Release Notes

1.19.4

v1.19.4 / 2026-06-18

Security

• [CRuby] (Low) Fixed a possible invalid memory read when XML::Node#initialize_copy_with_args is called with an argument that is not a Node. See GHSA-g9g8-vgvw-g3vf for more information.
• [CRuby] (Low) Fixed a possible use-after-free when an XML::XPathContext is used after its source document has been garbage collected. See GHSA-p67v-3w7g-wjg7 for more information.
• [CRuby] (Low) Fixed a possible use-after-free during XInclude processing via Node#do_xinclude. See GHSA-wfpw-mmfh-qq69 for more information.
• [CRuby] (Low) Fixed a possible use-after-free when Document#root= is assigned a non-element node. See GHSA-wjv4-x9w8-wm3h for more information.
• [CRuby] (Low) Fixed a possible use-after-free when setting an attribute value via XML::Attr#value= or #content=. See GHSA-phwj-rprq-35pp for more information.
• [CRuby] (Low) Fixed a null pointer dereference when methods are called on uninitialized wrapper objects (e.g. via allocate); these now raise instead of crashing the process. See GHSA-9cv2-cfxc-v4v2 for more information.
• [CRuby] (Low) Fixed a possible use-after-free when Document#encoding= raises an exception. See GHSA-5v8h-3h3q-446p for more information.
• [CRuby] (Medium) Fixed an out-of-bounds read in XML::NodeSet#[] (alias #slice) when given a large negative index. See GHSA-5prr-v3j2-97mh for more information.
• [JRuby] (Low) XML::Schema now enforces the NONET parse option, which Nokogiri enables by default. It was not enforced on JRuby, so a schema parsed with default options could still fetch external resources over the network, potentially enabling SSRF or XXE attacks and bypassing the mitigation for CVE-2020-26247. See GHSA-8678-w3jw-xfc2 for more information.

SHA256 checksums

1269fb644a6de405057a53dd5c762b1209b43ca7424f839454d3dbc677c31a8f  nokogiri-1.19.4-aarch64-linux-gnu.gem
35c65b9ce72b3bb03207bdbe7067915019dc18c1b9b59139684bd6690fdd01af  nokogiri-1.19.4-aarch64-linux-musl.gem
a301313e38bb065d68239e79734bcd6f56fb6efaacebde29e9abf2a4735340ca  nokogiri-1.19.4-arm-linux-gnu.gem
588923c101bcfa78869734d247d25b598674323e7f22474fc468f6e5647311eb  nokogiri-1.19.4-arm-linux-musl.gem
a46db9853286e6597b36ebc6953817d15acf3a299583eb3f89fdc6f91dd63527  nokogiri-1.19.4-arm64-darwin.gem
ce04b9e268c9626852231a48b49128ed52034f1ccb39484a6da3875491cd709e  nokogiri-1.19.4-java.gem
051da97b8eccfdb5444fed40246a35e10d7298b9efe759b4cd25455ea04c587e  nokogiri-1.19.4-x64-mingw-ucrt.gem
7fd17057d3e1f00e9954a74b3cd76595d3d4a5ef233b7ed9599047c204f70551  nokogiri-1.19.4-x86_64-darwin.gem
379fae440b28915e3f19d752ce2dcf8465ed2b2fbefd2a7ca0dd497bc981a06a  nokogiri-1.19.4-x86_64-linux-gnu.gem
17dfb7c1fa194ae02fbf7c51a7afc8d278045ab3fdacfd86f91d02d7b274470b  nokogiri-1.19.4-x86_64-linux-musl.gem
50c951611c92bca05c51411aef45f1cbc50f2821c4802758c5c6d34696533ab5  nokogiri-1.19.4.gem

1.19.3

v1.19.3 / 2026-04-27

Fixed / Security

• Address exponential regex backtracking in CSS selector tokenizer. See GHSA-c4rq-3m3g-8wgx for more information.
• [CRuby] Address memory leak in XSLT::Stylesheet#transform. See GHSA-v2fc-qm4h-8hqv for more information.

sha256 checksums

46b89e5d7b9e844c2ee360794240c6ea2a4e6fa0c5892a4ed487db621224b639  nokogiri-1.19.3-aarch64-linux-gnu.gem
8392dfdcd21be7a94dbbe9ccc138dea01b97b24cb2dc02a114ca98bfb1d9a0b7  nokogiri-1.19.3-aarch64-linux-musl.gem
3919d5ffc334ad778a4a9eb88fda7dcb8b1fb58c8a52ac640c6dcd2f038e774f  nokogiri-1.19.3-arm-linux-gnu.gem
9ce1cb6346bb9c67b1550eb537aa183ead91e4b6eadb2f36ade02d8dd2a79fb6  nokogiri-1.19.3-arm-linux-musl.gem
71b9bd424b1b7abc18b05052a1a3cfd3627abdca62be280854cc411791357e42  nokogiri-1.19.3-arm64-darwin.gem
40ea6ebf5cf2005dae1dee26dd557d3afb41fb6de6c9764aca8cf06fdb841db1  nokogiri-1.19.3-java.gem
8bb7132cad356c879a1286eaabcb5e68326cb2490317984280fbc62f456d506a  nokogiri-1.19.3-x64-mingw-ucrt.gem
77f3fba57d46c53ab31e62fc6c28f705109d1bf6264356c76f132b2be5728d4d  nokogiri-1.19.3-x86_64-darwin.gem
2f5078620fe12e83669b5b17311b32532a8153d02eee7ad06948b926d6080976  nokogiri-1.19.3-x86_64-linux-gnu.gem
248c906d2166eca5efb56d52fdee5f9a1f51d69a72e2b64fdac647b4ce39ea3f  nokogiri-1.19.3-x86_64-linux-musl.gem
78312cbac32a40c812780d9678221b79d51288eec00054c1a8d15f7ce05960e8  nokogiri-1.19.3.gem

1.19.2

v1.19.2 / 2026-03-19

Dependencies

• [JRuby] Saxon-HE is updated to 12.7, from 9.6.0-4. Saxon-HE is a transitive dependency of nu.validator:jing, and this update addresses CVEs in Saxon-HE's own transitive dependencies JDOM and dom4j. We don't think this warrants a security release, however we're cutting a patch release to help users whose security scanners are flagging this. [#3611] @flavorjones

SHA256 Checksums

c34d5c8208025587554608e98fd88ab125b29c80f9352b821964e9a5d5cfbd19  nokogiri-1.19.2-aarch64-linux-gnu.gem
7f6b4b0202d507326841a4f790294bf75098aef50c7173443812e3ac5cb06515  nokogiri-1.19.2-aarch64-linux-musl.gem
b7fa1139016f3dc850bda1260988f0d749934a939d04ef2da13bec060d7d5081  nokogiri-1.19.2-arm-linux-gnu.gem
61114d44f6742ff72194a1b3020967201e2eb982814778d130f6471c11f9828c  nokogiri-1.19.2-arm-linux-musl.gem
58d8ea2e31a967b843b70487a44c14c8ba1866daa1b9da9be9dbdf1b43dee205  nokogiri-1.19.2-arm64-darwin.gem
e9d67034bc80ca71043040beea8a91be5dc99b662daa38a2bfb361b7a2cc8717  nokogiri-1.19.2-java.gem
8ccf25eea3363a2c7b3f2e173a3400582c633cfead27f805df9a9c56d4852d1a  nokogiri-1.19.2-x64-mingw-ucrt.gem
7d9af11fda72dfaa2961d8c4d5380ca0b51bc389dc5f8d4b859b9644f195e7a4  nokogiri-1.19.2-x86_64-darwin.gem
fa8feca882b73e871a9845f3817a72e9734c8e974bdc4fbad6e4bc6e8076b94f  nokogiri-1.19.2-x86_64-linux-gnu.gem
93128448e61a9383a30baef041bf1f5817e22f297a1d400521e90294445069a8  nokogiri-1.19.2-x86_64-linux-musl.gem
38fdd8b59db3d5ea9e7dfb14702e882b9bf819198d5bf976f17ebce12c481756  nokogiri-1.19.2.gem

Full Changelog: v1.19.1...v1.19.2

1.19.1

v1.19.1 / 2026-02-16

Security

• [CRuby] Address unchecked return value from xmlC14NExecute which was a contributing cause to ruby-saml GHSA-x4h9-gwv3-r4m4. See GHSA-wx95-c6cv-8532 for more information.

sha256 checksums

cfdb0eafd9a554a88f12ebcc688d2b9005f9fce42b00b970e3dc199587b27f32  nokogiri-1.19.1-aarch64-linux-gnu.gem
1e2150ab43c3b373aba76cd1190af7b9e92103564063e48c474f7600923620b5  nokogiri-1.19.1-aarch64-linux-musl.gem
0a39ed59abe3bf279fab9dd4c6db6fe8af01af0608f6e1f08b8ffa4e5d407fa3  nokogiri-1.19.1-arm-linux-gnu.gem
3a18e559ee499b064aac6562d98daab3d39ba6cbb4074a1542781b2f556db47d  nokogiri-1.19.1-arm-linux-musl.gem
dfe2d337e6700eac47290407c289d56bcf85805d128c1b5a6434ddb79731cb9e  nokogiri-1.19.1-arm64-darwin.gem
1e0bda88b1c6409f0edb9e0c25f1bf9ff4fa94c3958f492a10fcf50dda594365  nokogiri-1.19.1-java.gem
110d92ae57694ae7866670d298a5d04cd150fae5a6a7849957d66f171e6aec9b  nokogiri-1.19.1-x64-mingw-ucrt.gem
7093896778cc03efb74b85f915a775862730e887f2e58d6921e3fa3d981e68bf  nokogiri-1.19.1-x86_64-darwin.gem
1a4902842a186b4f901078e692d12257678e6133858d0566152fe29cdb98456a  nokogiri-1.19.1-x86_64-linux-gnu.gem
4267f38ad4fc7e52a2e7ee28ed494e8f9d8eb4f4b3320901d55981c7b995fc23  nokogiri-1.19.1-x86_64-linux-musl.gem
598b327f36df0b172abd57b68b18979a6e14219353bca87180c31a51a00d5ad3  nokogiri-1.19.1.gem

1.19.0

v1.19.0 / 2025-12-28

Ruby

This release is focused on changes to Ruby version support, and is otherwise functionally identical to v1.18.10.

• Introduce native gem support for Ruby 4.0. #3590
• End support for Ruby 3.1, for which upstream support ended 2025-03-26.
• End support for JRuby 9.4 (which targets Ruby 3.1 compatibility).

sha256 checksums

11a97ecc3c0e7e5edcf395720b10860ef493b768f6aa80c539573530bc933767  nokogiri-1.19.0-aarch64-linux-gnu.gem
eb70507f5e01bc23dad9b8dbec2b36ad0e61d227b42d292835020ff754fb7ba9  nokogiri-1.19.0-aarch64-linux-musl.gem
572a259026b2c8b7c161fdb6469fa2d0edd2b61cd599db4bbda93289abefbfe5  nokogiri-1.19.0-arm-linux-gnu.gem
23ed90922f1a38aed555d3de4d058e90850c731c5b756d191b3dc8055948e73c  nokogiri-1.19.0-arm-linux-musl.gem
0811dfd936d5f6dd3f6d32ef790568bf29b2b7bead9ba68866847b33c9cf5810  nokogiri-1.19.0-arm64-darwin.gem
5f3a70e252be641d8a4099f7fb4cc25c81c632cb594eec9b4b8f2ca8be4374f3  nokogiri-1.19.0-java.gem
05d7ed2d95731edc9bef2811522dc396df3e476ef0d9c76793a9fca81cab056b  nokogiri-1.19.0-x64-mingw-ucrt.gem
1dad56220b603a8edb9750cd95798bffa2b8dd9dd9aa47f664009ee5b43e3067  nokogiri-1.19.0-x86_64-darwin.gem
f482b95c713d60031d48c44ce14562f8d2ce31e3a9e8dd0ccb131e9e5a68b58c  nokogiri-1.19.0-x86_64-linux-gnu.gem
1c4ca6b381622420073ce6043443af1d321e8ed93cc18b08e2666e5bd02ffae4  nokogiri-1.19.0-x86_64-linux-musl.gem
e304d21865f62518e04f2bf59f93bd3a97ca7b07e7f03952946d8e1c05f45695  nokogiri-1.19.0.gem

1.18.10

v1.18.10 / 2025-09-15

Dependencies

• [CRuby] Vendored libxml2 is updated to v2.13.9. Note that the security fixes published in v2.13.9 were already present in Nokogiri v1.18.9.
• [CRuby] [Windows and MacOS] Vendored libiconv is updated to v1.18

sha256 checksums

7fb87235d729c74a2be635376d82b1d459230cc17c50300f8e4fcaabc6195344  nokogiri-1.18.10-aarch64-linux-gnu.gem
7e74e58314297cc8a8f1b533f7212d1999dbe2639a9ee6d97b483ea2acc18944  nokogiri-1.18.10-aarch64-linux-musl.gem
51f4f25ab5d5ba1012d6b16aad96b840a10b067b93f35af6a55a2c104a7ee322  nokogiri-1.18.10-arm-linux-gnu.gem
1c6ea754e51cecc85c30ee8ab1e6aa4ce6b6e134d01717e9290e79374a9e00aa  nokogiri-1.18.10-arm-linux-musl.gem
c2b0de30770f50b92c9323fa34a4e1cf5a0af322afcacd239cd66ee1c1b22c85  nokogiri-1.18.10-arm64-darwin.gem
cd431a09c45d84a2f870ba0b7e8f571199b3727d530f2b4888a73639f76510b5  nokogiri-1.18.10-java.gem
64f40d4a41af9f7f83a4e236ad0cf8cca621b97e31f727b1bebdae565a653104  nokogiri-1.18.10-x64-mingw-ucrt.gem
536e74bed6db2b5076769cab5e5f5af0cd1dccbbd75f1b3e1fa69d1f5c2d79e2  nokogiri-1.18.10-x86_64-darwin.gem
ff5ba26ba2dbce5c04b9ea200777fd225061d7a3930548806f31db907e500f72  nokogiri-1.18.10-x86_64-linux-gnu.gem
0651fccf8c2ebbc2475c8b1dfd7ccac3a0a6d09f8a41b72db8c21808cb483385  nokogiri-1.18.10-x86_64-linux-musl.gem
d5cc0731008aa3b3a87b361203ea3d19b2069628cb55e46ac7d84a0445e69cc1  nokogiri-1.18.10.gem

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 70 commits:

• version bump to v1.19.4
• fix: JRuby NONET bypass in XML::Schema (v1.19.x) (#3639)
• fix(CRuby): use-after-free in Document#encoding= when setter raises (v1.19.x) (#3646)
• fix: JRuby NONET bypass in XML::Schema
• fix(CRuby): use-after-free in Document#encoding= when setter raises
• fix(CRuby): out-of-bounds read in NodeSet#[] with large negative index (v1.19.x) (#3647)
• fix: avoid NPE on uninitialized XML::Node structs (v1.19.x) (#3645)
• fix(CRuby): avoid UAF in XML::Attr#value= (v1.19.x) (#3644)
• fix: `Document#root=` rejects non-element nodes (v1.19.x) (#3643)
• fix(CRuby): use-after-free in XPathContext document lifetime (v1.19.x) (#3641)
• fix: `Node#initialize_copy_with_args` rejects non-Node sources (v1.19.x) (#3640)
• fix: use-after-free in `Node#do_xinclude` (v1.19.x) (#3642)
• fix: use-after-free in `Node#do_xinclude`
• test: skip int truncation tests where long==int
• fix(CRuby): out-of-bounds read in NodeSet#[] with large negative index
• fix(CRuby): use-after-free in XPathContext document lifetime
• fix: avoid NPE on uninitialized XML:Node structs
• fix(CRuby): avoid UAF in XML::Attr#value=
• fix: `Document#root=` rejects non-element nodes
• fix: `Node#initialize_copy_with_args` rejects non-Node sources
• style: disable SpaceInsidePercentLiteralDelimiters
• Merge branch 'better-valgrind-assertion-v1.19.x' into v1.19.x
• test(dev): extend refute_valgrind_errors with yield_on_jruby
• test(dev): add a test:memory_suite:valgrind rake target
• test(dev): improve refute_valgrind_errors
• test(dev): Extract memory debugger helpers
• version bump to v1.19.3
• fix: backtracking in CSS tokenizer rules (v1.19.x backport) (#3627)
• test: skip CSS tokenizer benchmarks on JRuby
• fix: ReDoS in CSS tokenizer ident rule
• fix: ReDoS in CSS tokenizer STRING rule
• fix: memory leak in XSLT transform (backport to v1.19.x) (#3624)
• doc: update CHANGELOG
• fix: memory leak in XSLT transform
• dep(test): test against libxml-ruby v6 (#3618)
• doc: add security warnings for untrusted XSLT stylesheets
• version bump to v1.19.2
• dep: upgrade Saxon-HE from 9.6.0-4 to 12.7 [v1.19.x backport] (#3614)
• dep: upgrade Saxon-HE from 9.6.0-4 to 12.7
• Skip compressed file SAX test on libxml2 >= 2.15
• version bump to v1.19.1
• doc: update CHANGELOG for upcoming v1.19.1
• C14n raise on failure (#3600)
• Raise RuntimeError when canonicalization fails
• Thank sponsors in the README
• dep: update rdoc to v7
• version bump to v1.19.0
• dev: convert scripts/test-gem-set to use mise
• dep: Add native Ruby 4 support, drop Ruby 3.1 support (v1.19.x) (#3592)
• Skip the parser compression test for Windows system libs
• ci: temporarily pin to setup-ruby with windows ruby 4
• dep: update to minitest 6
• dep: require JRuby >= 10.0
• dep: add support for native Ruby 4.0 gem
• ci: bump versions in CI images
• ci: avoid bundler collisions in downstream tests
• ci: use arm64 hosts to speed things up
• dep: make sure rdoc is an optional dependency
• dep(dev): drop explicit Bundler dependency
• version bump to v1.18.10
• dep: bump vendored libxml2 to v2.13.9 (#3555)
• ci: work around repeated bundler deadlocks
• dep: bump vendored libxml2 to v2.13.9
• [v1.18.x] backport libiconv upgrade to v1.18 (#3550)
• dep: update vendored libiconv to 1.18
• Use mirror site to download libiconv
• ci: stop testing Ruby 3.1 windows source builds
• ci: fix the aarch64 segfault by using a more modern qemu
• Fix errors building Ruby 3.1 on windows
• Fix errors building Ruby 3.1 on macos 15

✳️ bundler-audit (0.9.2 → 0.9.3) · Repo · Changelog

Release Notes

0.9.3

• Officially support Ruby 3.4, 3.5, and 4.0.
• Added support for Bundler 4.x.
• Fixed typos in API documentation.

CLI

• Ensure that the bundler-audit check command honors the BUNDLER_AUDIT_DB environment variable.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 16 commits:

• Updated the ChangeLog for 0.9.3.
• Version bump to 0.9.3.
• Added Ruby 4.0 to the CI matrix.
• Added Ruby 3.5 to the CI matrix.
• Require rubygems-tasks ~> 0.3 for Ruby 3.5 and 4.0.
• Allow using bundler 4.x
• Remove syntax highlighting from example output.
• Be consistent and only use markdown code fences.
• Fixed typo in `@return` tag.
• Update RubyGems in GitHub Actions CI (#406)
• Added Ruby 3.4 to the GitHub CI matrix.
• Disable new rubocops.
• Default `check --database` to `Database::DEFAULT_PATH`.
• Switched to using `Database::DEFAULT_PATH` instead of `Database.path`.
• Disable the `Gemspec/RequireMFA` rule since it's not aware of `gemspec.yml`.
• Added gem metadata and corrected links in gemspec.yml

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)