GHSA-7rrm-v45f-jp64

What it actually does

Nokogiri releases before 1.11.4 vendor libxml2 2.9.10, which contains multiple memory-safety defects (heap buffer overflow, use-after-free, and NULL pointer dereference) plus an exponential entity-expansion issue. When a Ruby process parses untrusted XML or HTML through Nokogiri’s native extension, those libxml2 bugs can corrupt heap memory, abort the interpreter, or in some layouts enable arbitrary code execution in the application process.

Why it matters to the business

Ruby services that ingest XML or HTML—APIs, file-upload pipelines, feed/webhook consumers, and SOAP clients—can suffer worker crashes and outages, or in a worst case full compromise of the application runtime. The issue is not in CISA KEV, has no reported in-the-wild exploitation, and is years old, so it is standard patch hygiene rather than an emergency; residual risk remains wherever untrusted documents are still parsed with Nokogiri older than 1.11.4.

How an attack unfolds

An attacker finds a Ruby application that uses Nokogiri to parse attacker-influenced XML or HTML (request bodies, uploads, webhooks, RSS/Atom, SOAP). They submit a malformed document intended to hit the bundled libxml2 2.9.10 defects—for example a crafted encoding/entity path, a malicious XInclude document, or a validation document that triggers a NULL dereference. Nokogiri invokes the vulnerable C library; the process either dies (denial of service) or, if heap layout can be influenced, memory corruption may yield code execution under the app’s privileges. No public exploit code or named threat-actor campaigns are associated with this advisory.

How to fix it

Upgrade the nokogiri gem to 1.11.4 or later, which vendors libxml2 2.9.12. In Bundler apps, constrain the gem to '>= 1.11.4' and run bundle update nokogiri, then redeploy so native extensions reload. If Nokogiri is built against system libxml2 (NOKOGIRI_USE_SYSTEM_LIBRARIES), upgrade the OS libxml2 package to 2.9.12 or later and rebuild Nokogiri. Prefer a current maintained Nokogiri line rather than remaining on 1.11.x long term.

How to confirm the fix worked

Check the installed version with bundle show nokogiri or gem list nokogiri and confirm it is 1.11.4 or higher; inspect Gemfile.lock for the resolved nokogiri version. In a Ruby console, review Nokogiri::VERSION_INFO to ensure the linked libxml2 is 2.9.12 or newer. After upgrade, exercise XML/HTML parse paths and verify application workers restart without loading the old native extension.

Typical attack path

1. Identify a Ruby application using Nokogiri to parse user-controlled XML or HTML.
2. Confirm the gem is older than 1.11.4 (vendored libxml2 2.9.10).
3. Craft a malformed XML/HTML document targeting the libxml2 memory or entity-expansion defects.
4. Deliver the document through a normal parse path (upload, API, webhook, or feed).
5. Trigger native parsing so libxml2 corrupts memory or exhausts resources.
6. Cause worker crash (denial of service) or, if corruption is controllable, execute code in the application process.
7. If code execution succeeds, abuse the app’s privileges for follow-on access.

How to detect it

There is no unique network signature or malware family for this issue, and exploit maturity is none, so hunt for effects rather than a specific payload. Review application, web-server, and job-worker logs (Puma, Unicorn, Passenger, Sidekiq, Resque) for sudden Ruby process exits, segmentation faults, or abort traces during XML/HTML parse handling around the time of suspicious document submissions. Collect core dumps or fatal error logs that mention Nokogiri or libxml2 frames (for example xmlEncodeEntitiesInternal or xmlXIncludeDoProcess). Correlate crashes with inbound XML/HTML uploads, SOAP bodies, or feed fetches. Absence of such artifacts does not prove the bug was never hit; it only means crash evidence was not retained.

• xmlEncodeEntitiesInternal
• xmlXIncludeDoProcess
• Nokogiri::XML
• nokogiri/xml_document
• Segmentation fault
• ruby
• libxml2

What your security team should do

• Inventory Ruby applications and lockfiles for nokogiri versions below 1.11.4.
• Upgrade to nokogiri 1.11.4 or later and redeploy processes so the new native extension is loaded.
• Prioritize internet-facing or multi-tenant apps that parse untrusted XML/HTML.
• Where Nokogiri uses system libxml2, patch libxml2 to 2.9.12+ independently and rebuild the gem.
• Pin a minimum nokogiri version in Gemfile to prevent accidental downgrade.
• Review historical Ruby worker crashes and core dumps around XML/HTML parsing for possible past attempts.
• Treat this as overdue hygiene, not an emergency, unless untrusted XML parsing is a primary attack surface.