CVE-2026-54904: concurrent-ruby AtomicReference NaN Infinite Loop DoS

Technical summary

The vulnerability stems from a semantic mismatch between three components: (1) AtomicReference#update, which implements optimistic locking by repeatedly calling compare_and_set() until success; (2) the Numeric compare_and_set implementation, which validates old == old_value before attempting the atomic swap; and (3) IEEE 754 NaN semantics, where Float::NAN == Float::NAN evaluates to false. When an AtomicReference holds Float::NAN, the equality check always fails, the compare_and_set operation never succeeds, and update() never returns—creating a permanent busy-wait loop. This is classified as an Infinite Loop vulnerability (CWE-835). The fix in version 1.3.7 addresses the NaN comparison semantics within the update retry logic.

Business impact

Applications relying on concurrent-ruby for thread-safe numeric operations face two critical risks: denial of service through CPU exhaustion if update() is called on an AtomicReference containing NaN, and request/job hangs if the update operation is performed synchronously in web request handlers or background job workers. This is particularly dangerous in services ingesting external numeric data (APIs, sensors, financial feeds) that may produce NaN values. A single malformed data input could crash or freeze an entire service thread or worker process.

Affected systems

concurrent-ruby versions prior to 1.3.7 are affected. Any Ruby application using the concurrent-ruby gem that stores or processes floating-point numbers in AtomicReference objects and calls the update() method is at risk. The vulnerability is most acute in services that accept external numeric inputs without validation, or in multi-threaded data processing pipelines where NaN values might propagate into atomic references.

Exploitability

Exploitation is straightforward and requires no special privileges or user interaction. An attacker who can influence numeric data flowing into an application using concurrent-ruby (e.g., via API requests, sensor data, or third-party feeds) can deliberately inject NaN values. Once a NaN reaches an AtomicReference, any subsequent update() call will hang. No special attack tools, authentication, or network position is required—only the ability to supply crafted numeric input. The attack surface is broad in data-ingestion applications.

Remediation

Upgrade concurrent-ruby to version 1.3.7 or later immediately. For applications unable to patch immediately, implement input validation to reject or sanitize NaN values before storing them in AtomicReferences. Consider replacing AtomicReference#update with non-retry-based approaches for numeric values if update semantics cannot be avoided. Review all code paths that call update() on AtomicReferences to identify exposure points.

Patch guidance

Apply the upgrade to concurrent-ruby 1.3.7 as part of your next dependency update cycle, prioritizing this above routine patches due to the HIGH severity rating. Verify the upgrade in a staging environment to ensure no other gem dependencies conflict. The patch should be applied to all Ruby applications in your environment that depend on concurrent-ruby, whether directly or transitively. Check your Gemfile.lock and dependency trees for indirect dependencies on concurrent-ruby and ensure the updated version is propagated across the entire fleet.

Detection guidance

Look for applications using concurrent-ruby versions < 1.3.7 via dependency scanning (bundler-audit, Dependabot, or software composition analysis tools). Monitor for increased CPU usage or thread hangs in Ruby processes, especially those handling external numeric data. Enable application-level logging around AtomicReference#update calls and watch for indefinite blocking. In staging, inject NaN test values into numeric fields and verify they do not cause update() hangs. Consider adding a timeout wrapper around update() calls as a temporary detective control.

Why prioritize this

This vulnerability merits immediate attention due to its HIGH CVSS score (7.5), trivial exploitability, and severe impact on availability. Unlike many high-severity vulnerabilities that require specific configurations or user actions, this one is triggered automatically once NaN reaches an AtomicReference, making it a reliable denial-of-service vector. The fix is simple and well-tested, with no known breaking changes in version 1.3.7. Any delay in patching leaves services vulnerable to request hangs and CPU exhaustion.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects: Network-accessible attack vector (AV:N), low attack complexity requiring only crafted input (AC:L), no privileges required (PR:N), no user interaction (UI:N), and a scope limited to the affected service (S:U). The impact is purely on availability (A:H)—requests hang indefinitely—with no confidentiality or integrity impact. The score would be higher if the vulnerability allowed remote code execution, but CPU exhaustion and service degradation alone justify the HIGH rating.

Frequently asked questions