CVE-2026-54899

What it actually does

Oj prior to 3.17.2 contains a heap use-after-free in the native Ruby extension when an Oj::Parser instance is reused and the symbol_keys option is changed from true to false. The option change frees the internal key cache but leaves a stale pointer, and the next parse operation can read from freed heap memory through cache_intern. In practical terms, affected applications may experience process crashes and limited memory disclosure; reliable code execution is not indicated by the supplied scoring or exploit maturity, but native memory-safety bugs should still be treated carefully.

Why it matters to the business

Applications that depend on vulnerable Oj versions may become unstable when processing JSON under the affected parser configuration, causing intermittent service errors, worker crashes, failed background jobs, or degraded API availability. The assessed exploitation likelihood is currently low, it is not listed in CISA KEV, and there is no reported ransomware use, but the issue has been public for 41 days and is in a commonly used Ruby parsing library, so organizations should remediate during normal vulnerability patch cycles or faster for internet-facing services that accept untrusted JSON.

How an attack unfolds

An attacker would need to reach application functionality that parses attacker-controlled JSON using a reused Oj::Parser instance that previously had symbol_keys enabled and is later switched to symbol_keys disabled. After that state transition, the parser retains a dangling pointer to a freed key cache. The attacker then submits JSON that causes the parser to intern or look up keys, triggering a read from freed heap memory. The most likely observable result is a Ruby process crash, segmentation fault, aborted worker, or malformed response; depending on allocator state and runtime behavior, limited disclosure of stale memory contents may also be possible. Exploitation is configuration-dependent because the vulnerable path requires parser reuse and option toggling rather than merely having the gem installed.

How to fix it

Upgrade Oj to version 3.17.2 or later everywhere it is used. For Bundler-managed Ruby applications, update the dependency constraint and lockfile, for example by running `bundle update oj`, then rebuild and redeploy application artifacts, containers, and background worker images. If immediate upgrade is not possible, avoid reusing Oj::Parser instances when parser options can change, do not toggle symbol_keys from true to false on an existing parser, instantiate a fresh parser for each option profile, and reduce exposure of affected endpoints to untrusted JSON where feasible. Treat mitigations as temporary because the defect is in native memory management and is fixed in the library release.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve Oj to 3.17.2 or newer, including Gemfile.lock, gemspec dependencies, vendored gems, container images, and deployed runtime environments. At runtime, verify with commands such as `bundle exec ruby -roj -e 'puts Oj::VERSION'` or `bundle list | grep oj`. Run application regression tests that cover JSON parsing paths and confirm no reused parser changes symbol_keys from true to false. For exposure assessment, use software composition analysis to find Oj versions below 3.17.2 and inspect code for `Oj::Parser` reuse combined with `symbol_keys` option changes. After remediation, confirm crash rates, worker restarts, and JSON parsing errors return to baseline.

Typical attack path

1. Identify a Ruby application or API endpoint that accepts JSON input and uses the Oj gem for parsing.
2. Find or trigger an application code path that reuses an Oj::Parser instance across parse operations.
3. Cause or wait for the parser configuration to transition from symbol_keys: true to symbol_keys: false.
4. Send crafted JSON containing object keys that exercise the parser key-cache path on the next parse call.
5. Observe process crashes, HTTP 5xx responses, worker restarts, or other instability that indicates the use-after-free was triggered.
6. Repeat requests to cause denial of service or attempt to infer limited memory exposure from abnormal parser behavior, if any is surfaced by the application.

How to detect it

There is no reliable network-only signature that proves exploitation because the trigger depends on application parser state and may look like ordinary JSON input. Review application, web server, process supervisor, container, and host logs for Ruby process crashes or segmentation faults occurring immediately after JSON requests. Correlate timestamps of crashes, worker restarts, core dumps, HTTP 500 responses, and JSON parse errors with access logs for endpoints accepting JSON bodies. On hosts or containers where core dumps are retained, inspect stack traces for Oj native extension frames, especially functions or symbols such as cache_intern, opt_symbol_keys_set, or cache_free. Check APM and orchestration telemetry for repeated restarts of Ruby web workers, job workers, or API processes. If available, review request samples immediately preceding crashes for repeated JSON object-key patterns or unusually high request repetition, but treat request content as supporting evidence rather than a definitive indicator.

• Oj::Parser
• symbol_keys
• cache_intern
• opt_symbol_keys_set
• cache_free
• [BUG] Segmentation fault
• Segmentation fault
• core dumped
• oj/oj.so
• oj.so
• bundle list | grep oj
• Oj::VERSION

What your security team should do

• Inventory all Ruby applications, services, jobs, and container images that include the Oj gem and identify versions below 3.17.2.
• Prioritize upgrades for internet-facing APIs, webhook receivers, file ingestion services, and background workers that parse untrusted JSON.
• Update Oj to 3.17.2 or later, regenerate lockfiles, rebuild immutable artifacts, and redeploy rather than only changing source manifests.
• Search code for reused `Oj::Parser` objects and any runtime toggling of `symbol_keys`; remove that pattern even after patching as a defensive coding improvement.
• Monitor application logs and crash telemetry for Ruby segmentation faults, native extension crashes, worker restarts, and spikes in HTTP 5xx responses around JSON parsing endpoints.
• Because EPSS is low, exploit maturity is listed as none, and the vulnerability is not in KEV, handle as a timely dependency patch rather than an emergency unless local exposure or instability is observed.