CVE-2026-57435: Nokogiri XML Attribute Memory Corruption (DoS)

Technical summary

CVE-2026-57435 is a use-after-free vulnerability in Nokogiri's CRuby native extension. The flaw occurs in the Nokogiri::XML::Attr#value= method, which is used to update an attribute's text content. The vulnerability manifests when: (1) Ruby code has previously accessed a child node of an XML attribute via the document node cache, and (2) that attribute's value is subsequently replaced. Under these conditions, the native C implementation deallocates the underlying child node while a Ruby wrapper object remains in the document's node cache. A subsequent reference to that cached wrapper—either through deliberate code access or during Ruby garbage collection mark phase—dereferences the freed memory, resulting in an invalid read and potential segmentation fault. The issue is classified under CWE-416 (Use After Free) and CWE-825 (Expired Pointer Dereference), indicating improper lifetime management of heap-allocated objects.

Business impact

For Ruby applications relying on Nokogiri for XML/HTML processing, this vulnerability presents an availability risk. Any production service that parses XML documents and modifies attribute values is potentially vulnerable to denial-of-service through application crashes. This is particularly relevant for web scraping tools, API response parsers, document transformers, and content management systems built in Ruby. The vulnerability cannot be exploited for data theft or unauthorized modification, but repeated crashes can disrupt service continuity. Organizations should prioritize patching in environments where Nokogiri processes external or semi-trusted XML content, especially if those environments have strict uptime requirements.

Affected systems

The vulnerability affects Nokogiri versions prior to 1.19.4. Any Ruby application or service using an affected version of the gem is at risk if it both accesses attribute nodes and subsequently modifies attribute values on the same document. This includes Rails applications, standalone Ruby scripts, microservices, and containerized applications that bundle Nokogiri. The issue does not affect applications that only read XML without modifying attributes, nor does it impact Nokogiri installations on non-CRuby implementations (such as JRuby or TruffleRuby), which lack the affected native extension.

Exploitability

While this is a memory corruption vulnerability, exploitation requires relatively specific conditions: an attacker must cause an application to parse XML where an attribute node is accessed and then that attribute's value is updated programmatically. However, no active public exploit code exists at this time (CVE-2026-57435 is not listed on the CISA Known Exploited Vulnerabilities catalog). The vulnerability is not trivial to exploit for information disclosure or code execution due to memory layout constraints and modern mitigations like ASLR, making segfault-based denial-of-service the most practical attack vector. Attackers do not require authentication or special privileges; a remote attacker can potentially trigger the crash by supplying crafted XML to a vulnerable service.

Remediation

Upgrade Nokogiri to version 1.19.4 or later. This patch corrects the lifetime management of child node references, ensuring that the native extension does not prematurely free memory that remains reachable through the Ruby object cache. Organizations should test the upgrade in a staging environment to verify compatibility with existing application code, though version 1.19.4 is a patch release and should not introduce breaking changes. Verify against the official Nokogiri release notes and the Ruby Gems repository to confirm the installed version.

Patch guidance

Upgrade Nokogiri via your dependency manager: for Bundler, update the Gemfile to require nokogiri >= 1.19.4 and run bundle update nokogiri; for other package managers, follow similar version pinning practices. If you manage dependencies manually, download version 1.19.4 or later from rubygems.org. Ensure your CI/CD pipeline or container images reflect the patched version before redeploying. Since this is a native extension, the patch requires compilation; monitor build logs during deployment for any compilation errors specific to your Ruby version or platform.

Detection guidance

Monitor application logs and error tracking systems (e.g., Sentry, Rollbar) for segmentation faults or unexplained crashes in processes running Nokogiri. If you have instrumentation that logs Nokogiri version numbers at startup, inventory which services and containers are running versions below 1.19.4. Conduct a software bill of materials (SBOM) scan or run bundle audit to identify Nokogiri in your dependency trees. In container environments, inspect layer metadata and installed gems. Consider automated alerting on gem version changes to catch delayed patch deployments.

Why prioritize this

Despite being a memory corruption vulnerability with a HIGH CVSS score (7.5), the practical exploitability is limited to denial-of-service via application crashes, with no known active exploitation. However, availability is critical in production systems, and the vulnerability is easily remediated through a straightforward patch. Organizations should prioritize patching based on: (1) whether the affected service processes untrusted XML input, (2) the tolerance for downtime, and (3) the ease of deployment in your CI/CD pipeline. Services with high uptime requirements or that accept external XML should patch within 1–2 weeks; lower-risk internal tools can be included in the next maintenance cycle.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects a network-accessible vulnerability with no privilege or user interaction requirements, resulting in high availability impact. However, the score does not capture the limited exploitability for code execution or data exfiltration, nor does it account for the fact that active exploitation is currently absent. The score is appropriate for internal risk prioritization when considering downtime costs; organizations with very high uptime SLAs should treat this as a near-critical priority, while those with more lenient availability targets can space out patching accordingly.

Frequently asked questions