EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
yajl-rubyReal-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
NOTE: A previous patch, 1.4.2, fixed the heap memory issue, but could still lead to a DoS infinite loop. Please update to version 1.4.3
The 1.x branch and the 2.x branch of yajl contain an integer overflow which leads to subsequent heap memory corruption when dealing with large (~2GB) inputs.
Details
The reallocation logic at yajl_buf.c#L64 may result in the need 32bit integer wrapping to 0 when need approaches a value of 0x80000000 (i.e. ~2GB of data), which results in a reallocation of buf->alloc into a small heap chunk.
These integers are declared as size_t in the 2.x branch of yajl, which practically prevents the issue from triggering on 64bit platforms, however this does not preclude this issue triggering on 32bit builds on which size_t is a 32bit integer.
Subsequent population of this under-allocated heap chunk is based on the original buffer size, leading to heap memory corruption.
Impact
We rate this as a moderate severity vulnerability which mostly impacts process availability as we believe exploitation for arbitrary code execution to be unlikely.
Patches
Patched in yajl-ruby 1.4.3
Workarounds
Avoid passing large inputs to YAJL
References
For more information
If you have any questions or comments about this advisory:
- Open an issue in yajl-ruby
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | yajl-ruby | all versions | 1.4.3 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for yajl-ruby. 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 yajl-ruby to 1.4.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jj47-x69x-mxrm 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-jj47-x69x-mxrm 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-jj47-x69x-mxrm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-jj47-x69x-mxrm in your dependencies?
O3 detects GHSA-jj47-x69x-mxrm across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.