Nokogiri EUVD-2026-39429

Exploitation requires a specific, non-default three-step API usage pattern: (1) the application must parse an XML document WITHOUT the xinclude parse option - meaning XInclude processing is intentionally deferred; (2) the application must then traverse into an <xi:include> element's subtree and bind one or more child nodes (e.g., <xi:fallback> descendants) or namespace objects declared on those nodes to live Ruby object references; and (3) the application must subsequently call #do_xinclude on the same document. The vastly more common pattern - enabling xinclude as a parse option - is not affected because no application-level Ruby bindings to those nodes exist yet. Additionally, only CRuby (MRI) is affected; JRuby users face no risk regardless of API usage. Exploitation would be limited to processes where an attacker can influence how the application calls the Nokogiri API, making this primarily a developer-introduced vulnerability rather than an externally injectable attack surface.

Real-world risk is low despite the memory-corruption class of the bug. The CVSS 4.0 vector (AV:L/AC:H) correctly captures that this is not a remotely triggerable network service flaw - it is a library API misuse pattern that can only manifest inside an application process that calls Nokogiri in a specific, non-standard three-step sequence. The Nokogiri maintainers independently rate severity as low, consistent with the 2.2 score. No EPSS data was provided; CISA KEV status is absent, confirming no known active exploitation. No public proof-of-concept code is referenced. The CVSS 4.0 metrics show VA:H (availability High) as the dominant impact, reflecting crash potential, while VC:L/VI:L indicate limited confidentiality and integrity impact - full deterministic code execution is not implied by the available data. There is no conflict between the CVSS signals and the description; they are mutually consistent. This is a genuine low-priority issue for most deployments: applications using XInclude at parse time (the common case) are not affected, and the fix requires only a gem upgrade with no application code changes.

An application parses an XML document without the xinclude parse option, then iterates into an <xi:include> element's subtree - for example, reading attribute values from an <xi:fallback> child or collecting declared namespaces - binding those objects to Ruby variables. When the application subsequently calls document.do_xinclude, libxml2 frees the underlying C structures for those nodes, leaving the previously bound Ruby objects as dangling pointers into freed memory. Continued access to those Ruby objects (such as printing a node's content or checking a namespace URI) triggers invalid memory reads or writes, potentially crashing the process or disclosing adjacent heap contents. No public proof-of-concept exploit has been identified at time of analysis.