Cloudanix VulnDB

CVE-2026-54502

None

CVSS

—

EPSS

0.3%

Published

Jul 1, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in a Ruby JSON library can let someone crash an application if the app allows them to supply an extremely large formatting value.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
Library
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

CVE-2026-54502 is a stack-based buffer overflow in the Ruby Oj JSON library before version 3.17.2. The vulnerable path is in Oj.dump when a caller supplies an extremely large :indent option. Internally, fill_indent in dump.h passes opts->indent to memset without validating that the requested indentation length fits the fixed-size stack buffer. A value such as INT_MAX causes memset to attempt to write roughly 2 GB of spaces into a stack buffer of about 4 KB, corrupting stack memory and crashing the Ruby process. Based on the published assessment, the practical impact is primarily availability loss rather than confirmed code execution, and exploitation requires application code to allow an attacker-controlled value to reach the Oj.dump :indent option.

Why it matters to the business

Applications that use Oj for JSON serialization can be crashed if they expose or derive the Oj.dump indentation setting from untrusted input. The most likely business consequence is denial of service: web workers, background jobs, API processes, or services using vulnerable Oj versions may terminate and cause errors, retries, degraded performance, or temporary service unavailability. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported exploit maturity, so broad opportunistic exploitation is less likely; however, any internet-facing feature that lets users influence JSON formatting options should be treated as higher risk.

How an attack unfolds

An attacker first identifies an application endpoint or workflow that serializes data using the Oj Ruby gem and where a request parameter, configuration value, API option, job payload, or other untrusted input can influence the :indent value passed to Oj.dump. The attacker then submits an unusually large indentation value, potentially near the maximum signed 32-bit integer value of 2147483647. In vulnerable Oj versions before 3.17.2, Oj.dump reaches fill_indent in dump.h, which calls memset against a small stack-allocated buffer using the unvalidated large indent length. This overwrites stack memory, causing the Ruby process to crash. In a web application this may kill a worker process; in a background processing system it may repeatedly fail jobs; in a single-process service it may cause an outage until the process is restarted. There is no public indication from the provided data that this vulnerability is being exploited by named threat actors or that reliable remote code execution has been demonstrated.

How to fix it

Upgrade the Oj gem to version 3.17.2 or later wherever it is used. Because no affected product list or per-package fixed-version list was provided beyond the upstream gem version, inventory Ruby applications by dependency manifests and lockfiles, then update Gemfile/Gemfile.lock or gemspec constraints accordingly. If immediate upgrade is not possible, add strict application-level validation so Oj.dump :indent is never derived directly from untrusted input and is constrained to a small safe range, such as 0 to a low double-digit value appropriate for formatting. Disable user-selectable pretty-print indentation where possible. Restart affected application, worker, and job-processing processes after the patched gem is deployed to ensure the vulnerable native extension is no longer loaded.

How to confirm the fix worked

Confirm the installed Oj version is 3.17.2 or later in all runtime images, hosts, containers, and build artifacts. Check Gemfile.lock, gem dependency outputs, software composition analysis results, and container image SBOMs for oj versions below 3.17.2. Validate that application code does not pass untrusted values into Oj.dump :indent, or that the value is bounded before use. In a non-production test environment, reproduce the vulnerable code path with a large indent value before patching to observe a crash, then verify the patched version rejects or safely handles the same condition without process termination. Monitor post-deployment crash/error rates for Ruby application workers to confirm stability.

Typical attack path

  1. Identify a Ruby application or service that uses the Oj gem for JSON serialization.
  2. Find an endpoint, API option, job field, or configuration path where user-controlled input can affect the Oj.dump :indent option.
  3. Submit a crafted request or payload with an extremely large indent value, such as 2147483647.
  4. Trigger the application code path that calls Oj.dump with the attacker-influenced indent value.
  5. Cause fill_indent to call memset with the oversized length against a small stack buffer.
  6. Crash the Ruby process, resulting in denial of service or repeated worker failures.

How to detect it

Look for evidence of abnormal Ruby process crashes correlated with requests, jobs, or messages containing very large indentation or formatting parameters. Relevant log sources include web access logs, application logs, Ruby exception/crash logs, container runtime logs, process supervisor logs, orchestration events, background job logs, and system logs. Search for segmentation faults, worker exits, container restarts, native extension crashes, and repeated failures immediately after requests containing fields or query parameters such as indent, indentation, pretty, pretty_print, format, json_options, or dump options with very large numeric values. Review core dumps, if collected, for crashes in Oj native extension code or functions such as fill_indent, oj_dump, or memset. Since the primary known outcome is denial of service, exploitation evidence may appear as process termination rather than application-level exceptions. No named threat actor behavior is provided for this vulnerability, so detection should focus on crash artifacts and attacker-controlled oversized indent values.

  • oj version < 3.17.2
  • indent=2147483647
  • "indent":2147483647
  • indent: 2147483647
  • indent=2147483648
  • "indent":2147483648
  • pretty_print_indent=2147483647
  • indentation=2147483647
  • Segmentation fault
  • segfault
  • SIGSEGV
  • core dumped
  • fill_indent
  • dump.h
  • Oj.dump
  • oj.so

What your security team should do

  • Inventory all Ruby applications, containers, and services using the Oj gem and identify versions below 3.17.2.
  • Prioritize remediation for internet-facing services, APIs, and background job processors where request or job data can influence JSON serialization formatting options.
  • Upgrade Oj to 3.17.2 or later and redeploy/restart all affected Ruby processes.
  • Review application code for Oj.dump calls that accept dynamic options, especially :indent, and enforce strict allowlists or numeric bounds.
  • Add tests or static analysis rules to prevent untrusted input from controlling serializer options.
  • Monitor application and platform logs for Ruby process crashes, segmentation faults, repeated worker restarts, and requests containing unusually large indent-related parameters.
  • Because this issue is not KEV-listed, not known ransomware-used, and has low EPSS, handle through normal vulnerability management timelines unless exposure analysis shows attacker-controlled indentation is reachable.

The record

Oj (Optimized JSON) is a JSON parser and Object marshaller packaged as a Ruby gem. In versions prior to 3.17.2, Oj.dump is vulnerable to a stack-based buffer overflow when a large :indent value is provided by the developer. fill_indent in dump.h calls memset(indent_str, ' ', (size_t)opts->indent) without validating the size. When opts->indent is set to INT_MAX (2,147,483,647), the (size_t) cast preserves the large value and memset writes 2 GB into the stack-allocated out buffer (4,184 bytes), corrupting the stack and crashing the process. This issue has been fixed in version 3.17.2.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities