chore(deps): update dependency nokogiri to v1.19.4 [security]#15
Open
renovate[bot] wants to merge 1 commit into
Open
chore(deps): update dependency nokogiri to v1.19.4 [security]#15renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
renovate
Bot
changed the title
renovate
Bot
force-pushed
the
renovate/rubygems-nokogiri-vulnerability
branch
from
835aa87 to
461f7d4
Compare
renovate
Bot
force-pushed
the
renovate/rubygems-nokogiri-vulnerability
branch
from
461f7d4 to
bdf255b
Compare
renovate
Bot
changed the title
renovate
Bot
force-pushed
the
renovate/rubygems-nokogiri-vulnerability
branch
from
bdf255b to
c8364b9
Compare
renovate
Bot
changed the title
renovate
Bot
force-pushed
the
renovate/rubygems-nokogiri-vulnerability
branch
from
c8364b9 to
fbb3ece
Compare
renovate
Bot
changed the title
renovate
Bot
force-pushed
the
renovate/rubygems-nokogiri-vulnerability
branch
from
fbb3ece to
093594d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.18.6→1.19.4Nokogiri updates packaged libxml2 to v2.13.8 to resolve CVE-2025-32414 and CVE-2025-32415
GHSA-5w6v-399v-w3cc
More information
Details
Summary
Nokogiri v1.18.8 upgrades its dependency libxml2 to v2.13.8.
libxml2 v2.13.8 addresses:
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 maintainer:
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.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri patches vendored libxml2 to resolve multiple CVEs
GHSA-353f-x4gh-cqq8
More information
Details
Summary
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 (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L)
Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/5e9ec5c1
CVE-2025-49794
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 <sch:name path="..."/> 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)
Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5
CVE-2025-49795
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)
Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/62048278
CVE-2025-49796
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)
Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5
Affected Versions
Patched Versions
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.
References
Severity
Critical
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri does not check the return value from xmlC14NExecute
GHSA-wx95-c6cv-8532
More information
Details
Summary
Nokogiri's CRuby extension fails to check the return value from
xmlC14NExecutein the methodNokogiri::XML::Document#canonicalizeandNokogiri::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
RuntimeErroron 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.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri CSS selector tokenizer has regular expression backtracking
GHSA-c4rq-3m3g-8wgx
More information
Details
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:
The public CSS selector methods that funnel through the affected tokenizer are
Nokogiri::CSS.xpath_for,Node#css,Node#at_css,Searchable#search, andCSS::Parser#parse.Mitigation
Upgrade to Nokogiri
>= 1.19.3.If users are unable to upgrade, two options are available:
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
Credit
Vector 1 was responsibly reported by @colby-swandale. Vectors 2 and 3 were discovered by @flavorjones during the response to the original report.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri XSLT transform has a memory leak
GHSA-v2fc-qm4h-8hqv
More information
Details
Summary
Nokogiri's
Nokogiri::XSLT::Stylesheet#transformleaks a small heap allocation when passed a Ruby string parameter containing a null byte.For applications that pass attacker-controlled input through
XSLT.transformparameters, 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
Credit
This vulnerability was responsibly reported by @Captainjack-kor.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: Possible Out-of-Bounds Read in
Nokogiri::XML::NodeSet#[]GHSA-5prr-v3j2-97mh
More information
Details
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
NodeSetwith externally-supplied integers can validate the index againstnode_set.lengthbefore use, or avoid passing untrusted values as an index.Credit
This issue was responsibly reported by Zheng Yu from depthfirst.com.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: Null Pointer Dereference calling methods on uninitialized wrapper classes
GHSA-9cv2-cfxc-v4v2
More information
Details
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
.allocatedirectly 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
.allocatedirectly 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.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:UReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: XML::Schema on JRuby allows network requests when NONET is set, bypassing CVE-2020-26247
GHSA-8678-w3jw-xfc2
More information
Details
Summary
The
NONETparse option, which Nokogiri turns on by default forNokogiri::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
NONETis enabled, only local resources (afile: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
xmlNoNetExternalEntityLoaderblocks 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
NONETon 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 disableNONET, exactly as documented for CVE-2020-26247:Nokogiri::XML::ParseOptionswith theNONETflag turned off:References
Credit
This issue was responsibly reported by @bilerden.
Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: Possible Use-After-Free when setting
Document#root=to an invalid node typeGHSA-wjv4-x9w8-wm3h
More information
Details
Summary
Nokogiri::XML::Document#root=validated only that the new root was aNokogiri::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, raisingTypeErrorfor 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 raisesTypeErrorinstead 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.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:UReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: Possible Use-After-Free in XInclude Processing
GHSA-wfpw-mmfh-qq69
More information
Details
Summary
XInclude substitution performed by
Nokogiri::XML::Node#do_xincludereplaced 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
xincludeparse option) rather than calling#do_xincludeon 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.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: Possible Use-After-Free when
Nokogiri::XML::Document#encoding=raises an exceptionGHSA-5v8h-3h3q-446p
More information
Details
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 toDocument#encodingreads invalid memory, which can cause a segfault or leak freed bytes into a RubyString.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.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:UReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: Possible Use-After-Free when setting an attribute value via
Nokogiri::XML::Attr#value=or#content=GHSA-phwj-rprq-35pp
More information
Details
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#childor similar before mutating the same attribute’s value.Credit
This issue was responsibly reported by Zheng Yu from depthfirst.com.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:UReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Nokogiri: Possible Use-After-Free when directly using
NokogirI::XML::XPathContextbeyond document lifetimeGHSA-p67v-3w7g-wjg7
More information
Details
Summary
Nokogiri::XML::XPathContextdid not keep its source document alive for garbage collection. If anXPathContextoutlived 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
XPathContextdirectly and lets the document become unreachable while continuing to use the context. The normalDocument#xpath,#css, and related search methods are not affected, and it is not triggerable by malicious document input.Nokogiri 1.19.4 makes
XPathContextkeep 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::XPathContextdirectly 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
XPathContextcreated from it is in use. The standardDocument#xpath,#css, and related search methods already do this and are unaffected.Credit
This issue was responsibly reported by Zheng Yu from depthfirst.com.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U/U:ClearReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.