Nokogiri EUVD-2026-39419

Three specific conditions must align simultaneously for exploitation: (1) the application must pass an attacker-controlled or otherwise invalid encoding value - specifically a non-string or a string containing a null byte - to Document#encoding= on a Nokogiri XML document; (2) the application must rescue the resulting Ruby exception rather than allowing it to propagate, terminate the operation, or replace the document; and (3) the application must subsequently call Document#encoding on the same, now-corrupted document object. Applications that pass only developer-authored, hardcoded encoding strings are not exposed. Applications that do not rescue the Document#encoding= exception and continue using the document are not exposed. JRuby-based Nokogiri installations are immune regardless of usage pattern.

The provided CVSS 4.0 score of 1.7 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L) is broadly accurate, with the AT:P (attack requirements: present) metric correctly capturing the non-default exploitation preconditions. Real-world risk is very low: the Nokogiri maintainers themselves rate it low severity and describe the triggering pattern as unusual. No KEV listing confirms active exploitation, no public POC has been identified, and no EPSS score was provided in the input data. The network attack vector (AV:N) reflects that a remote attacker who controls parsing input could theoretically reach this code path, but only if the application also rescues the exception and reuses the document - a pattern that does not arise during normal Nokogiri use. The primary realistic impact is a process crash (availability) rather than meaningful information disclosure, as heap byte leaks via this path are limited in scope. This is a patch-and-move-on issue with no urgency for emergency remediation in most environments.

An attacker who controls input to a Ruby application that passes user-supplied data to Document#encoding= can submit a null-byte-containing string, causing the method to free the internal encoding pointer and raise a Ruby exception. If the application rescues this exception and continues using the same document object - for example, in an error-tolerant document processing pipeline - the next call to Document#encoding reads freed heap memory, either crashing the Ruby process or returning stale heap bytes as a string value. No public proof-of-concept code has been identified at time of analysis.