GHSA-cgx6-hpwq-fhv5

What it actually does

An integer overflow/wraparound in libxml2 buffer handling (xmlBuf/xmlBuffer growth and related paths) is reachable through Nokogiri XML/HTML parsing. Oversized or crafted input can wrap size calculations, producing undersized allocations and subsequent out-of-bounds writes. Impact is memory corruption in the native extension: typically process crash (DoS) and, in some runtimes, further memory-safety failure. Scope is any Ruby process that parses attacker-influenced XML/HTML with a vulnerable Nokogiri (vendored libxml2 before the 1.13.5 bump, or an unpatched system libxml2 when built with system libraries).

Why it matters to the business

Nokogiri is a default XML/HTML parser across much of the Ruby and Rails ecosystem, so unpatched gems leave web apps, APIs, background jobs, and document pipelines exposed to untrusted markup. Practical outcomes are service crashes, failed imports, and potential integrity loss in parsers that handle customer uploads, webhooks, feeds, or scraped content. The issue is not listed in CISA KEV, has no public exploit maturity, and is years past publication (2022), so remaining risk is concentrated in unmaintained apps, pinned gems, and images still shipping Nokogiri < 1.13.5. Treat leftover exposure as hygiene debt with high blast radius rather than an active mass-exploitation emergency.

How an attack unfolds

An attacker finds an application that parses XML or HTML from an untrusted source (upload, HTTP body, SOAP/XML API, feed, or scraped page) using a vulnerable Nokogiri. They submit a crafted document that drives libxml2 buffer-size arithmetic to wrap, so the parser allocates too little memory and writes past the buffer. The worker or web process then crashes or corrupts heap state. No named threat actors or ransomware campaigns are associated with this advisory; public exploit maturity is none. Exploitation therefore depends on the application accepting untrusted markup and running an old Nokogiri/libxml2 combination, not on a known in-the-wild kit.

How to fix it

Upgrade the nokogiri gem to 1.13.5 or later (the advisory’s fixed version; prefer current maintained 1.13.x/1.14+ or 1.15+/1.16+ lines as supported). Rebuild native extensions after upgrade. If Nokogiri was built with --use-system-libraries, also patch OS libxml2 to a release that includes the xmlBuf/xmlBuffer overflow fixes (libxml2 2.9.14 or vendor-equivalent) and restart Ruby processes. Remove version pins in Gemfile.lock that keep Nokogiri < 1.13.5. Do not rely on input filtering as the primary fix; untrusted XML/HTML should still be parsed only with patched libraries.

How to confirm the fix worked

Run bundle show nokogiri (or gem list nokogiri) and confirm version >= 1.13.5. Inspect Gemfile.lock and container/base images for older nokogiri. For system-library builds, verify libxml2 >= 2.9.14 (or the distro package that backports CVE-2022-29824). After deploy, restart app servers and workers, then parse representative XML/HTML through the same code paths. Use bundle-audit / dependency scanners to assert the GHSA is cleared. Confirm native extension load path matches the upgraded gem, not a stale vendor copy.

Typical attack path

1. Locate a Ruby service that parses untrusted XML/HTML with Nokogiri (file upload, API, feed, scraper, or SOAP).
2. Confirm the process uses Nokogiri before 1.13.5 or links an unpatched system libxml2.
3. Submit a crafted document that stresses libxml2 buffer growth/size calculations.
4. Trigger integer wraparound and out-of-bounds write in the native parser.
5. Cause worker crash (availability impact) or memory corruption in the parsing process.

How to detect it

There is no public in-the-wild campaign or named actor for this advisory, so hunt for crash evidence rather than a unique payload signature. Review application, systemd/journald, container, and APM logs for Ruby process aborts, SIGSEGV/SIGABRT, or worker restarts coincident with XML/HTML parse, file upload, feed ingest, or SOAP endpoints. Look at native backtraces mentioning libxml2, xmlBuf, xmlBuffer, or nokogiri’s native extension around the time of the crash. Compare those hosts’ Nokogiri/libxml2 versions to 1.13.5 / libxml2 2.9.14. Core dumps or segfault reports in /var/crash, container OOM/segfault events, and repeated Puma/Unicorn/Sidekiq restarts after parse jobs are the primary artifacts. Absence of those signals does not prove non-exploitation; it only means memory-corruption attempts may have failed or not been logged.

What your security team should do

• Inventory all Ruby apps, gems, and images still shipping Nokogiri < 1.13.5 and treat those as the patch set.
• Force upgrade to nokogiri 1.13.5+ (or current maintained line) and rebuild/restart processes; patch system libxml2 where system libraries are used.
• Prioritize internet-facing parsers of uploads, webhooks, feeds, and SOAP/XML APIs over internal-only tools.
• Add CI/dependency-policy gates so Nokogiri cannot regress below 1.13.5.
• Because this is not KEV and has no known in-the-wild exploitation, complete remaining upgrades as high-priority hygiene rather than emergency incident response—unless a crash cluster appears on XML parse paths.