GHSA-v6gp-9mmm-c6p5

What it actually does

Nokogiri versions before 1.13.4 vendor a zlib copy with an out-of-bounds write in the deflate/compression path. Crafted input processed during compression can overwrite memory adjacent to the compression buffer, typically crashing the Ruby process and, depending on allocator layout, enabling further memory corruption.

Why it matters to the business

Ruby services that compress untrusted or attacker-influenced data with Nokogiri can suffer worker crashes, request failures, and repeated process restarts. Nokogiri is a foundational XML/HTML gem, so many applications and downstream gems may be exposed. The issue is not in CISA KEV, has no reported ransomware or in-the-wild use, and has no public exploit maturity, but unpatched services remain exposed to denial of service more than three years after disclosure.

How an attack unfolds

An attacker finds a Ruby application using a vulnerable Nokogiri build whose compression path is reachable with untrusted data. They submit input that is deflated through the vendored zlib. The flawed compressor writes past the allocated buffer, corrupting nearby heap memory. The usual outcome is an immediate process crash (denial of service); under favorable memory conditions the same write could theoretically be leveraged for broader memory corruption. No public exploit maturity or named threat-actor use is reported.

How to fix it

Upgrade the nokogiri RubyGem to 1.13.4 or later so the vendored zlib includes the out-of-bounds-write fix. Refresh lockfiles (Gemfile.lock / gems.locked), rebuild native extensions, and redeploy. Inventory all applications and container images that bundle Nokogiri, including transitive dependencies. If Nokogiri is built against system zlib, ensure the OS zlib package is also patched, then restart application processes.

How to confirm the fix worked

Confirm installed Nokogiri is 1.13.4 or newer via bundle show nokogiri, gem list nokogiri, or Gemfile.lock. Rebuild and restart workers after upgrade. Treat any remaining 1.13.3 or earlier installs as exposed. Optionally compare the vendored zlib version inside the gem against 1.2.12 or later.

Typical attack path

1. Locate a Ruby application that uses Nokogiri older than 1.13.4 and compresses attacker-influenced data
2. Submit crafted input that reaches Nokogiri’s vendored zlib deflate path
3. Trigger the out-of-bounds write during compression
4. Cause the Ruby process or worker to crash, producing denial of service
5. Repeat submissions to keep workers down or unstable

How to detect it

There are no public exploits, named threat actors, or KEV/ransomware associations for this issue, so compromise is unlikely to leave distinct malware artifacts. Hunt for unexplained Ruby process crashes, segmentation faults, and worker restarts (Puma, Unicorn, Sidekiq, Passenger) around compression or Nokogiri use. Review application logs, systemd/journald, container runtime logs, and core dumps for native frames in zlib deflate, nokogiri, or related compression helpers. Correlate crash bursts with untrusted upload or compression endpoints. Presence of Nokogiri older than 1.13.4 indicates exposure, not confirmed exploitation.

What your security team should do

• Prioritize upgrading nokogiri to 1.13.4+ across all Ruby applications and images that compress untrusted data
• Inventory direct and transitive Nokogiri usage in Gemfile.lock files and CI artifacts
• Redeploy patched builds and restart long-lived workers so old native extensions are not left loaded
• Track this as a memory-corruption/DoS risk rather than an active KEV or ransomware item; exploit maturity is none
• Add a dependency policy or SCA gate that fails builds on Nokogiri versions below 1.13.4