Nokogiri EUVD-2026-39427

Exploitation requires that application code explicitly calls Nokogiri::XML::Document#root= with a non-element node - specifically a DTD node or any other Nokogiri::XML::Node subclass that is not an element node - in the CRuby implementation of Nokogiri prior to 1.19.4. This cannot be triggered by untrusted user input (e.g., maliciously crafted XML documents), by normal API usage, or by any network-reachable code path absent a pre-existing programming error in the application. The JRuby runtime is entirely unaffected. What limits exploitation further: the crash (segfault or invalid memory read) occurs during garbage collection or finalization, not deterministically at the assignment, making it difficult to construct a reliable exploit even in the erroneous code scenario. The attacker model here is effectively a developer writing incorrect application code, not an external adversary.

Real-world risk is very low, consistent with the CVSS 4.0 score of 1.7. The critical limiting factor confirmed by the vendor is that this vulnerability cannot be triggered by untrusted input or through correct API usage - it requires a programming error in application code where a DTD node is explicitly passed to Document#root=. The CVSS 4.0 vector's AT:P (attack requirements present) captures this constraint: a specific non-default, incorrect code pattern must exist in the consuming application. Availability impact is Low (VA:L), with no confidentiality or integrity impact (VC:N/VI:N). The E:U (unexploited) signal reinforces that no exploitation attempt has been observed. There is no KEV listing and no public exploit identified. The risk profile is effectively that of a latent crash bug in applications that misuse the API, rather than an externally exploitable attack surface. Security teams should prioritize this as a routine gem upgrade during normal dependency maintenance, not an emergency response item.

A Ruby application using Nokogiri on CRuby parses an XML document and, due to a developer error, extracts the DTD node from the document and assigns it as the root via document.root = document.internal_subset. At some subsequent point - possibly during a request cycle's cleanup, process shutdown, or garbage collection run - Ruby's GC finalizes the document object, libxml2 attempts to free the DTD node through the root pointer, and the process crashes with a segfault or accesses already-freed heap memory. No public exploit code exists; the scenario requires attacker-controlled application code rather than attacker-controlled input data.