CVE-2026-54903 — oj
CVE-2026-54903 is a CWE-190 vulnerability in oj. A fix is available for oj — see the affected versions and patch details below.
Oj: Integer Overflow in Oj.load 2GB String Handling
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-54903.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
ojReal-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
Oj.load is vulnerable to heap corruption when parsing a JSON string longer than 2 GB. An integer overflow in buf_append_string (buf.h:61) converts the string length to a large negative size_t, causing memcpy to copy an astronomically large amount of data out of bounds. This crashes the process and can corrupt adjacent heap memory.
Version
- Software: oj gem
- Affected: all versions with
ext/oj/buf.handext/oj/parse.c - Latest tested: 3.17.1 (confirmed present)
Details
ext/oj/buf.h, line 61:
inline static void buf_append_string(Buf buf, const char *s, size_t slen) {
// ...
memcpy(buf->tail, s, slen); // slen derived from 32-bit int that wrapped negative
In parse.c, escape sequence handling computes the remaining string length as an int:
// parse.c:402 (read_escaped_str)
int slen = (int)(s - str); // ← wraps to negative when string > 2 GB
buf_append_string(buf, str, (size_t)slen); // ← (size_t)(-2147483648) = 0x80000000...
ASAN report:
==399019==ERROR: AddressSanitizer: negative-size-param: (size=-2147483648)
#0 __asan_memcpy
#1 buf_append_string /ext/oj/buf.h:61
#2 read_escaped_str /ext/oj/parse.c:402
#3 read_str /ext/oj/parse.c:542
#4 oj_parse2 /ext/oj/parse.c:882
#5 oj_pi_parse /ext/oj/parse.c:1256
#6 oj_object_parse /ext/oj/object.c:701
#7 load /ext/oj/oj.c:1259
0x7f5a26ff0801 is located 1 bytes inside of 2147483657-byte region [0x7f5a26ff0800, 0x7f5aa6ff0809)
Reproduce
require 'oj'
n = 1 << 31 # 2 GB
json = '"' + ('A' * n) + 'A"' # >2GB JSON string with a trailing escape
Oj.load(json)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | oj | all versions | 3.17.3bundle update oj --conservative |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for oj, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update oj to 3.17.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-54903 is resolved across your whole dependency graph.
Workarounds
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Frequently Asked Questions
Is CVE-2026-54903 in your dependencies?
Find it across RubyGems, including transitive dependencies.