GHSA-2qc6-mcvw-92cw

What it actually does

Nokogiri versions before 1.13.9 bundle a vulnerable libxml2 version affected by multiple memory-corruption flaws. Applications that parse attacker-controlled XML, HTML, XHTML, SVG, SOAP, RSS, or other markup through Nokogiri may trigger invalid memory access in libxml2 during parsing, entity handling, tree manipulation, or related XML processing. The most likely outcomes are process crashes and denial of service; depending on the specific libxml2 flaw, runtime protections, architecture, and parser usage, more severe outcomes such as memory disclosure or code execution may be possible.

Why it matters to the business

Services that accept or process untrusted markup can be destabilized by crafted input, causing application crashes, failed background jobs, degraded availability, or repeated restarts. Because Nokogiri is widely used in Ruby applications for web scraping, API processing, document ingestion, feed parsing, and test tooling, exposure can exist both in internet-facing request paths and internal processing pipelines. This advisory is older and is not listed in CISA KEV, with no known mature public exploitation indicated in the provided data, but remediation remains important because the affected library is commonly embedded in applications and may be reachable through many file-upload or data-ingestion features.

How an attack unfolds

An attacker first identifies an application feature that parses markup using Nokogiri, such as XML API input, uploaded documents, SVG images, feeds, SOAP messages, HTML sanitization, or background ingestion of third-party content. The attacker then sends specially crafted malformed markup designed to exercise vulnerable libxml2 parsing behavior bundled with older Nokogiri releases. When the application parses the payload, libxml2 may corrupt memory or access invalid memory, causing the Ruby process, worker, or service container to crash. In a denial-of-service scenario, the attacker repeats requests or submits multiple queued payloads to keep workers failing. In more severe scenarios, successful exploitation would require shaping memory layout and bypassing platform mitigations to gain stronger impact, which is generally more difficult and no mature exploitation is indicated by the provided data.

How to fix it

Upgrade Nokogiri to version 1.13.9 or later for RubyGems deployments. Regenerate and redeploy dependency locks so runtime artifacts actually use the fixed gem version. If Nokogiri is built against system libraries rather than the packaged native libraries, also ensure the system libxml2 package is updated to a vendor-fixed release that includes libxml2 2.10.3 security fixes or equivalent backports. Rebuild containers, application images, and native extensions after upgrading. As interim risk reduction, avoid parsing untrusted markup where possible, reject unexpectedly large or malformed XML/HTML/SVG inputs, disable unnecessary XML features, enforce request and file-size limits, run parsers in least-privileged isolated workers, and apply rate limits to ingestion endpoints.

How to confirm the fix worked

Confirm dependency state by checking Gemfile.lock, bundle info nokogiri, gem list nokogiri, or runtime version output from Nokogiri::VERSION. The fixed RubyGems version is nokogiri 1.13.9 or later. For native linkage validation, check Nokogiri::LIBXML_COMPILED_VERSION and Nokogiri::LIBXML_LOADED_VERSION, and verify the compiled and loaded libxml2 versions are 2.10.3 or a distribution-backported fixed build. In containerized deployments, scan the final runtime image rather than only the source repository. Exercise representative XML/HTML/SVG parsing paths after upgrade to confirm there are no compatibility regressions, and verify old application pods, workers, or build artifacts using vulnerable Nokogiri versions have been removed from service.

Typical attack path

1. Find an endpoint, job, importer, webhook, or file-processing workflow that accepts XML, HTML, SVG, SOAP, RSS, or similar markup.
2. Confirm or infer that the application parses the content with Nokogiri linked to bundled libxml2 before version 2.10.3.
3. Create malformed markup targeting libxml2 parser edge cases fixed in Nokogiri 1.13.9.
4. Submit the payload through the reachable application feature or place it where an ingestion worker will process it.
5. Trigger memory corruption during parsing, typically causing a crash, exception storm, worker restart, or service degradation.
6. Repeat delivery to sustain denial of service or attempt more advanced exploitation if the vulnerable process is reachable and memory layout can be influenced.

How to detect it

Retrospective detection is difficult because exploitation may leave only application-level crash or parser-error artifacts rather than a durable host indicator. Review web access logs, API gateway logs, upload logs, job queue logs, application logs, container restart events, process supervisor logs, and crash dumps for unusual spikes around XML, HTML, SVG, SOAP, RSS, or feed-processing routes. Look for repeated requests or uploaded files immediately preceding Ruby worker crashes, segmentation faults, core dumps, container restarts, or libxml2/Nokogiri stack traces. Preserve and inspect suspicious submitted documents for malformed XML structures, extreme nesting, unusual encodings, oversized attributes, entity-heavy content, or parser edge cases. Correlate source IPs, user accounts, API tokens, or automation clients that repeatedly trigger parsing failures. Host forensics should focus on evidence of abnormal Ruby process termination and unexpected child processes; successful code execution is not indicated by the provided data, but any parser crash followed by suspicious process execution, outbound connections, or file writes should be treated as a potential compromise.

• nokogiri
• Nokogiri::XML
• Nokogiri::HTML
• libxml2
• libxml2.so
• xmlParse
• Segmentation fault
• SIGSEGV
• core dumped
• Nokogiri::XML::SyntaxError
• Nokogiri::VERSION
• LIBXML_LOADED_VERSION
• /usr/local/bundle/gems/nokogiri-1.13.
• /usr/local/lib/ruby/gems/*/gems/nokogiri-1.13.
• Gemfile.lock: nokogiri (1.13.
• bundle info nokogiri

What your security team should do

• Inventory Ruby applications, containers, CI jobs, and background workers that include the nokogiri gem, prioritizing internet-facing services and ingestion pipelines that parse untrusted markup.
• Upgrade all affected deployments to nokogiri 1.13.9 or later and rebuild native extensions and container images to eliminate stale vulnerable binaries.
• For applications compiled against system libxml2, verify operating-system packages include the libxml2 2.10.3 fixes or vendor backports, not merely an updated Ruby gem declaration.
• Add software composition analysis checks to block nokogiri versions before 1.13.9 in dependency manifests and built artifacts.
• Review XML/HTML/SVG parsing entry points and ensure untrusted parsing is constrained with file-size limits, timeouts, isolation, and least privilege.
• Monitor application error, crash, and restart telemetry for parsing-related failures that may indicate probing or attempted denial of service.
• Because no KEV listing or mature exploit is indicated, prioritize based on exposure: externally reachable parsers and automated document ingestion should be remediated first.