GHSA-pxvg-2qj5-37jq

What it actually does

Nokogiri versions before 1.14.3 include a packaged copy of libxml2 older than 2.10.4 that contains multiple memory-corruption defects. Applications that parse attacker-controlled XML, HTML, XHTML, SVG, SOAP, RSS/Atom, or other XML-derived content through Nokogiri may trigger unsafe memory behavior in libxml2. Depending on the specific parsing path, platform hardening, allocator behavior, and process privileges, impact can range from process crash and denial of service to potential memory disclosure or, in worst-case conditions, arbitrary code execution within the application process.

Why it matters to the business

A vulnerable application may be destabilized by malformed documents supplied through uploads, API payloads, feeds, integrations, email/file processing, or web scraping workflows. The most likely operational outcome is service disruption or worker crashes; higher-impact outcomes could include compromise of the application process if a memory-corruption path is weaponized. This issue is not listed in CISA KEV, has no provided evidence of mature public exploitation, and was published more than three years ago, so remediation should be treated as dependency hygiene with priority increased for internet-facing or automated document-parsing services.

How an attack unfolds

An attacker first identifies an application or background job that uses Nokogiri to parse content the attacker can influence. They then craft malformed XML or XML-like input designed to reach vulnerable libxml2 parsing code packaged inside the affected Nokogiri gem. The payload is delivered through a supported ingestion path such as a file upload, API request body, XML/SOAP endpoint, imported feed, attachment-processing workflow, or crawler target. When the application parses the document, libxml2 mishandles memory, which may crash the process, corrupt heap state, disclose memory, or potentially allow execution of attacker-controlled code in the context of the running application. Successful exploitation evidence may be limited because crashes can look like ordinary parser failures unless core dumps, application exceptions, and process restarts are centrally retained.

How to fix it

Upgrade Nokogiri to version 1.14.3 or later. For Ruby applications, update dependency constraints in Gemfile or gemspec as needed, run `bundle update nokogiri`, and verify Gemfile.lock resolves to `nokogiri (1.14.3)` or a newer version. Rebuild and redeploy application containers, images, serverless packages, and offline worker artifacts so the updated native extension and packaged libxml2 are actually present at runtime. Do not rely only on operating-system libxml2 patches when using precompiled Nokogiri gems, because Nokogiri may use its own packaged libxml2. If immediate upgrade is not possible, reduce exposure by rejecting untrusted XML-like uploads where feasible, disabling unnecessary XML features, imposing strict file size/depth/entity limits, running parsing workloads with least privilege, isolating parser workers, and ensuring automatic restart does not mask repeated crash attempts.

How to confirm the fix worked

Confirm dependency resolution and runtime library versions, not just source-code intent. Check `Gemfile.lock` for Nokogiri 1.14.3 or later, run `bundle exec ruby -rnokogiri -e 'puts Nokogiri::VERSION; puts Nokogiri::LIBXML_LOADED_VERSION'`, and verify Nokogiri is at least 1.14.3 and the loaded libxml2 version is 2.10.4 or later where applicable. In containerized deployments, run the check inside the final runtime image. Scan SBOMs, dependency manifests, lockfiles, built artifacts, and deployed images for Nokogiri versions below 1.14.3. Exercise representative XML/HTML/SVG parsing workflows after upgrade to confirm no compatibility regressions and that the patched package is loaded in web, worker, and scheduled-job processes.

Typical attack path

1. Find an application feature or service that accepts or retrieves XML, HTML, SVG, SOAP, RSS, Atom, or other markup that is parsed by Nokogiri.
2. Confirm or infer that the application uses a vulnerable Nokogiri version before 1.14.3 with packaged libxml2 older than 2.10.4.
3. Craft malformed markup intended to exercise vulnerable libxml2 parsing behavior.
4. Deliver the payload through an upload, API call, feed import, attachment, web-crawled page, or integration endpoint.
5. Trigger Nokogiri parsing in a web process, worker, job queue consumer, or batch processor.
6. Observe service errors, parser crashes, worker restarts, memory faults, or other side effects; in more severe scenarios, attempt to shape memory corruption toward data exposure or code execution.

How to detect it

There are no reliable vulnerability-specific network or file indicators for confirmed exploitation because this is a library memory-corruption issue triggered by crafted parser input. Look for suspicious activity in application, web server, API gateway, job runner, container, EDR, and system logs around endpoints or workflows that parse XML, HTML, SVG, SOAP, RSS, Atom, or uploaded documents. Relevant signs include repeated malformed-document submissions from the same source, sudden spikes in 4xx/5xx responses during parsing operations, Ruby process crashes, segmentation faults, aborts, core dumps, container restarts, job retries, and worker exits following document ingestion. Preserve and examine submitted payloads associated with crashes where legally and operationally appropriate. Correlate process crashes with inbound requests, uploaded files, feed fetches, background job arguments, and scheduler activity. For forensic review, search for Nokogiri/libxml2 parser exceptions immediately preceding abnormal process termination, and inspect core dumps only in controlled environments because they may contain sensitive application memory.

What your security team should do

• Inventory Ruby applications, containers, and worker services that include the Nokogiri RubyGem and prioritize those that parse untrusted or internet-sourced markup.
• Upgrade all affected Nokogiri dependencies to 1.14.3 or later and rebuild deployed artifacts from clean dependency caches.
• Verify runtime versions inside production-equivalent images or hosts using Nokogiri::VERSION and Nokogiri::LIBXML_LOADED_VERSION.
• Add dependency scanning or SBOM policy checks that fail builds when Nokogiri is below 1.14.3.
• Review application logs and crash telemetry for historical parser-related segmentation faults, abnormal worker exits, repeated restarts, or malformed XML/HTML processing errors around exposed ingestion points.
• For high-risk parsing services, apply defense-in-depth limits on document size, nesting depth, external resource loading, request rate, and parser process privileges.
• Because this issue is not in KEV and no exploit maturity is provided, prioritize based on exposure: internet-facing document parsing first, internal trusted-only parsing next.