Skip to content

GHSA-wfpw-mmfh-qq69 CVE-2026-57438

Nokogiri: Possible Use-After-Free in XInclude Processing

Low RubyGems
Severity
2.2 / 10
Low · CVSS 4.0
Exploit chance (EPSS)
0.12%
Chance of exploitation in the next 30 days. Higher than 2.16% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-416 Use After Free
Fix
1.19.4
Upgrade nokogiri to this version or later

Description

Summary

XInclude substitution performed by Nokogiri::XML::Node#do_xinclude replaced each <xi:include> in place, freeing the include node along with its children (such as <xi:fallback> and its descendants) and any namespaces declared on them. If an application had already exposed one of those nodes or namespaces to Ruby, the corresponding Ruby object was left pointing at freed memory. Using the object could result in invalid reads or writes to memory.

Nokogiri 1.19.4 substitutes each <xi:include> on a defensive copy by default, so the structures libxml2 frees are never the ones bound to live Ruby objects.

Only the CRuby implementation is affected; JRuby is not affected.

Severity

The Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must parse a document without XInclude, traverse into an <xi:include> subtree to expose its nodes or namespaces to Ruby, and only then invoke XInclude processing. The common case, requesting XInclude at parse time, operates on a freshly parsed document whose nodes are not yet exposed to Ruby and is not affected. Nokogiri 1.19.4 makes this pattern safe by default and requires no change to application code.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

As a workaround for earlier versions, perform XInclude substitution at parse time (with the xinclude parse option) rather than calling #do_xinclude on a document that has already been traversed. A freshly parsed document has no nodes exposed to Ruby, so the substitution is safe.

Credit

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

Affected versions

RubyGems

PackageVulnerableFixed in
nokogiri
< 1.19.4
1.19.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

nokogiri RubyGems → 1.19.4

bundler
bundle update nokogiri # Gemfile: gem "nokogiri", ">= 1.19.4"

Severity breakdown

CVSS 4.0 2.2

CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector
Local
Attack complexity
High
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
Low
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Unreported
Scope
X

CVSS 3.1 6.6

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H

Attack vector
Local
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
High

Weakness

CWE-416: Use After Free

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

How to prevent it
  • Architecture and Design: Choose a language that provides automatic memory management.
  • Implementation: When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-phwj-rprq-35pp
Nokogiri: Possible Use-After-Free when setting an attribute value via `Nokogiri::XML::Attr#value=` or `#content=`
High Also affects nokogiri
GHSA-p67v-3w7g-wjg7
Nokogiri: Possible Use-After-Free when directly using `NokogirI::XML::XPathContext` beyond document lifetime
Medium Also affects nokogiri
GHSA-wjv4-x9w8-wm3h
Nokogiri: Possible Use-After-Free when setting `Document#root=` to an invalid node type
Medium Also affects nokogiri
GHSA-5prr-v3j2-97mh
Nokogiri: Possible Out-of-Bounds Read in `Nokogiri::XML::NodeSet#[]`
High Also affects nokogiri
GHSA-9cv2-cfxc-v4v2
Nokogiri: Null Pointer Dereference calling methods on uninitialized wrapper classes
High Also affects nokogiri
GHSA-8678-w3jw-xfc2
Nokogiri: XML::Schema on JRuby allows network requests when NONET is set, bypassing CVE-2020-26247
Low Also affects nokogiri
GHSA-5v8h-3h3q-446p
Nokogiri: Possible Use-After-Free when `Nokogiri::XML::Document#encoding=` raises an exception
High Also affects nokogiri
GHSA-v2fc-qm4h-8hqv
Nokogiri XSLT transform has a memory leak
Medium Also affects nokogiri
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor