concurrent-ruby CVE-2026-54906

The write-lock bypass requires that the attacker control or influence a Ruby thread executing within the same OS process as the target application, and that thread must hold a reference to the specific Concurrent::ReadWriteLock instance under attack. The application must use the manual acquire_write_lock / release_write_lock API rather than the block form with_write_lock. A second writer thread must be available to acquire the lock after the attacker clears the RUNNING_WRITER bit. External network attackers cannot trigger this without prior arbitrary code execution in the Ruby process. For the counter-corruption denial-of-service path, the only condition is that any thread with access to the lock object calls release_read_lock without a prior acquire_read_lock; no timing coordination or second thread is needed. Both exploitation paths are limited to in-process scenarios and do not require elevated OS-level privileges or special Ruby runtime configuration.

Real-world risk is moderate and scoped to in-process threat models. No NVD CVSS vector or EPSS score was provided for this CVE; all metric assessments below are independently derived from the advisory description and reproduction evidence. There is no CISA KEV listing, and this is not a remotely exploitable network vulnerability. The primary threat actors are: (a) untrusted code running as threads within the same Ruby process, such as plugin systems or multi-tenant job queues, and (b) application-level coding defects that call release methods outside a proper acquire/release pair. The integrity impact is high when the lock protects shared mutable state, as the write-exclusion bypass directly creates data races. The availability impact is concrete but bounded: only the specific lock instance becomes permanently unusable after counter corruption; other locks and the broader process are unaffected. The DoS tag in the advisory accurately reflects the stray read-release path. This is not a high-CVSS-but-low-real-risk situation - it is a genuine correctness flaw with meaningful impact in concurrent Ruby applications, though its exploitability is substantially constrained by the requirement to execute code within the same process.

A proof-of-concept is included in the GitHub Security Advisory. An attacker thread running within the same Ruby process obtains a reference to a shared Concurrent::ReadWriteLock instance, waits for a legitimate writer to signal lock acquisition, then immediately calls release_write_lock from the attacker thread - which succeeds without ownership verification. A second writer thread can then acquire the write lock and execute concurrently with the still-running first writer, creating a data race on any shared mutable state the lock was intended to protect. In the counter-corruption path, the attacker calls release_read_lock on a fresh or idle lock, driving the counter to -1, after which all subsequent read acquisitions by all threads fail with Concurrent::ResourceLimitError.