CVE-2026-54901

What it actually does

CVE-2026-54901 is a use-after-free flaw in the Ruby Oj JSON parser before version 3.17.2. In Oj::Parser usual mode, references assigned through array_class or hash_class are not properly marked during Ruby garbage collection. If garbage collection runs after those class references are assigned but before parsing occurs, the class object can be reclaimed while the parser still holds a dangling Ruby VALUE. A subsequent parse operation can dereference freed memory and crash the Ruby process with a segmentation fault. Based on the published details and CVSS attributes, the practical impact is low availability impact/denial of service rather than confirmed arbitrary code execution.

Why it matters to the business

Applications or services that use vulnerable Oj versions to parse JSON may be remotely crashable if an attacker can send JSON to a code path that uses Oj::Parser in the affected configuration. This can cause request failures, worker restarts, degraded API availability, background job interruptions, and instability in Ruby services. The EPSS score is low, the issue is not listed in CISA KEV, and no mature public exploitation is reported, so urgency is moderate; however, internet-facing JSON APIs and high-availability Ruby services should still patch promptly because the fix is straightforward.

How an attack unfolds

An attacker first identifies a Ruby application that uses the Oj gem prior to 3.17.2 and exposes a JSON parsing path reachable over the network. Exploitation depends on the application using Oj::Parser in usual mode with array_class and/or hash_class configuration such that the parser retains class references. The attacker sends crafted or repeated JSON parse requests intended to reach the vulnerable parser state. If Ruby garbage collection runs after the class reference is assigned but before the parse operation, the parser may retain a dangling reference to a freed class object. When parsing subsequently occurs, Oj dereferences that freed object, causing the Ruby process to segfault. In typical deployments this results in denial of service through crashed web workers, API processes, or job processors; repeated requests may cause recurring process restarts or service instability.

How to fix it

Upgrade the Oj Ruby gem to version 3.17.2 or later. In Bundler-managed applications, update the Gemfile/Gemfile.lock and rebuild/redeploy all application images, containers, and hosts that include the vulnerable gem. If immediate upgrade is not possible, reduce exposure by limiting untrusted JSON input to affected parsing paths, avoiding Oj::Parser usual mode configurations that set array_class or hash_class where feasible, using an alternate JSON parser for untrusted input, enforcing request size/rate limits, and ensuring process supervisors restart crashed workers. Mitigations should be treated as temporary; the durable fix is upgrading Oj to 3.17.2 or newer.

How to confirm the fix worked

Confirm that all deployed Ruby runtimes, containers, build artifacts, and dependency locks resolve Oj to 3.17.2 or later. Use dependency inventory, software composition analysis, `bundle list`, `bundle info oj`, `bundle exec ruby -roj -e 'puts Oj::VERSION'`, or inspection of Gemfile.lock to verify the effective version at runtime. Validate that no older Oj versions remain in container layers, vendored gems, or packaged releases. After deployment, exercise JSON parsing endpoints and monitor for Ruby segmentation faults, worker restarts, and application crash loops. Where feasible, add regression tests around Oj::Parser configurations using array_class and hash_class to ensure parsing remains stable under forced garbage collection.

Typical attack path

1. Identify a Ruby application or service that uses the Oj gem for JSON parsing.
2. Confirm or infer that the deployed Oj version is earlier than 3.17.2.
3. Find a remotely reachable endpoint, API, webhook, or job ingestion path that parses attacker-controlled JSON using Oj::Parser usual mode.
4. Send JSON payloads or repeated requests that exercise parser creation and parse execution around Ruby garbage-collection timing.
5. Trigger the use-after-free condition when garbage collection reclaims an unmarked array_class or hash_class reference before parsing.
6. Cause the Ruby process to crash with a segmentation fault, resulting in denial of service or worker restarts.

How to detect it

To determine whether exploitation may already have occurred, review application logs, process supervisor logs, container orchestration events, host syslog/journal logs, APM crash reports, and core dump records for Ruby segmentation faults or sudden worker exits correlated with inbound JSON requests. Focus on crashes in Ruby web servers, API workers, background job processors, and services that use Oj. Look for repeated segfaults following HTTP requests with JSON content types, unusually high rates of malformed or repeated JSON submissions, crash loops, and stack traces referencing Oj::Parser, Oj parsing routines, array_class, or hash_class. Also review WAF, load balancer, reverse proxy, and API gateway logs for repeated requests to JSON-processing endpoints immediately before Ruby process crashes. Because published information does not describe a unique payload signature, detection should rely on crash artifacts plus temporal correlation to attacker-controlled JSON input rather than a single definitive network IOC.

• [BUG] Segmentation fault
• Segmentation fault
• segfault
• core dumped
• Oj::Parser
• Oj.parse
• array_class
• hash_class
• oj (3.17.1)
• oj (3.17.0)
• oj (3.16.
• /gems/oj-3.
• Content-Type: application/json

What your security team should do

• Inventory Ruby applications, containers, and services that include the Oj gem, prioritizing internet-facing APIs and services that parse untrusted JSON.
• Upgrade Oj to 3.17.2 or later across all affected builds and redeploy immutable artifacts rather than only updating source dependency files.
• Search dependency locks and runtime images for Oj versions earlier than 3.17.2, including transitive and vendored dependencies.
• Review application code for Oj::Parser usage in usual mode, especially configurations using array_class or hash_class with attacker-controlled JSON input.
• Monitor production logs and crash reporting for Ruby segmentation faults, worker restarts, crash loops, and Oj-related stack traces since publication.
• Apply rate limiting and request-size limits to JSON ingestion endpoints to reduce the ability to repeatedly trigger crashes before patching is complete.
• Because the issue is not KEV-listed, has low EPSS, and has no reported mature exploit, prioritize patching as a standard dependency security update unless the service is critical or externally exposed, in which case expedite.