CVE-2026-54500: Oj Ruby Gem Memory Leak via Long JSON Keys

Technical summary

CVE-2026-54500 is a memory-disclosure vulnerability in Oj's :object mode JSON parsing. The root cause lies in ext/oj/intern.c's form_attr() function, which handles long attribute names by allocating a temporary heap buffer but then passes an uninitialized stack buffer (buf, 256 bytes) to rb_intern3() instead of the populated heap buffer. This causes rb_intern3() to read len + 1 bytes of uninitialized stack memory. When key length exceeds 256 bytes, the function reads beyond buf's bounds entirely. The leaked bytes are subsequently interned as Ruby Symbols or embedded in EncodingError exception messages, making them observable by the caller. Affected CWE classifications are CWE-125 (Out-of-bounds Read) and CWE-908 (Use of Uninitialized Resource).

Business impact

Organizations running applications that parse JSON with Oj are exposed to information disclosure. If untrusted users can submit JSON payloads (e.g., via an API, form submission, or message queue), an attacker can extract fragments of process memory—potentially including secrets, authentication tokens, or other sensitive data resident on the stack. The leaked information becomes embedded in Symbol interning or error messages, making it accessible to the attacker. In multi-tenant environments or cloud deployments, this could leak cross-tenant data. The impact is limited to confidentiality; the vulnerability does not enable code execution, denial of service, or data modification.

Affected systems

Oj versions prior to 3.17.3 are vulnerable. Ruby applications that include Oj as a dependency and parse JSON in :object mode (the default marshalling mode) are at risk, particularly those accepting JSON input from untrusted sources. Applications that only parse JSON in other modes (e.g., :strict, :null, :json) or that exclusively parse trusted, internal JSON data face lower risk. Verify your Gemfile or gemspec to confirm which version of Oj you have installed and whether long keys are a realistic input vector in your use case.

Exploitability

Exploitability is straightforward: the vulnerability requires only network access and the ability to send a JSON object with a key ≥254 bytes to the target application. No authentication, user interaction, or complex setup is required. The CVSS 3.1 score of 5.3 (MEDIUM) reflects the low attack complexity and network accessibility, balanced against the confidentiality-only impact. However, the ease of triggering and deterministic nature of the leak make this a practical threat in any scenario where untrusted JSON input is processed.

Remediation

Upgrade Oj to version 3.17.3 or later. This version corrects form_attr() to pass the initialized heap buffer (b) to rb_intern3(), eliminating the uninitialized memory read. After patching, redeploy your Ruby application. If immediate patching is not possible, consider temporarily disabling JSON parsing of untrusted input or implementing a JSON key-length validation layer upstream to reject keys exceeding a reasonable threshold (e.g., 200 bytes).

Patch guidance

Update your Gemfile to require 'oj', '~> 3.17.3' or later, then run bundle update oj. Verify the new version with bundle list oj or by checking Gem::Specification.find_by_name('oj').version in a Rails console. Restart your application after updating. Test thoroughly in a staging environment to ensure no compatibility issues with your JSON parsing workflows. If you use Oj via a transitive dependency, trace the dependency tree (bundle show or bundler-audit) and ensure the parent gem also updates Oj or that you can pin Oj directly in your Gemfile.

Detection guidance

Monitor application logs for EncodingError or Symbol creation anomalies tied to JSON parsing. If Oj is instrumented with logging, look for repeated attempts to parse JSON with unusually long keys. Network-based detection is difficult because the payload is valid JSON; however, WAF rules or API gateway policies can flag requests with abnormally long JSON object keys (e.g., >1000 bytes). For forensic investigation, review process memory dumps or process stack traces around the time of suspected exploitation to identify leaked data. Enable Ruby's symbol_gc gem or monitor :Symbol objects for unexpected interning patterns if you suspect memory exfiltration.

Why prioritize this

Although classified as MEDIUM severity, this vulnerability warrants prompt attention because: (1) the attack surface is wide—any application parsing untrusted JSON is at risk; (2) exploitation is trivial and requires no special tools; (3) the leak exposes live process memory, which in modern applications often contains secrets, API keys, or user data; and (4) Ruby gems are frequently auto-updated or pinned transitively, potentially leaving applications behind. Prioritize patching for any services accepting external JSON input, especially APIs, webhooks, and data importers.

Risk score, explained

The CVSS 3.1 score of 5.3 is derived from: Network-accessible attack vector (AV:N), low attack complexity (AC:L), no privilege or user interaction required (PR:N, UI:N), and impact scoped to confidentiality only (C:L, I:N, A:N). The score correctly reflects the practical exploitability and low bar for triggering the leak, but should not minimize the risk of actual data exposure—leaked stack memory in production environments can contain high-value secrets. Organizations handling sensitive data should treat this as higher-priority than the numeric score alone suggests.

Frequently asked questions