CVE-2026-54906 is a critical rated flaw (CVSS 9.8) in the concurrent-ruby gem before 1.3.7. Concurrent::ReadWriteLock does not check which thread releases a write lock, so another thread can release it and let a second writer in. The maintainers describe it as a synchronization issue. Upgrade to 1.3.7.
What's affected
- concurrent-ruby before 1.3.7, per the record.
- Fixed in 1.3.7.
- Code that uses Concurrent::ReadWriteLock directly and exposes the lock object to code that should not release it.
How to check if you're exposed
Find the gem version in each application.
bundle list | grep concurrent-ruby
bundle exec gem list concurrent-ruby
In Gemfile.lock, search for concurrent-ruby. It is a very common transitive dependency, so also check frameworks and tools. Then search your own code for ReadWriteLock. If nothing in your code or your dependencies uses that class, the practical risk is low, though the version should still move forward.
What to do now
- Run
bundle update concurrent-rubyand confirm the lock file shows 1.3.7 or later. - Rebuild and redeploy images and gems that vendor an older copy.
- Search your code for ReadWriteLock and check whether any lock object can reach code that should not release it.
- Re-scan to confirm no older copy remains.
Why it matters
The classes are CWE-414, CWE-667: use of a potentially invalid lock, and improper locking. The advisory says release_write_lock checks only that some writer is running, not that the calling thread holds the lock. A release of a read lock that was never taken also changes the shared counter from zero to minus one, which makes later read acquisitions raise an error.
The maintainers say it should not be treated as an authorization bypass, since the lock is an in-process primitive and not an access control boundary. The CVSS score of 9.8 reflects how the CVE record was scored, not an assessment of how many applications are at risk. This is a case where reachability matters, so checking whether the class is used tells you more than the number does. The record does not mark the CVE as exploited in the wild.
For your own projects, the free in-browser dependency scan needs no install, and the Gold directory tracks this CVE.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is a 9.8 not an emergency here?
The advisory frames it as a synchronization correctness issue in a public API. Whether it affects you depends on whether your code uses ReadWriteLock in a way that other threads can misuse.
Sources
Last reviewed: 19 October 2026.
