CVE-2026-54903

What it actually does

Oj versions prior to 3.17.2 contain an integer overflow in the JSON string-buffer append path used by Oj.load. When parsing a JSON string longer than 2 GB, the vulnerable length calculation can wrap and be interpreted as an extremely large size_t, causing memcpy to read and write out of bounds. The expected practical impact is process crash and possible adjacent heap corruption, resulting primarily in denial of service for Ruby applications that parse attacker-controlled JSON with Oj.load. The provided CVSS indicates network reachability, low attack complexity, no authentication, and low availability impact, with no stated confidentiality or integrity impact.

Why it matters to the business

Applications or services that accept large, attacker-controlled JSON payloads and process them with vulnerable Oj versions can be crashed remotely, causing service interruptions, worker restarts, failed API requests, degraded job processing, or resource exhaustion. Because the attack requires sending a JSON string over 2 GB, exploitation is constrained by request-size limits, proxies, load balancers, application servers, and memory capacity; however, services that permit very large uploads, streaming JSON, bulk imports, or background ingestion may be exposed. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported exploit maturity, so urgency is lower than actively exploited flaws but remediation is still recommended for internet-facing or high-availability Ruby services.

How an attack unfolds

An attacker identifies a Ruby application endpoint, API, import feature, queue consumer, webhook receiver, or file-processing workflow that passes attacker-controlled JSON to Oj.load using an Oj version earlier than 3.17.2. The attacker submits or causes ingestion of a JSON document containing a single string value longer than 2 GB. If upstream infrastructure allows the payload and the application attempts to parse it, Oj reaches buf_append_string, overflows the length calculation, and calls memcpy with an invalid, astronomically large copy size. This causes out-of-bounds memory access, usually terminating the Ruby process and potentially corrupting nearby heap memory before the crash. In a production deployment this may manifest as repeated worker crashes, container restarts, failed requests, or service unavailability. There is no public evidence in the supplied data of reliable code execution, named threat actor exploitation, or ransomware use.

How to fix it

Upgrade the Oj Ruby gem to version 3.17.2 or later wherever it is used. Rebuild and redeploy application images, lockfiles, and dependency bundles so production runtimes actually load the fixed gem. If immediate upgrade is not possible, reduce exposure by enforcing strict maximum request, upload, message, and file sizes well below 2 GB at every layer: CDN, WAF, reverse proxy, application server, API gateway, background job ingestion, and application validation. Avoid using Oj.load on untrusted input unless required; prefer safer parsing modes and schema validation where applicable. Ensure large malformed payloads are rejected before reaching the JSON parser, and disable automatic retries for poison messages that repeatedly crash workers.

How to confirm the fix worked

Confirm dependency inventories, Gemfile.lock, bundled gems, container images, and runtime package paths show Oj 3.17.2 or later. Run `bundle list | grep oj`, `bundle info oj`, or equivalent software composition analysis tooling against built artifacts, not only source repositories. Verify that external and internal ingestion paths enforce maximum body, upload, file, and queue-message sizes below the vulnerable threshold. Test representative endpoints with oversized but safe payloads that exceed configured limits and confirm they are rejected before application parsing. Monitor deployment logs to ensure application workers are running the updated artifact and no older containers or hosts continue to load vulnerable Oj versions.

Typical attack path

1. Find a Ruby service or processing workflow that accepts JSON from unauthenticated or low-trust users.
2. Confirm that large request bodies, uploads, imports, or queued JSON messages are accepted without strict size limits below 2 GB.
3. Craft a JSON document containing a string value longer than 2 GB.
4. Submit the payload to an endpoint or ingestion path that parses the data with Oj.load on an Oj version prior to 3.17.2.
5. Trigger the integer overflow and oversized memcpy operation during parsing.
6. Cause the Ruby process, worker, job consumer, or container to crash, potentially repeatedly if the payload is retried or reprocessed.

How to detect it

Look for evidence of attempted or successful denial-of-service exploitation through very large JSON inputs followed by Ruby process crashes. Relevant sources include CDN/WAF/access logs, reverse proxy logs, application server logs, API gateway logs, upload/import service logs, message broker logs, container orchestration events, Ruby exception/crash logs, system logs, and APM traces. Search for requests or messages with Content-Type values such as application/json and body, upload, or message sizes approaching or exceeding 2 GB, especially if followed by 5xx responses, connection resets, worker exits, segmentation faults, aborts, out-of-memory events, or container restarts. In application and system logs, correlate crashes of Ruby, Puma, Unicorn, Passenger, Sidekiq, Resque, Delayed Job, or custom job consumers with unusually large JSON payloads or repeated retries of the same message/file. Because the vulnerability is a native memory corruption crash, there may be no Ruby exception stack trace; OS-level signals such as SIGSEGV, SIGABRT, core dumps, and Kubernetes CrashLoopBackOff events are important artifacts. No named threat actors, malware artifacts, or stable exploit-specific network signatures are provided, so detection should focus on payload size anomalies and crash correlation.

• Content-Type: application/json
• Content-Length: 2147483648
• Content-Length: 2147483649
• Content-Length: 2147483647
• Oj.load
• buf_append_string
• memcpy
• Segmentation fault
• SIGSEGV
• SIGABRT
• core dumped
• CrashLoopBackOff
• OOMKilled
• puma
• unicorn
• passenger
• sidekiq
• resque
• delayed_job
• /usr/local/bundle/gems/oj-3.17.1
• /usr/local/bundle/gems/oj-3.17.0
• /usr/local/bundle/gems/oj-3.16
• /usr/local/bundle/gems/oj-3.15
• /usr/local/bundle/gems/oj-3.14

What your security team should do

• Inventory all Ruby applications, services, containers, serverless functions, and background workers that include the Oj gem.
• Prioritize upgrading internet-facing APIs, upload/import services, webhook receivers, and queue consumers that parse untrusted JSON.
• Update Oj to 3.17.2 or later and redeploy all affected runtime artifacts.
• Enforce defense-in-depth payload-size limits at gateways, proxies, application servers, queues, and application code, keeping limits well below 2 GB.
• Review places where Oj.load is used on untrusted data and replace with safer parsing patterns or add schema and size validation.
• Add monitoring for unusually large JSON requests, uploads, queue messages, repeated Ruby worker crashes, and container restart loops.
• Because this is not KEV-listed, has low EPSS, and has no known exploit maturity in the supplied data, schedule remediation according to normal dependency security SLAs unless exposed services accept very large untrusted JSON, in which case treat as high operational risk.