CVE-2026-54900

What it actually does

Oj versions prior to 3.17.2 contain a heap corruption flaw in the Ruby gem's usual parsing mode when create_id is enabled. If Oj::Parser#parse processes a JSON object containing a key exactly 65,535 bytes long, an integer truncation in form_attr converts the key length to -1 before it is passed to memcpy. memcpy then interprets that value as a very large unsigned size and attempts an oversized copy, corrupting heap memory and typically crashing the Ruby process. Based on the published scoring, the expected impact is availability loss rather than confirmed data disclosure or code execution, and exploitation requires the vulnerable Oj configuration to be reachable through attacker-controlled JSON input.

Why it matters to the business

Applications that accept untrusted JSON and parse it with vulnerable Oj settings can be remotely crashed by a specially crafted request, causing service disruption, failed transactions, job-processing failures, or degraded API availability. The current exploitation signal is low: EPSS is 0.00253, it is not listed in CISA KEV, no ransomware use is reported, and exploit maturity is listed as none. However, Oj is commonly used in Ruby application stacks, so organizations should still prioritize inventory and upgrades where internet-facing services or message-processing systems parse external JSON.

How an attack unfolds

An attacker first identifies an application endpoint, webhook, API, queue consumer, or file-import workflow that accepts JSON controlled by the attacker. Exploitation is only viable when that code path uses the Oj Ruby gem before version 3.17.2, runs in usual mode, and has create_id enabled. The attacker sends a JSON object containing a property name that is exactly 65,535 bytes long. During parsing, Oj's form_attr logic truncates the key length into a negative value and passes it to memcpy, which treats it as an extremely large size. The attempted copy corrupts heap memory and usually terminates the Ruby worker, web process, or background job process. Repeated requests can cause a denial of service by continuously crashing vulnerable workers or forcing process supervisors to restart them.

How to fix it

Upgrade the Oj Ruby gem to version 3.17.2 or later everywhere it is used. Review Gemfile.lock, gemspecs, container images, vendored gems, and CI build artifacts to ensure no vulnerable Oj version remains. If immediate upgrade is not possible, reduce exposure by disabling create_id where it is not required, avoiding usual mode for untrusted JSON where feasible, enforcing maximum JSON key lengths well below 65,535 bytes, applying request body and field-name limits at the application or proxy layer, and isolating JSON-processing workers so crashes do not take down unrelated services. Restart affected application processes after upgrading so the patched native extension is loaded.

How to confirm the fix worked

Confirm the installed Oj version is 3.17.2 or later using dependency manifests and runtime checks such as `bundle list | grep oj`, `bundle exec ruby -roj -e 'puts Oj::VERSION'`, or equivalent build inventory tooling. Verify deployed containers and hosts use the rebuilt artifact rather than an older cached native gem. Review application configuration and code paths for `Oj.default_options`, `Oj.load`, `Oj::Parser`, `mode: :usual`, and `create_id` settings to confirm untrusted JSON is no longer parsed with the vulnerable combination. Where safe, use a non-production regression test that submits JSON with oversized key names and confirms the service rejects the request gracefully instead of crashing. Validate that reverse proxies, API gateways, or application middleware enforce practical JSON field-name and request-size limits.

Typical attack path

1. Find a JSON-ingesting endpoint, webhook, API, background job, or import path exposed to untrusted input.
2. Confirm or infer that the target application uses the Oj Ruby gem for JSON parsing or object marshalling.
3. Reach a vulnerable code path using Oj prior to 3.17.2 in usual mode with create_id enabled.
4. Submit a JSON object whose key name is exactly 65,535 bytes long.
5. Trigger integer truncation inside Oj's form_attr handling and an oversized memcpy operation.
6. Cause heap corruption and crash the Ruby process handling the request or job.
7. Repeat the request to create sustained application unavailability if process restarts are automatic.

How to detect it

Look for evidence of sudden Ruby application crashes correlated with JSON requests, webhook deliveries, API calls, import jobs, or queue messages containing unusually long object keys. Relevant sources include application logs, web server and reverse proxy access logs, API gateway logs, background worker logs, container runtime events, process supervisor logs, system journal logs, crash dumps, and core files. Focus on crashes occurring immediately after HTTP requests with JSON content types, large request bodies, 400/500-series responses, worker restarts, or aborted Ruby processes. If full request capture or WAF logs are available, search for JSON object member names with lengths near exactly 65,535 bytes. On Linux systems, investigate messages such as segmentation faults, aborts, glibc heap corruption errors, and Ruby native-extension crashes involving Oj. Absence of logs does not rule out exploitation, because the process may terminate before application-level logging occurs.

• Oj::Parser#parse
• Oj.load
• Oj::VERSION
• mode: :usual
• create_id
• usual.c:63
• form_attr
• Segmentation fault
• Aborted (core dumped)
• malloc(): corrupted top size
• malloc(): memory corruption
• free(): invalid next size
• corrupted size vs. prev_size
• double free or corruption
• Content-Type: application/json
• worker restart
• process exited with status 134
• process exited with status 139
• Gemfile.lock: oj
• oj (3.17.1)
• oj (3.17.0)

What your security team should do

• Inventory all Ruby applications, containers, gems, and build pipelines for Oj versions earlier than 3.17.2.
• Prioritize remediation for internet-facing APIs, webhook receivers, file importers, and queue consumers that parse untrusted JSON.
• Upgrade Oj to 3.17.2 or later and redeploy/restart all affected services.
• If patching is delayed, enforce JSON key-length limits and request-size limits at application and edge layers.
• Search code and configuration for use of usual mode and create_id, and disable create_id where object creation from JSON is not explicitly required.
• Monitor Ruby process crashes, worker restarts, segmentation faults, and heap-corruption messages after JSON requests.
• Add regression tests for long JSON object keys to ensure malformed input is rejected without process termination.
• Because EPSS is low and there is no KEV listing or known mature exploit, treat this as a targeted availability-risk patch rather than an emergency mass-exploitation event unless exposed critical services are affected.