I think there may be a problem in Gemfile.lock around line 69.
Vulnerable dependency found: concurrent-ruby 1.2.3 (Gemfile.lock, line 69) is affected by CVE-2026-54906, rated CRITICAL, fixed in >= 1.3.7. The flaw is in the Concurrent::ReadWriteLock synchronization API: (1) release_write_lock does not verify that the calling thread owns the write lock, so any thread with access to the lock object can release a write lock held by another thread, letting a second writer enter its critical section while the first is still running — a race condition that can cause data corruption, inconsistent state, or security-relevant TOCTOU bugs in code protected by the lock; (2) release_read_lock decrements the shared counter even when no read lock is held, so a stray call drives the counter to -1 and all subsequent read acquisitions raise Concurrent::ResourceLimitError, enabling an availability/denial-of-service failure. Impact is highest if the application or its gems (e.g., Rails concurrency internals) actually use ReadWriteLock, but since this is a public API correctness bug, upgrading is low-risk and strongly recommended. Fix by upgrading to concurrent-ruby 1.3.7 (a compatible patch release for existing ~> 1.x constraints, including Rails') and regenerating the lockfile.
Something like this might fix it:
Upgrade the dependency to the fixed version. Preferred approach — let Bundler resolve and regenerate Gemfile.lock:
$ bundle update concurrent-ruby
Resulting diff:
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -66,7 +66,7 @@
concurrent-ruby (1.2.3)
+ concurrent-ruby (1.3.7)
More precisely, replace the resolved version entry:
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -69,1 +69,1 @@
- concurrent-ruby (1.2.3)
+ concurrent-ruby (1.3.7)
Optionally, add a floor constraint in the Gemfile to prevent regressions:
--- a/Gemfile
+++ b/Gemfile
@@
-gem "concurrent-ruby"
+gem "concurrent-ruby", ">= 1.3.7"
Then run `bundle install` (or `bundle update concurrent-ruby`), commit the updated Gemfile.lock, and re-run the container/vulnerability scan to confirm the finding is resolved. No application code changes are required; 1.3.7 is a patch release with no expected breaking API changes for ReadWriteLock consumers.For reference: rule CVE-2026-54906. Rated critical.
I do not maintain this project, so I may well be missing context — if this is intentional or already handled elsewhere, please just close it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
I think there may be a problem in
Gemfile.lockaround line 69.Vulnerable dependency found: concurrent-ruby 1.2.3 (Gemfile.lock, line 69) is affected by CVE-2026-54906, rated CRITICAL, fixed in >= 1.3.7. The flaw is in the Concurrent::ReadWriteLock synchronization API: (1) release_write_lock does not verify that the calling thread owns the write lock, so any thread with access to the lock object can release a write lock held by another thread, letting a second writer enter its critical section while the first is still running — a race condition that can cause data corruption, inconsistent state, or security-relevant TOCTOU bugs in code protected by the lock; (2) release_read_lock decrements the shared counter even when no read lock is held, so a stray call drives the counter to -1 and all subsequent read acquisitions raise Concurrent::ResourceLimitError, enabling an availability/denial-of-service failure. Impact is highest if the application or its gems (e.g., Rails concurrency internals) actually use ReadWriteLock, but since this is a public API correctness bug, upgrading is low-risk and strongly recommended. Fix by upgrading to concurrent-ruby 1.3.7 (a compatible patch release for existing ~> 1.x constraints, including Rails') and regenerating the lockfile.
Something like this might fix it:
For reference: rule
CVE-2026-54906. Rated critical.I do not maintain this project, so I may well be missing context — if this is intentional or already handled elsewhere, please just close it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.