Cloudanix VulnDB

GHSA-v2fc-qm4h-8hqv

Medium · 5.3

Nokogiri XSLT transform has a memory leak

CVSS

5.3

EPSS

—

Published

May 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in a common Ruby XML processing library can let repeated malformed input slowly exhaust memory and make affected services unavailable.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
Library
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This advisory describes a denial-of-service weakness in Nokogiri's XSLT transformation path. When `Nokogiri::XSLT::Stylesheet#transform` receives a Ruby string parameter containing a null byte, Nokogiri leaks a small heap allocation. A single request is unlikely to cause immediate failure, but repeated transformations with attacker-controlled null-byte-containing parameters can steadily consume process memory. The impact is most relevant to long-running Ruby processes, such as web application workers, background job processors, API services, or document-processing services that accept untrusted input and pass it into XSLT transform parameters.

Why it matters to the business

Applications that use Nokogiri for XSLT processing may become slow, unstable, or unavailable if an attacker repeatedly submits crafted input that causes memory growth. The primary business risk is service degradation or outage in affected Ruby services, especially long-running processes exposed to internet traffic or untrusted document/XML transformation workflows. There is no indication from the provided data that this issue is in CISA KEV, used in ransomware campaigns, or has mature public exploitation, so urgency should be risk-based and focused on systems that pass user-controlled values into XSLT transforms.

How an attack unfolds

An attacker first identifies an application feature that performs XSLT transformations using Nokogiri and allows user-controlled values to be supplied as transform parameters. The attacker then submits repeated requests containing string parameters with embedded null bytes. Each affected call to `Nokogiri::XSLT::Stylesheet#transform` leaks a small amount of heap memory. Over time, especially against persistent application workers or background processors, memory consumption increases until the process slows, is killed by the operating system or container runtime, restarts repeatedly, or becomes unable to serve legitimate traffic. Exploitation does not require code execution; it relies on repeatedly exercising the vulnerable transformation path with crafted input.

How to fix it

Upgrade Nokogiri to a version that contains the upstream fix for this advisory when available through the project's package manager channel. Because no fixed versions were provided in the input, verify the corrected version from the official Nokogiri advisory, RubyGems release notes, or the relevant distribution/package maintainer before deployment. As compensating controls, avoid passing attacker-controlled strings directly into `Nokogiri::XSLT::Stylesheet#transform` parameters, reject or sanitize null bytes in XSLT parameter values, impose request size and rate limits on transformation endpoints, use process memory limits with safe worker recycling, and isolate document-transformation workloads from critical application paths.

How to confirm the fix worked

Confirm exposure by inventorying Ruby applications and dependencies for Nokogiri usage, then review code paths for calls to `Nokogiri::XSLT::Stylesheet#transform` where transform parameters can include user-controlled strings. Validate remediation by confirming the deployed Nokogiri package version includes the upstream fix and by testing that null-byte-containing transform parameters no longer cause sustained memory growth. Operationally, monitor Ruby process resident memory over repeated XSLT transform calls, verify workers remain stable under malformed-input tests, and confirm application-layer validation rejects embedded null bytes where those values are not required.

Typical attack path

  1. Discover an application endpoint, job, or import feature that performs XSLT transformations using Nokogiri.
  2. Determine whether attacker-controlled input is passed as a parameter to `Nokogiri::XSLT::Stylesheet#transform`.
  3. Send crafted parameter values containing embedded null bytes.
  4. Repeat requests or jobs at sufficient volume to accumulate leaked heap allocations.
  5. Cause memory growth in long-running Ruby processes.
  6. Trigger degraded performance, worker crashes, container restarts, or service unavailability.

How to detect it

To assess possible prior exploitation, review application, web server, reverse proxy, and background job logs for repeated requests or jobs reaching XSLT transformation functionality with parameters containing encoded or raw null bytes. Useful log sources include Rails or Rack application logs, API gateway logs, reverse proxy access logs, WAF events, background worker logs, container runtime events, kernel or orchestrator OOM-kill events, and APM memory telemetry. Look for correlated patterns: repeated malformed XML/XSLT transformation attempts, parameter values containing `%00`, `\x00`, `\u0000`, or null-byte decoding errors, sustained growth in Ruby process memory, worker restarts, out-of-memory kills, and spikes in requests to document-conversion or XML-transformation endpoints. Because this issue causes resource exhaustion rather than code execution, indicators are more likely to be behavioral than file- or process-based.

  • %00
  • \x00
  • \u0000
  • Nokogiri::XSLT::Stylesheet#transform
  • XSLT.transform
  • Nokogiri::XSLT
  • out of memory
  • OOMKilled
  • Killed process
  • Cannot allocate memory
  • SignalException: SIGKILL
  • worker restart
  • Memory limit exceeded

What your security team should do

  • Inventory Ruby services, APIs, background workers, and document-processing pipelines that use Nokogiri XSLT transformations.
  • Prioritize remediation for internet-facing or untrusted-input workflows that pass user-controlled values into `Nokogiri::XSLT::Stylesheet#transform`.
  • Upgrade Nokogiri to a fixed release once confirmed from official Nokogiri or package-maintainer sources.
  • Add input validation to reject embedded null bytes in XSLT transform parameters unless explicitly required and safely handled.
  • Apply rate limiting, request size limits, worker memory limits, and controlled worker recycling around XSLT transformation workloads.
  • Monitor Ruby worker memory trends and restart/crash patterns for signs of repeated malformed transformation attempts.
  • Add tests covering null-byte-containing XSLT parameters to prevent regression in application-level validation.

The record

Nokogiri's `Nokogiri::XSLT::Stylesheet#transform` leaks a small heap allocation when passed a Ruby string parameter containing a null byte. For applications that pass attacker-controlled input through `XSLT.transform` parameters, this may be a vector for a denial of service attack against long-running processes.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities