Nokogiri (鋸) makes it easy and painless to work with XML and HTML from Ruby. It provides a sensible, easy-to-understand API for reading, writing, modifying, and querying documents. It is fast and standards-compliant by relying on native parsers like libxml2, libgumbo, or xerces.
Stack-buffer overflow is possible when reporting DTD validation errors if the input contains a long (~3kb) QName prefix.
CVE-2024-56171
Use-after-free is possible during validation against untrusted XML Schemas (.xsd) and, potentially, validation of untrusted documents against trusted Schemas if they make use of xsd:keyref in combination with recursively defined types that have additional identity constraints.
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.
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.
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:
Ensure the input is trusted. Do not enable this option for untrusted input.
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)
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'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:
String-literal tokenization on certain unterminated quoted-string input.
String-literal tokenization on a separate class of hex-escape-rich input.
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.
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’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'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.
Please note that this advisory only applies to the CRuby implementation of Nokogiri, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.
JRuby users are not affected.
Severity
The Nokogiri maintainers have evaluated this as Moderate.
Impact
From the CVE description, this issue applies to the xmlTextReader module (which underlies Nokogiri::XML::Reader):
When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.
Mitigation
Upgrade to Nokogiri ~> 1.15.6 or >= 1.16.2.
Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against patched external libxml2 libraries which will also address these same issues.
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::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'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.
Nokogiri v1.18.9 patches the vendored libxml2 to address CVE-2025-6021, CVE-2025-6170, CVE-2025-49794, CVE-2025-49795, and CVE-2025-49796.
Impact and severity
CVE-2025-6021
A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.
NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.
NVD claims a severity of 2.5 Low (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L)
A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.
NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)
A NULL pointer dereference vulnerability was found in libxml2 when processing XPath XML expressions. This flaw allows an attacker to craft a malicious XML input to libxml2, leading to a denial of service.
NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.
NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)
Nokogiri < 1.18.9 when using CRuby (MRI) with vendored libxml2
Patched Versions
Nokogiri >= 1.18.9
Mitigation
Upgrade to Nokogiri v1.18.9 or later.
Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against patched external libxml2 libraries which will also address these same issues.
In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.
There is no impact from this CVE for Nokogiri users.
CVE-2025-32415: Low impact
In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.
In the upstream issue, further context is provided by the maintainer:
The bug affects validation against untrusted XML Schemas (.xsd) and validation of untrusted documents against trusted Schemas if they make use of xsd:keyref in combination with recursively defined types that have additional identity constraints.
MITRE has published a severity score of 2.9 LOW (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) for this CVE.
The protected copy helper behind Node#dup and #clone unwrapped its source argument as an xmlNode without a type check. Supplying a non-Node (e.g. a Namespace) made it read an xmlNs out of bounds, crashing the process.
Nokogiri 1.19.4 performs a type check and raises TypeError when an argument of invalid type is passed.
Only CRuby is affected. 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 the protected internal initializecopywith_args method with an argument that is not a Nokogiri::XML::Node. Nokogiri 1.19.4 now raises TypeError instead of reading out of bounds. It cannot be triggered by untrusted input or through normal use of the public API.
Mitigation
Upgrade to Nokogiri 1.19.4 or later. There is no workaround.
Credit
This issue was responsibly reported by Zheng Yu from depthfirst.com.
Stack-buffer overflow is possible when reporting DTD validation errors if the input contains a long (~3kb) QName prefix.
CVE-2024-56171
Use-after-free is possible during validation against untrusted XML Schemas (.xsd) and, potentially, validation of untrusted documents against trusted Schemas if they make use of xsd:keyref in combination with recursively defined types that have additional identity constraints.
Please note that this advisory only applies to the CRuby implementation of Nokogiri, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.
JRuby users are not affected.
Severity
The Nokogiri maintainers have evaluated this as Moderate.
Impact
From the CVE description, this issue applies to the xmlTextReader module (which underlies Nokogiri::XML::Reader):
When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.
Mitigation
Upgrade to Nokogiri ~> 1.15.6 or >= 1.16.2.
Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against patched external libxml2 libraries which will also address these same issues.
