CVE-2026-54906: 
Ruby 脆弱性の分析と軽減

CVE-2026-54906 is a synchronization correctness vulnerability in the concurrent-ruby gem's Concurrent::ReadWriteLock implementation, affecting versions prior to 1.3.7. The flaw manifests in two related issues: release_write_lock does not verify that the calling thread actually holds the write lock, and release_read_lock unconditionally decrements the shared counter even when no read lock is held. It was published on June 16, 2026, and assigned a CVSS v4 base score of 2.1 (Low) (GitHub Advisory, Repo Advisory).

The root cause is classified as CWE-414 (Missing Lock Check) and CWE-667 (Improper Locking). In release_write_lock, the method only checks whether a writer is globally running via the shared @Counter atomic variable — it does not track or verify which thread acquired the lock. This means any thread with a reference to the lock object can call release_write_lock and clear the RUNNING_WRITER bit, allowing a second writer to enter the critical section concurrently with the first. Separately, release_read_lock unconditionally decrements the counter via a compare-and-set loop; calling it on a fresh lock drives the counter to -1, causing subsequent acquire_read_lock calls to raise Concurrent::ResourceLimitError because the maximum-reader check interprets the negative value as a saturated count. Both issues are exploitable only by code running within the same process that has access to the lock object (GitHub Advisory).

Successful exploitation can break the write-lock mutual exclusion guarantee, allowing two writer threads to execute concurrently inside a critical section and introducing data races on any mutable state protected by the lock. If the lock guards integrity-sensitive data structures, concurrent writers could corrupt application state. The stray read-release path can render the lock permanently unusable, causing a localized denial of service for any code that subsequently attempts to acquire a read lock (Concurrent::ResourceLimitError). The impact is strictly local to the affected process; there is no network exposure, no confidentiality impact, and no lateral movement potential (GitHub Advisory, Repo Advisory).

1. Obtain lock reference: Acquire a reference to a Concurrent::ReadWriteLock object within the target Ruby process — this requires being co-located in the same process (e.g., a malicious gem, plugin, or thread).
2. Trigger wrong-thread write release: While a legitimate writer thread holds the write lock (i.e., between acquire_write_lock and release_write_lock), call lock.release_write_lock from a different thread. The method checks only the global counter, not ownership, and returns true, clearing the RUNNING_WRITER bit.
3. Achieve concurrent write access: Immediately after the intruder thread releases the lock, spawn a second writer thread that calls acquire_write_lock. Because the RUNNING_WRITER bit is cleared, the second writer enters its critical section while the first writer is still executing — violating mutual exclusion.
4. Trigger read-lock counter corruption (alternative path): On a fresh or idle lock, call lock.release_read_lock without having acquired a read lock. This decrements the counter from 0 to -1.
5. Cause denial of service: Any subsequent call to lock.acquire_read_lock raises Concurrent::ResourceLimitError: Too many reader threads, rendering the lock unusable for all reader threads in the process (GitHub Advisory).

Upgrade concurrent-ruby to version 1.3.7 or later, which is the patched release that addresses both the missing ownership check in release_write_lock and the unconditional decrement in release_read_lock. No configuration-based workaround is available; the fix requires a code change in the library itself. As an interim measure, applications can audit their use of the manual acquire_* / release_* API to ensure release methods are only called by the thread that acquired the lock, and avoid exposing lock objects to untrusted code paths (GitHub Advisory, Repo Advisory).

The advisory was published by eregon (a core concurrent-ruby maintainer) on June 16, 2026, and credited to researcher Pranjali Thakur of depthfirst.com. The advisory explicitly notes the issue should not be framed as an authorization bypass, clarifying that ReadWriteLock is an in-process concurrency primitive rather than an access-control boundary — a nuance that helps prevent overstating the severity (Repo Advisory).