CVE-2026-57437: Nokogiri XPathContext Use-After-Free Memory Safety Vulnerability

Technical summary

The vulnerability exists in Nokogiri's XPathContext class, which maintains a reference to its source document for query execution. In versions before 1.19.4, the context did not prevent its document from being garbage collected, creating a use-after-free condition (CWE-416). When an application constructs an XPathContext directly, stores it, and allows the parent document to become unreachable without actively holding a strong reference, the garbage collector may reclaim the document's memory. Subsequent calls to evaluate XPath expressions on that context will then operate on dangling pointers. The CVSS 3.1 score of 5.3 (MEDIUM) reflects limited exploitability: the attack vector is network-accessible, but the condition must be triggered by vulnerable application code patterns, not by document content alone.

Business impact

For most Nokogiri users, this vulnerability poses minimal risk because standard library usage patterns—Document#xpath and Document#css—are not affected. However, applications that directly instantiate XPathContext objects while relying on implicit garbage collection of the document face availability risk. An attacker able to trigger the vulnerable code path could cause a denial of service through application crashes. Data confidentiality and integrity are not at risk. Organizations heavily dependent on Ruby-based XML/HTML processing should review whether their code uses XPathContext directly; if so, prioritize upgrading.

Affected systems

Nokogiri versions prior to 1.19.4 are affected. Ruby applications using this library are potentially at risk only if they construct XPathContext objects directly and do not maintain explicit references to the underlying document. This affects a limited subset of Nokogiri users, as most applications rely on the higher-level Document methods which manage the context-document lifecycle safely.

Exploitability

This vulnerability is difficult to exploit in practice. It requires two conditions: (1) application code must explicitly create XPathContext objects rather than using Document#xpath or Document#css, and (2) the source document must become unreachable while the context is still in use. An attacker cannot trigger this through malicious XML or HTML input alone. The vulnerability is exploitable by remote attackers only in applications with this specific architectural pattern. The lack of KEV designation reflects the narrow attack surface.

Remediation

Upgrade Nokogiri to version 1.19.4 or later. This version fixes the issue by ensuring XPathContext maintains a reference to its source document, preventing premature garbage collection. No configuration changes or workarounds are necessary. Organizations should apply this update during normal maintenance windows; while the risk is limited, updating removes the vulnerability entirely.

Patch guidance

Update the nokogiri gem to version 1.19.4 or newer. If using Bundler, update your Gemfile and run `bundle update nokogiri`. Verify the upgrade with `gem list nokogiri` or check your application's lock file. Test any code that directly uses XPathContext to ensure compatibility, though the fix is internal and should not require application code changes. Consult the vendor's release notes at nokogiri.org for full details on this and concurrent security or stability improvements.

Detection guidance

Review your Ruby application codebase for direct instantiation of Nokogiri::XML::XPathContext or Nokogiri::HTML::XPathContext. Search for patterns like `XPathContext.new` or direct context construction outside of the Document class. Most applications using standard patterns (Document#xpath, Document#css) require no investigation. If you find direct XPathContext usage, verify that the source document is held in scope for the lifetime of the context. Monitor application logs for segmentation faults or unexpected crashes that might indicate memory corruption. Upgrade to 1.19.4 to eliminate the risk regardless of code patterns.

Why prioritize this

While the CVSS score is MEDIUM (5.3), the practical risk is lower due to limited exploitability: this is not a vulnerability in the library's default behavior or triggered by document content. Prioritize this update for applications known to use XPathContext directly, or as part of routine dependency updates. Organizations without such code patterns can schedule this as a normal update cycle, though addressing it promptly is still prudent given it is a memory safety issue.

Risk score, explained

The CVSS 3.1 score of 5.3 reflects a network-reachable denial-of-service condition (availability impact only) with no confidentiality or integrity risk. The score does not account for the narrow attack surface—vulnerability requires direct XPathContext usage by the application, not by the library's standard API. This makes real-world risk lower than the numeric score suggests. The vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) indicates no privilege or user interaction required, but 'AC:L' assumes the vulnerable code path is reachable, which in practice is limited.

Frequently asked questions