CVE-2026-54896

What it actually does

Oj versions before 3.17.2 contain a heap buffer overflow in object-mode serialization when Oj.dump serializes Exception objects with an excessively large indent option. The buffer allocation accounts for object attributes but not the repeated indent bytes written during serialization, allowing adjacent heap memory corruption. The most likely technical outcome is process instability or denial of service through Ruby process crashes; reliable code execution is not currently indicated by the published scoring or exploit maturity.

Why it matters to the business

Applications, background workers, API services, and automation that use the Oj Ruby gem may crash if an attacker or untrusted workflow can influence Oj.dump inputs or serialization options. Because Oj is commonly used for high-performance JSON handling in Ruby applications, affected deployments may experience service interruptions, failed jobs, degraded availability, or increased operational noise. Public exploitation is not currently known, EPSS is low, and the issue is not in CISA KEV, but remediation is still important for exposed services that deserialize or serialize untrusted data paths.

How an attack unfolds

An attacker first needs access to a code path that invokes Oj.dump in object mode and allows an Exception object, serialization options, or an indent value to be influenced. They then trigger serialization using a very large indent value, such as thousands of bytes. During serialization, Oj allocates a heap buffer based on the Exception object's attributes but repeatedly writes the large indent string without accounting for that additional memory. This overflows the heap allocation, corrupts neighboring memory, and can cause the Ruby process to crash. In a service context, repeated requests or jobs that trigger the vulnerable serialization path could produce a denial-of-service condition.

How to fix it

Upgrade the Oj Ruby gem to version 3.17.2 or later wherever it is used. Regenerate and redeploy dependency lockfiles after updating, and ensure all application images, worker containers, serverless packages, and CI-built artifacts include the fixed gem version. If immediate upgrade is not possible, avoid Oj object mode for untrusted data paths, do not serialize Exception objects with user-controlled options, reject or clamp large indent values to a small safe maximum, and ensure serialization options are not accepted directly from request parameters, job payloads, or external configuration.

How to confirm the fix worked

Confirm that dependency manifests and runtime environments report Oj version 3.17.2 or later. Check Gemfile.lock, gemspec files, container image SBOMs, deployed bundle output, and runtime gem inventories for oj versions below 3.17.2. Exercise representative serialization paths after upgrade, especially error serialization and logging paths, to confirm normal behavior. For mitigation validation, verify that large indent values are rejected or normalized before reaching Oj.dump and that object mode is not used for untrusted serialization workflows.

Typical attack path

1. Identify a Ruby application, API endpoint, job processor, or internal tool that uses the Oj gem for JSON serialization.
2. Determine whether the application uses Oj object mode or permits caller-controlled serialization options.
3. Find a path where an Exception object or error object is serialized with Oj.dump.
4. Supply or influence a large indent value, such as approximately 5000 bytes or more.
5. Trigger the vulnerable serialization operation.
6. Cause heap corruption and likely crash the Ruby process, worker, or service.
7. Repeat the trigger to maintain service disruption if supervisors automatically restart the process.

How to detect it

To determine whether exploitation may have already occurred, review application logs, process supervisor logs, container runtime logs, crash dumps, and host telemetry for Ruby process crashes correlated with JSON serialization, exception handling, or unusually large indent values. Focus on services using oj versions before 3.17.2 and on endpoints or jobs that accept formatting options, debug parameters, error payloads, or serialized exception objects. Look for segmentation faults, heap corruption messages, malloc/free errors, core dumps, repeated worker restarts, and request or job payloads containing very large indent values. If available, correlate HTTP access logs, background job arguments, APM traces, and exception logging pipelines to identify requests immediately preceding Ruby crashes. There are no known public threat actor campaigns or KEV activity for this issue at this time, so detection should emphasize anomaly and crash correlation rather than known attacker infrastructure.

• oj (3.17.1)
• oj (3.17.0)
• oj (3.16.
• Oj.dump
• mode: :object
• indent: 5000
• indent=>5000
• indent = 5000
• Segmentation fault
• segfault at
• core dumped
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid pointer
• double free or corruption
• ruby crashed
• /var/lib/systemd/coredump/
• core.ruby
• bundle exec ruby

What your security team should do

• Inventory Ruby applications, worker services, and container images that include the oj gem.
• Prioritize upgrade to oj 3.17.2 or later for internet-facing applications, API services, and job processors that handle untrusted input.
• Search code for Oj.dump usage with mode: :object, object mode defaults, Exception serialization, and caller-controlled indent options.
• Add input validation or hard-coded serialization options so external users cannot control Oj indent values.
• Review recent crash telemetry for Ruby segmentation faults, heap corruption, abnormal worker exits, and repeated restarts around JSON serialization or exception handling paths.
• Add dependency scanning gates to block oj versions earlier than 3.17.2 in new builds.
• If vulnerable paths are found, perform targeted log review for repeated requests or jobs that correlate with Ruby crashes or unusually large indent parameters.