CVE-2026-54906: concurrent-ruby ReadWriteLock: write lock release without ownership check

Overview

The record describes a synchronization correctness flaw in the public Concurrent::ReadWriteLock API of concurrent-ruby. The write-lock release method does not confirm that the calling thread owns the lock, and the read-lock release method decrements a shared counter even when no read lock is held. The GitHub Security Advisory GHSA-6wx8-w4f5-wwcr is the third-party reference listed for this record.

Impact

• According to the record, a thread with access to the lock object can release a write lock held by another thread, so a second writer may enter its critical section while the first is still running. This can corrupt shared state that the lock was meant to protect.
• A release call on a fresh lock moves the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This can cause denial of service in code that depends on that lock.
• NVD scores the issue at CVSS 3.1 9.8 (Network, low complexity, no privileges, no user interaction, high confidentiality, integrity and availability impact as listed in the vector). GitHub, as CNA, lists a CVSS 4.0 score of 2.1. The two scores differ and the record does not explain the difference.

Affected products and versions

• Product: Rubyconcurrency Concurrent Ruby.
• Affected versions: those before 1.3.7, as stated in the record.
• The record states the vulnerability is fixed in 1.3.7. The record's fixes list is empty, so the fix is confirmed only by the description text.

Exploitation status

The CISA KEV catalog does not list this CVE in the record. No confirmed active exploitation or exploitation in the wild appears in the sources consulted. The EPSS score is not available in the record.

Remediation and mitigation

• Upgrade concurrent-ruby to version 1.3.7 or later, as described in the record. Review the dependency tree, including transitive dependencies, to find every installed copy.
• Until patching is possible, review application code that calls Concurrent::ReadWriteLock directly and make sure lock acquisition and release are confined to the same thread and code path. This is a general defensive pattern, not a substitute for the fix.
• Verify the installed version after deployment and restart long-running services so the patched library is loaded.

Detection guidance

• Inventory Gemfile.lock files and deployed images for concurrent-ruby versions below 1.3.7.
• Monitor application logs for Concurrent::ResourceLimitError, which the record associates with a negative counter after a spurious release call.
• Investigate unexpected concurrent behavior in code protected by read-write locks, such as overlapping writes to shared data, as a possible symptom.

Limitations of the available information

The record does not include a fixes list, EPSS, SSVC data, a CWE name beyond the identifier, or detailed reproduction conditions. It does not state which applications or workloads are most exposed. The gap between the CVSS 3.1 and CVSS 4.0 scores is not explained. Conclusions about real-world exposure are therefore limited.

Frequently asked questions

What is the core problem in CVE-2026-54906?

According to the record, Concurrent::ReadWriteLock#release_write_lock does not check that the calling thread holds the write lock, so another thread can release it. The release_read_lock method can also decrement the counter without a held read lock.

Which versions are affected and what fixes it?

The record lists versions before 1.3.7 as affected and states that the vulnerability is fixed in 1.3.7. The record's fixes list is empty, so the fix is confirmed only by the description.

Is this vulnerability being exploited?

The CISA KEV catalog does not list it in this record, and no confirmed exploitation appears in the sources consulted.

This analysis was drafted with AI assistance from verified source data and automatically checked against it.