CVE-2026-33210

What it actually does

Ruby JSON versions 2.14.0 through the vulnerable release lines before 2.15.2.1, 2.17.1.2, and 2.19.2 contain a format string injection flaw in parsing paths that reject duplicate keys using the allow_duplicate_key: false option. If an application parses attacker-supplied JSON with that option enabled, crafted key names can be interpreted as format strings rather than inert data. The practical impact is application-level denial of service through parser crashes or abnormal termination, and potential limited information disclosure from process memory or error output depending on platform, build, logging behavior, and how exceptions are surfaced.

Why it matters to the business

Services that accept JSON from users, partners, APIs, queues, webhooks, or uploaded documents may be disrupted by a single crafted request if they use the vulnerable Ruby JSON parser configuration. The highest operational risk is outage or degraded availability of Ruby services, background workers, API endpoints, and data-ingestion pipelines; a secondary risk is leakage of sensitive runtime data through error responses or logs. Although EPSS is currently low and there is no known KEV listing or reported exploit maturity, the CVSS severity is high because the bug can be reached remotely without authentication in exposed parsing paths.

How an attack unfolds

An attacker first identifies an endpoint or processing flow that accepts arbitrary JSON and is implemented with the Ruby JSON library. The attacker then determines, directly or by trial and error, whether duplicate-key rejection is enabled via allow_duplicate_key: false. They submit a JSON document containing duplicate keys where the relevant key material includes format-string tokens. During duplicate-key validation, the vulnerable parser mishandles attacker-controlled key text as a format string. Depending on the runtime and error-handling path, this can crash the Ruby process, trigger repeated parser exceptions that consume resources, or expose limited process data in generated messages. The attacker can repeat the request against externally reachable API routes, webhook receivers, or asynchronous ingestion workers to sustain denial of service.

How to fix it

Upgrade the Ruby JSON package to a patched version in the applicable release line: 2.15.2.1 or later for the 2.15 line, 2.17.1.2 or later for the 2.17 line, or 2.19.2 or later for the 2.19 line. If possible, upgrade to the latest current json gem release rather than only the minimum fixed version. Rebuild and redeploy all Ruby applications, containers, serverless packages, and worker images that vendor or bundle the json gem. If immediate upgrade is not possible, reduce exposure by avoiding parsing untrusted JSON with allow_duplicate_key: false in vulnerable versions, limiting request body sizes, enforcing authentication and rate limits on JSON-ingestion endpoints, returning generic parse errors, and preventing detailed parser exceptions from being exposed to clients. These mitigations reduce risk but should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm dependency resolution with package manifests and runtime checks, including Gemfile.lock, gemspec files, container images, vendor/bundle directories, and output from bundle info json or ruby -rjson -e 'puts JSON::VERSION'. The installed json version should be 2.15.2.1, 2.17.1.2, 2.19.2, or a later fixed release and should not be in the vulnerable range beginning at 2.14.0. Search application code for JSON.parse or JSON.load calls using allow_duplicate_key: false and verify those code paths no longer run on vulnerable json versions. Validate deployed artifacts, not just source repositories, because Ruby gems are often bundled into build images. Exercise representative JSON-ingestion endpoints with duplicate-key test documents in a controlled environment and confirm the service returns safe, generic errors without crashing or disclosing internal details.

Typical attack path

1. Find a Ruby application endpoint, webhook, upload feature, API, or queue consumer that accepts user-supplied JSON.
2. Send benign JSON with duplicate keys to infer whether duplicate-key rejection is enabled.
3. Craft JSON containing duplicate keys whose key names include format-string sequences.
4. Submit the crafted document to the vulnerable parsing path.
5. Trigger parser crash, abnormal exception handling, excessive error generation, or limited data disclosure.
6. Repeat requests or target multiple ingestion paths to maintain service disruption.

How to detect it

To assess possible prior exploitation, review logs and telemetry from any Ruby service that accepts untrusted JSON and uses duplicate-key rejection. Useful sources include application logs, API gateway and reverse-proxy access logs, WAF logs, container stdout/stderr, process-manager logs, crash reports, APM error traces, and worker queue dead-letter records. Look for spikes in JSON parsing failures, repeated requests with malformed or duplicate-key JSON bodies, HTTP 400/422/500 responses clustered around the same endpoints, Ruby process restarts, container crash loops, segmentation faults, or exception traces involving the json gem. If request bodies are logged or sampled, search for JSON object keys containing format-string tokens such as %s, %p, %x, %n, or unusually long percent-format sequences, especially in documents that also contain duplicate keys. Correlate suspicious requests with service restarts, elevated error rates, memory faults, or unusual error messages that may include fragments of process data. Threat actor exploitation is not reported in the provided intelligence, so detection should focus on behavioral evidence rather than named actor tooling.

• allow_duplicate_key: false
• JSON.parse(
• JSON.load(
• JSON::ParserError
• duplicate key
• json (2.14.
• json (2.15.0
• json (2.15.1
• json (2.15.2)
• json (2.17.0
• json (2.17.1)
• json (2.19.0
• json (2.19.1)
• Gemfile.lock
• vendor/bundle
• /usr/local/bundle/gems/json-2.14
• /usr/local/bundle/gems/json-2.15.0
• /usr/local/bundle/gems/json-2.15.1
• /usr/local/bundle/gems/json-2.15.2
• /usr/local/bundle/gems/json-2.17.0
• /usr/local/bundle/gems/json-2.17.1
• /usr/local/bundle/gems/json-2.19.0
• /usr/local/bundle/gems/json-2.19.1
• %n
• %p
• %x
• %s
• Segmentation fault
• core dumped
• ruby

What your security team should do

• Inventory all Ruby applications, jobs, containers, and serverless functions that include the json gem, prioritizing internet-facing APIs, webhook receivers, file-ingestion services, and message consumers.
• Upgrade vulnerable json gem versions to 2.15.2.1, 2.17.1.2, 2.19.2, or later, and redeploy affected workloads.
• Search code and packaged artifacts for allow_duplicate_key: false to identify the vulnerable parsing condition and prioritize those applications for urgent remediation.
• Add or tune rate limits, request-size limits, and generic error handling on JSON-ingestion endpoints until all affected services are patched.
• Review application, reverse-proxy, WAF, container, and process-supervisor logs for repeated JSON parser errors, duplicate-key parse failures, abnormal Ruby process exits, or crash loops since publication.
• Add dependency scanning rules or software composition analysis policies that flag ruby-lang json versions 2.14.0 through the affected pre-fixed releases.
• Ensure exception details from JSON parsing are not returned to clients and are appropriately redacted in logs.
• Because there is no known KEV listing, ransomware association, or public exploit maturity in the provided data, treat this as high-priority exposure-driven patching rather than confirmed active mass exploitation.