CVE-2026-54592: Oj Ruby Gem Buffer Overflow DoS

Affected Versions and Exposure Assessment

The affected product is the Oj Ruby gem, maintained by the Oj project. The published affected range is explicit: all versions prior to 3.17.3, commonly expressed as < 3.17.3. The fixed version is equally explicit: 3.17.3.

That version range matters for dependency management because Oj is often a transitive dependency or pinned indirectly in Ruby applications. Many teams know they use Rails, Sidekiq, Sinatra, or internal service frameworks, but do not always know which JSON gem versions are bundled into application images or lockfiles. If you operate Ruby workloads, check both direct dependencies in Gemfile.lock and built artifacts such as containers or packaged deployments.

Exposure depends on more than the installed version. You should prioritize systems that meet all of the following conditions: they run Oj below 3.17.3, they process attacker-influenced JSON, and they use Oj::Doc#each_child recursively or through application logic that leads to equivalent traversal behavior. If you cannot verify usage quickly, treat public-facing API services as higher risk than isolated internal jobs.

Because the available sources do not provide a full CVSS vector, network preconditions are not formally stated in the retrieved NVD response. Likewise, there is no authoritative vendor statement here on every framework or code path that could make the flaw reachable. In that uncertainty, defenders should assume realistic exploitability wherever user-controlled JSON meets vulnerable parsing code.

Exploitation Status and Risk Posture

At the time of writing, there is no confirmed evidence from the retrieved sources that exploitation is occurring in the wild. The vulnerability is not listed in CISA KEV based on the research note provided. That lowers immediate pressure compared with mass-exploited edge-device flaws, but it should not be read as a reason to defer patching indefinitely.

There is also no separate public proof-of-concept repository identified in the provided source set. However, the public vulnerability description is technically detailed. It explains the faulty pointer handling, the missing state restoration, and the overflow condition. That means a motivated researcher or attacker likely does not need much additional information to reproduce a crash in a lab environment.

For prioritization, this lands in the middle ground: no confirmed active exploitation, no known public PoC from the provided references, but enough implementation detail to expect reproduction is feasible. If your application is exposed to arbitrary JSON from customers, third parties, webhooks, or message queues, patching should still be treated as near-term operational work, not backlog cleanup.

Defenders should also keep in mind that denial-of-service vulnerabilities are often underreported operationally. An attacker does not need persistence or stealth if repeatedly crashing a service is enough to degrade business function. If your environment depends on worker autoscaling or retries, even a “simple crash” can become an expensive reliability incident.

Technical Impact and Root Cause

The root cause described in public records is a logic error in ext/oj/fast.c. In brief, doc_each_child increments an internal pointer, doc->where, without sufficient bounds checking against where_path[MAX_STACK = 100]. It also fails to restore that pointer correctly because a corresponding decrement is missing. Later, the code calculates a path length and copies it into a fixed-size stack buffer.

That sequence matters because the bug is not just “deep nesting is bad.” The advisory describes a two-step chain: internal traversal state moves past the intended bounds, and on a later entry the computed length exceeds the fixed-size local buffer. The result is a stack buffer overflow into save_path[MAX_STACK], causing process abort. The parser itself also does not impose a JSON nesting-depth limit according to the description, which helps attacker-controlled deeply nested input reach the vulnerable path.

Technical Notes

The available public explanation describes the vulnerable behavior in terms of native code state management:

// Conceptual summary from the public description, not a full source listing.
doc_each_child(...){
    doc->where++;              // incremented
    // missing effective bounds enforcement here
    // ...
    wlen = doc->where - doc->where_path;
    memcpy(save_path, doc->where_path, wlen * sizeof(...)); // overflows when wlen > MAX_STACK
    // missing doc->where-- restoration in the vulnerable path
}

The reported fix behavior for Oj 3.17.3 is that traversal now bounds-checks before incrementing doc->where, raises Oj::DepthError when depth would exceed limits, and restores doc->where after traversal. That change blocks the invalid internal state that enables the overflow.

What Defenders Should Do Next

First, identify every Ruby application, background worker, and container that includes Oj < 3.17.3. This should be a dependency inventory exercise, not just a source repository review. In many environments, the biggest gap is between “we updated the Gemfile” and “the running image actually contains the fixed gem.”

Second, prioritize internet-facing services and integration points that accept JSON from customers or third parties. If those services are high-availability systems, include SRE or platform teams in the response so restart loops, crash alerts, and autoscaling behavior are monitored during the patch window. Do not wait for public exploitation confirmation before taking action if your service availability matters.

Third, review code for Oj::Doc and recursive each_child usage. Even after patching, this review is useful because it highlights parsing pathways that deserve better validation, safer traversal limits, and more robust resilience testing with malformed or extreme inputs.