GHSA-gx8x-g87m-h5q6

What it actually does

On JRuby only, Nokogiri versions before 1.13.4 use an inefficient regular expression during HTML character-encoding detection. Crafted HTML can trigger catastrophic backtracking (ReDoS), pinning CPU and stalling the parsing thread until timeout, worker kill, or process exhaustion. Confidentiality and integrity are unaffected; impact is availability of the JRuby worker or process that invoked the parser. MRI/CRuby builds that use libxml2/gumbo are not affected by this regex defect.

Why it matters to the business

JRuby applications that parse untrusted HTML—content ingestion, user-generated markup, scrapers, email/HTML renderers, SSO or feed consumers—can be taken offline by a single unauthenticated request, causing outages, SLA breaches, and wasted compute. Nokogiri is a foundational RubyGems dependency, so exposure is often transitive. The issue has been public since 11 April 2022 (patch in 1.13.4) and is not in CISA KEV, with no recorded exploit maturity or ransomware use; remaining risk is unpatched JRuby estates that never upgraded.

How an attack unfolds

An unauthenticated attacker finds any path where a JRuby app feeds attacker-controlled HTML into Nokogiri (upload, URL fetch, webhook, form field, or MIME part). They submit a document whose encoding/charset-related content forces the vulnerable encoding-detection regex into catastrophic backtracking. The parse never completes in reasonable time; the worker pegs a CPU core and stops handling other work. Repeating or parallelizing the request exhausts the thread pool and produces a service outage. No privileges, code execution, or follow-on payload are required. No named threat actors or campaigns are associated with this issue.

How to fix it

Upgrade nokogiri (RubyGems) to 1.13.4 or later on every JRuby application. Pin `gem 'nokogiri', '>= 1.13.4'` and refresh Gemfile.lock, then redeploy. Updating libxml2 alone does not fix this JRuby regex issue. If an immediate upgrade is not possible, stop parsing untrusted HTML on JRuby, enforce strict size and wall-clock timeouts around parse calls, isolate parsers in workers with CPU/time quotas, or shift HTML parsing onto MRI processes that are not affected.

How to confirm the fix worked

On each JRuby host or image, inspect Gemfile.lock or run `bundle show nokogiri` / `gem list nokogiri` and confirm version >= 1.13.4. Confirm affected apps actually run on JRuby (`RUBY_ENGINE`). After upgrade, regression-test HTML parsing paths (including documents with unusual charset declarations) under load and verify parse times stay bounded. SCA/SBOM scans should no longer report nokogiri < 1.13.4.

Typical attack path

1. Locate a JRuby application that parses untrusted HTML with Nokogiri.
2. Confirm the runtime is JRuby and nokogiri is older than 1.13.4.
3. Submit crafted HTML through an input that reaches Nokogiri HTML parsing or encoding detection.
4. Observe extreme parse latency and CPU saturation on the affected worker.
5. Repeat or fan out submissions to exhaust workers and deny service to legitimate users.

How to detect it

This ReDoS leaves no unique malware artifacts. Hunt for already-occurred abuse via APM or access logs showing HTML ingest/upload endpoints with extreme duration or 502/504 spikes at low request volume; JVM thread dumps stuck in JRuby regexp evaluation or Nokogiri HTML encoding detection; worker timeouts, thread-pool exhaustion, or single-core CPU saturation coinciding with HTML parse traffic. HTTP bodies are rarely retained, so charset-related request content is an opportunistic signal only. There are no associated C2 indicators, hashes, or named-actor TTPs.

What your security team should do

• Inventory all JRuby runtimes and transitive nokogiri versions; treat anything below 1.13.4 as exposed.
• Upgrade nokogiri to 1.13.4 or later and redeploy; do not rely on libxml2-only updates.
• Gate CI and production with an SCA policy that fails nokogiri < 1.13.4.
• Put request timeouts, body-size limits, and CPU/time quotas around every HTML parse of untrusted input.
• Review APM and JVM thread dumps for historical unbounded HTML-parse times even though this CVE is not KEV and has no known in-the-wild exploitation.