CVE-2026-54905: 
Ruby vulnerability analysis and mitigation

CVE-2026-54905 is a wrap-around error (CWE-128) in the Concurrent::ReentrantReadWriteLock class of the concurrent-ruby gem that allows a thread to incorrectly obtain a write lock without exclusivity. All versions of concurrent-ruby prior to 1.3.7 are affected. The vulnerability was discovered by Pranjali Thakur (depthfirst.com) and published to the GitHub Advisory Database on June 19, 2026. It carries a CVSS v3.1 base score of 5.5 (Medium) and a CVSS v4.0 base score of 2.0 (Low) (Github Advisory, Vendor Advisory).

The root cause is an integer wrap-around (CWE-128) in the per-thread @HeldCount variable used by ReentrantReadWriteLock. The lock packs both read and write hold counts into a single integer: the low 15 bits store the read hold count, and bit 15 (WRITE_LOCK_HELD = 1 << 15 = 32768) is the write-lock flag. When a thread reacquires the read lock 32,768 times, the read count overflows into bit 15, making @HeldCount equal to WRITE_LOCK_HELD. The try_write_lock method then interprets this as the thread already holding a write lock and returns true without setting the global RUNNING_WRITER bit, so other threads are never notified of an active writer and can freely acquire read locks concurrently. A public proof-of-concept demonstrating full reproduction is included in the advisory (Github Advisory).

Successful exploitation breaks the write-lock mutual-exclusion guarantee: a thread believes it holds an exclusive write lock while other threads can simultaneously hold or acquire read locks, creating a race condition on shared mutable state. This can lead to inconsistent or corrupted reads of protected data, potentially exposing sensitive in-memory information to other threads (confidentiality impact). Integrity of shared state may also be compromised if concurrent reads observe partially written data. Availability is not directly impacted, and the vulnerability is confined to the local process — there is no network-based attack surface (Github Advisory, Vendor Advisory).

1. Identify target: Confirm the application uses Concurrent::ReentrantReadWriteLock from concurrent-ruby < 1.3.7 and that a thread can be made to acquire the read lock a large number of times (e.g., in a tight loop or deeply recursive call path).
2. Acquire read lock 32,768 times: From within a single thread that already holds the read lock, call lock.acquire_read_lock exactly 32,768 times (WRITE_LOCK_HELD times). Each call increments @HeldCount by 1.
3. Trigger the overflow: After 32,768 acquisitions, @HeldCount equals 32768 (i.e., WRITE_LOCK_HELD). At this point, try_write_lock checks held >= WRITE_LOCK_HELD, evaluates to true, and returns success without setting the global RUNNING_WRITER bit.
4. Exploit the race: While the attacker's thread believes it holds an exclusive write lock, other threads can still call acquire_read_lock and succeed, because the global writer state was never set. This allows concurrent reads of data the attacker is modifying, potentially exposing in-flight sensitive state.
5. Observe inconsistent state: Read shared mutable data from a concurrent thread while the "writer" thread modifies it, observing partial or inconsistent values (Github Advisory).

Upgrade concurrent-ruby to version 1.3.7 or later, which fixes the integer overflow by correctly handling the read hold count boundary. No configuration-based workaround is available; the only remediation is to update the gem. Applications using Concurrent::ReentrantReadWriteLock with deeply reentrant read lock patterns should be prioritized for patching (Github Advisory, Vendor Advisory).