GHSA-fq42-c5rg-92c2

What it actually does

Nokogiri versions before 1.13.2 vendor or link libxml2 builds that contain a use-after-free when processing XML ID and IDREF attributes. Parsing a crafted document can free attribute nodes that are later reused, corrupting the Ruby process heap. Effects range from native crashes (denial of service) to potential memory disclosure or code execution if an attacker can influence subsequent allocations.

Why it matters to the business

Ruby services that parse untrusted XML or HTML with Nokogiri—web apps, APIs, scrapers, SOAP/SAML/RSS consumers—can be crashed by a single malicious document, causing outages and worker restarts. This advisory is not in CISA KEV, has no known exploit maturity, and has been public since February 2022 (over four years), so remaining exposure mainly signals lagging gem hygiene rather than an active mass campaign. A compromised parsing process would inherit that application's privileges and data access.

How an attack unfolds

An attacker finds an application path that feeds user-controlled XML or HTML into Nokogiri (uploads, webhooks, document conversion, scraping, or protocol payloads). They submit a document whose ID/IDREF structure triggers libxml2's use-after-free during parse or validation. The process then aborts or continues with a corrupted heap. No public exploit, ransomware use, or named threat-actor campaign is associated with this advisory; practical impact is expected to be availability-focused unless combined with additional heap-control conditions.

How to fix it

Upgrade the nokogiri gem to 1.13.2 or later (bundle update nokogiri or gem update nokogiri), commit the lockfile, and restart all Ruby processes so old native extensions unload. If using system libxml2 instead of Nokogiri's vendored copy, upgrade libxml2 to 2.9.13 or later and rebuild native extensions. Audit transitive gems that pin or vendor older Nokogiri and raise those constraints as well.

How to confirm the fix worked

Check Gemfile.lock and installed gems (bundle show nokogiri or gem list nokogiri) and confirm the resolved version is 1.13.2 or newer. Run nokogiri -v and verify the linked libxml2 is 2.9.13 or later. Add a CI/SCA gate that fails when nokogiri is below 1.13.2. After deploy, exercise XML/HTML parse paths and watch for native segfaults or worker deaths.

Typical attack path

1. Locate a Ruby service that parses untrusted XML or HTML with Nokogiri
2. Deliver a crafted document containing ID and IDREF attributes to that parser
3. Trigger the libxml2 use-after-free during parse or DTD/IDREF handling
4. Induce a process crash for denial of service, or attempt to abuse resulting heap corruption if further primitives exist
5. If the process is taken over, act with the privileges of the affected Ruby worker

How to detect it

No in-the-wild campaign or unique payload signature is known. Hunt unexplained Ruby process crashes, segmentation faults, or core dumps whose stacks include nokogiri, xmlSoft, or libxml2 during XML parse; spikes in 5xx responses or worker restarts coinciding with XML/HTML intake; and application logs showing parse failures immediately before process death. Review deploy and package logs for nokogiri versions below 1.13.2 running after 2022-02-25. Silent successful exploitation is difficult to prove from logs alone without a crash or memory-corruption artifact.

What your security team should do

• Inventory all Ruby lockfiles and images for nokogiri below 1.13.2; treat remaining hits as overdue patching
• Prioritize internet-facing parsers and workers that accept XML or HTML from untrusted sources
• Upgrade to nokogiri 1.13.2 or later, rebuild native extensions if needed, and restart processes
• Enforce SCA/lockfile policy so outdated Nokogiri cannot ship
• Review historical Ruby crash dumps and worker-restart spikes around XML parse activity if a compromise assessment is required