GHSA-vcc3-rw6f-jv97

What it actually does

This is a use-after-free memory safety flaw in libxml2 reachable through Nokogiri::XML::Reader when parsing specially crafted XML. A vulnerable process may dereference memory after it has been freed, leading to process crashes and, in less common but higher-impact conditions, possible memory corruption that could affect confidentiality, integrity, or control flow of the Ruby process using Nokogiri. The issue is relevant to applications, containers, and packaged products that process untrusted XML with affected Nokogiri/libxml2 builds, including the listed Chainguard NeuVector packages before 5.4.4-r3 and Nokogiri before 1.15.6.

Why it matters to the business

Systems that accept or ingest XML from users, partners, feeds, APIs, files, or message queues may be vulnerable to denial of service if a crafted XML document crashes the service or background worker. If the vulnerable parser runs inside a security, monitoring, or admission-control component, outages may reduce visibility or enforcement. No CISA KEV listing, ransomware association, or mature public exploitation is indicated in the provided data, which lowers immediate emergency priority, but the issue has been public for a long time and should be remediated as part of normal vulnerability management, especially in internet-facing or automated XML-processing workflows.

How an attack unfolds

An attacker first identifies an application or component that parses attacker-controlled XML using Nokogiri::XML::Reader backed by a vulnerable libxml2 version. The attacker then submits a malformed or specially structured XML document through an upload feature, API request, integration feed, import job, webhook, message queue, or other XML ingestion path. During streaming XML parsing, libxml2 reaches the vulnerable memory-management condition and accesses freed memory. The most likely observable result is a segmentation fault, worker crash, container restart, or service instability. In a more advanced scenario, an attacker would attempt to shape heap state and repeat attempts to turn memory corruption into a stronger primitive, but no mature exploit is identified from the supplied data.

How to fix it

Upgrade affected components to fixed versions or later. For Ruby applications, upgrade Nokogiri to 1.15.6 or later and rebuild/redeploy the application so the fixed native extension and bundled or linked libxml2 are actually in use. For Chainguard NeuVector packages, upgrade neuvector, neuvector-cis-benchmarks, neuvector-controller, neuvector-enforcer, neuvector-monitor, and neuvector-nstools to 5.4.4-r3 or later. Rebuild container images, refresh lockfiles, redeploy workloads, and remove older vulnerable images from registries where practical. If immediate upgrade is not possible, reduce exposure by rejecting untrusted XML, enforcing strict file size and complexity limits, disabling unnecessary XML ingestion features, isolating XML parsing workers, using restart limits and resource controls, and monitoring for parser crashes.

How to confirm the fix worked

Confirm fixed dependency versions in both build artifacts and running workloads. For Ruby applications, verify Nokogiri is 1.15.6 or later using lockfiles, SBOMs, package inventory, and runtime checks. For Chainguard NeuVector packages, verify installed versions are 5.4.4-r3 or later. Rebuild and redeploy all dependent images so stale vulnerable layers are removed from active use. Run vulnerability scans against deployed containers and hosts, and test XML-processing workflows to ensure parsing still functions without crashes.

Typical attack path

1. Find an application, service, container, or packaged product that accepts XML input and uses vulnerable Nokogiri/libxml2 components.
2. Identify reachable XML parsing paths such as file upload, API import, SOAP/XML endpoint, feed ingestion, webhook processing, or background document processing.
3. Submit crafted XML designed to trigger the libxml2 use-after-free through Nokogiri::XML::Reader.
4. Observe whether the target process crashes, restarts, returns 500 errors, drops connections, or produces parsing-related faults.
5. Repeat or vary payloads to cause reliable denial of service, or, in a more advanced attack, attempt to influence memory layout for deeper exploitation.

How to detect it

Review application, web server, container, kernel, and process supervisor logs for crashes or restarts that occur immediately after XML parsing, XML upload, XML import, SOAP, feed ingestion, webhook, or document-processing requests. Focus on segmentation faults, core dumps, abnormal exits, repeated 500 responses, connection resets, and restart loops involving Ruby, Rails, Puma, Sidekiq, Resque, Passenger, or other processes that use Nokogiri. Inspect crash dumps or stack traces for symbols and paths referencing Nokogiri::XML::Reader, libxml2, xmlTextReader, or reader-related parsing code. In web and API logs, look for repeated requests with XML content types, malformed XML bodies, unusual nesting, large or complex XML, or repeated attempts from the same source followed by service crashes. If memory-corruption exploitation beyond denial of service is suspected, review endpoint telemetry for unexpected child processes, outbound network connections, modified application files, new scheduled jobs, or shell execution spawned by the XML-processing application process. No vulnerability-specific network signature or payload string is derivable from the supplied advisory data.

• Nokogiri::XML::Reader
• nokogiri/xml/reader
• libxml2
• xmlTextReader
• Segmentation fault
• segfault
• core dumped
• signal 11
• SIGSEGV
• nokogiri (1.15.5)
• nokogiri (1.15.4)
• nokogiri (1.15.3)
• nokogiri (1.15.2)
• nokogiri (1.15.1)
• nokogiri (1.15.0)

What your security team should do

• Prioritize internet-facing, partner-facing, automated, or high-volume XML ingestion services that use Nokogiri::XML::Reader or packaged NeuVector components.
• Upgrade Nokogiri to 1.15.6 or later and Chainguard NeuVector-related packages to 5.4.4-r3 or later, then rebuild and redeploy affected images and services.
• Generate or refresh SBOMs for Ruby applications and container images to identify transitive Nokogiri/libxml2 exposure.
• Search historical logs for XML-triggered crashes, segmentation faults, worker restarts, and repeated malformed XML requests before and after remediation.
• Apply input validation, file size limits, parser timeouts, and isolation around XML processing paths to reduce future parser vulnerability impact.
• Track this as normal-to-high priority based on exposure because public details exist, but no KEV listing, ransomware use, or mature exploit is indicated by the supplied data.