How severe is GHSA-v2fc-qm4h-8hqv?

GHSA-v2fc-qm4h-8hqv has a CVSS score of 5.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-v2fc-qm4h-8hqv?

GHSA-v2fc-qm4h-8hqv affects the following packages: nokogiri (RubyGems). Ecosystems affected: RubyGems.

How do I fix GHSA-v2fc-qm4h-8hqv?

Update nokogiri to 1.19.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v2fc-qm4h-8hqv is resolved across your whole dependency graph.

How do I detect GHSA-v2fc-qm4h-8hqv in my RubyGems dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nokogiri. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-v2fc-qm4h-8hqv if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-v2fc-qm4h-8hqv?

O3 pinpoints whether GHSA-v2fc-qm4h-8hqv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-v2fc-qm4h-8hqv actively exploited in the wild?

No public exploit code has been indexed for GHSA-v2fc-qm4h-8hqv yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-v2fc-qm4h-8hqv published, and has it been updated?

GHSA-v2fc-qm4h-8hqv was published on May 6, 2026 and was last updated on May 9, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

💎 RubyGems

GHSA-v2fc-qm4h-8hqv

MEDIUM

Nokogiri XSLT transform has a memory leak

Published

May 6, 2026

Updated

May 9, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

💎nokogiri

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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.

Mitigation

Upgrade to Nokogiri >= 1.19.3.

Users may also be able to mitigate this issue without upgrading by validating untrusted transform parameters before passing them to Nokogiri::XSLT::Stylesheet#transform.

Severity

The Nokogiri maintainers have evaluated this as Moderate Severity, CVSS 5.3.

Each leaked allocation is approximately 24–32 bytes, so meaningful memory growth requires sustained attacker-controlled traffic at high call rates. The bug does not cause memory corruption, information disclosure, or any change in the behavior of the transform itself, and the string-handling exception is raised as expected.

Applications that do not pass raw attacker-controlled bytes to XSLT parameters are unlikely to be affected in practice.

Resources

CWE-401: Missing Release of Memory after Effective Lifetime

Credit

This vulnerability was responsibly reported by @Captainjack-kor.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
💎RubyGems	`nokogiri`	all versions	1.19.3

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nokogiri. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update nokogiri to 1.19.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v2fc-qm4h-8hqv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-v2fc-qm4h-8hqv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-v2fc-qm4h-8hqv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary 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. ## Mitigation Upgrade to Nokogiri `>= 1.19.3`. Users may also be able to mitigate this issue without upgrading by validating untrusted transform parameters before passing them to `Nokogiri::XSLT::Stylesheet#transform`. ## Severity The Nokogiri maintainers have evalu

O3 Security · Impact-Aware SCA

Is GHSA-v2fc-qm4h-8hqv in your dependencies?

O3 detects GHSA-v2fc-qm4h-8hqv across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works