Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
57 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
XInclude substitution performed by Nokogiri::XML::Node#doxinclude 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…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 nodeset.length…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.19.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.19.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.xpathfor, Node#css, Node#atcss, 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,…
Recommended action: Upgrade to 1.19.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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) Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/17d950ae CVE-2025-6170 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…
Recommended action: Upgrade to 1.18.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri v1.18.8 upgrades its dependency libxml2 to v2.13.8. libxml2 v2.13.8 addresses: - CVE-2025-32414 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/889 - CVE-2025-32415 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/890 Impact CVE-2025-32414: No impact 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…
Recommended action: Upgrade to 1.18.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri v1.18.4 upgrades its dependency libxslt to v1.1.43. libxslt v1.1.43 resolves: - CVE-2025-24855: Fix use-after-free of XPath context node - CVE-2024-55549: Fix UAF related to excluded namespaces Impact CVE-2025-24855 - "Use-after-free due to xsltEvalXPathStringNs leaking xpathCtxt-node" - MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H - Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/128 - NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2025-24855 CVE-2024-55549 - "Use-after-free related to excluded result prefixes" - MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H - Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/127 - NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2024-55549
Recommended action: Upgrade to 1.18.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri v1.18.3 upgrades its dependency libxml2 to v2.13.6. libxml2 v2.13.6 addresses: - CVE-2025-24928 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/847 - CVE-2024-56171 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/828 Impact CVE-2025-24928 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.
Recommended action: Upgrade to 1.18.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri v1.16.5 upgrades its dependency libxml2 to 2.12.7 from 2.12.6. libxml2 v2.12.7 addresses CVE-2024-34459: - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/720 - patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/2876ac53 Impact There is no impact to Nokogiri users because the issue is present only in libxml2's xmllint tool which Nokogiri does not provide or expose. Timeline - 2024-05-13 05:57 EDT, libxml2 2.12.7 release is announced - 2024-05-13 08:30 EDT, nokogiri maintainers begin triage - 2024-05-13 10:05 EDT, nokogiri v1.16.5 is released and this GHSA made public
Recommended action: Upgrade to 1.16.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri upgrades its dependency libxml2 as follows: - Nokogiri v1.15.6 upgrades libxml2 to 2.11.7 from 2.11.6 - Nokogiri v1.16.2 upgrades libxml2 to 2.12.5 from 2.12.4 libxml2 v2.11.7 and v2.12.5 address the following vulnerability: - CVE-2024-25062 / https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25062 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/604 - patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/92721970 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. 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…
Recommended action: Upgrade to 1.16.2 or 1.15.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri v1.14.3 upgrades the packaged version of its dependency libxml2 to v2.10.4 from v2.10.3. libxml2 v2.10.4 addresses the following known vulnerabilities: - CVE-2023-29469: Hashing of empty dict strings isn't deterministic - CVE-2023-28484: Fix null deref in xmlSchemaFixupComplexType - Schemas: Fix null-pointer-deref in xmlSchemaCheckCOSSTDerivedOK Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.14.3, 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. Mitigation Upgrade to Nokogiri = 1.14.3. Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against external libraries libxml2 = 2.10.4 which will also address these same issues. Impact No public information has yet been published about…
Recommended action: Upgrade to 1.14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri 1.13.8, 1.13.9 fails to check the return value from xmlTextReaderExpand in the method Nokogiri::XML::Reader#attributehash. This can lead to a null pointer exception when invalid markup is being parsed. For applications using XML::Reader to parse untrusted inputs, this may potentially be a vector for a denial of service attack. Mitigation Upgrade to Nokogiri = 1.13.10. Users may be able to search their code for calls to either XML::Reader#attributes or XML::Reader#attributehash to determine if they are affected. Severity The Nokogiri maintainers have evaluated this as High Severity 7.5 (CVSS3.1). References - CWE - CWE-252: Unchecked Return Value (4.9) - CWE - CWE-476: NULL Pointer Dereference (4.9) Credit This vulnerability was responsibly reported by @davidwilemski.
Recommended action: Upgrade to 1.13.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nokogiri v1.13.9 upgrades the packaged version of its dependency libxml2 to v2.10.3 from v2.9.14. libxml2 v2.10.3 addresses the following known vulnerabilities: - CVE-2022-2309 - CVE-2022-40304 - CVE-2022-40303 Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.9, 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. Mitigation Upgrade to Nokogiri = 1.13.9. Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against external libraries libxml2 = 2.10.3 which will also address these same issues. Impact libxml2 CVE-2022-2309 - CVSS3 score: Under evaluation - Type: Denial of service - Description: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This…
Recommended action: Upgrade to 1.13.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Use after free in Blink XSLT in Google Chrome prior to 91.0.4472.164 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
Recommended action: Upgrade to 1.13.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There is a flaw in the xml entity encoding functionality of libxml2 in versions before 2.9.11. An attacker who is able to supply a crafted file to be processed by an application linked with the affected functionality of libxml2 could trigger an out-of-bounds read. The most likely impact of this flaw is to application availability, with some potential impact to confidentiality and integrity if an attacker is able to use memory information to further exploit the application. Nokogiri prior to version 1.11.4 used a vulnerable version of libxml2. Nokogiri 1.11.4 updated libxml2 to version 2.9.11 to address this and other vulnerabilities in libxml2.
Recommended action: Upgrade to 1.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There's a flaw in libxml2 in versions before 2.9.11. An attacker who is able to submit a crafted file to be processed by an application linked with libxml2 could trigger a use-after-free. The greatest impact from this flaw is to confidentiality, integrity, and availability.
Recommended action: Upgrade to 1.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability found in libxml2 in versions before 2.9.11 shows that it did not propagate errors while parsing XML mixed content, causing a NULL dereference. If an untrusted XML document was parsed in recovery mode and post-validated, the flaw could be used to crash the application. The highest threat from this vulnerability is to system availability.
Recommended action: Upgrade to 1.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Type confusion in xsltNumberFormatGetMultipleLevel prior to libxslt 1.1.33 could allow attackers to potentially exploit heap corruption via crafted XML data. Nokogiri prior to version 1.10.5 contains a vulnerable version of libxslt. Nokogiri version 1.10.5 upgrades the dependency to libxslt 1.1.34, which contains a patch for this issue.
Recommended action: Upgrade to 1.10.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.