https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 00:13:09 +0000 https://cve.radiocsirt.org/vuln/brew-asciidoctor-cve-2026-54906 <p><strong>Affected:</strong> Homebrew: asciidoctor</p> <p>### Summary `Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.</p> <p>`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.</p> <p>This is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.</p> <p>### Version Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab</p> <p>### Details</p> <p>`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:</p> <p>```ruby def release_write_lock return true unless running_writer? c = @Counter.update { |counter| counter - RUNNING_WRITER } @ReadLock.broadcast @WriteLock.signal if waiting_writers(c) &gt; 0 true end ```</p> <p>Because ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first…</p> <p><strong>Affected:</strong> Homebrew: asciidoctor</p> <p>### Summary `Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.</p> <p>`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.</p> <p>This is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.</p> <p>### Version Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab</p> <p>### Details</p> <p>`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:</p> <p>```ruby def release_write_lock return true unless running_writer? c = @Counter.update { |counter| counter - RUNNING_WRITER } @ReadLock.broadcast @WriteLock.signal if waiting_writers(c) &gt; 0 true end ```</p> <p>Because ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first…</p> https://cve.radiocsirt.org/vuln/brew-asciidoctor-cve-2026-54906 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0958 certfr-2026-avi-0958 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0958 https://cve.radiocsirt.org/vuln/cleanstart-2026-de16221 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: ruby-fluentd-1.18</p> <p>Multiple security vulnerabilities affect the ruby-fluentd-1.18 package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: ruby-fluentd-1.18</p> <p>Multiple security vulnerabilities affect the ruby-fluentd-1.18 package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-de16221 https://cve.radiocsirt.org/vuln/euvd-2026-330009 EUVD-2026-330009 https://cve.radiocsirt.org/vuln/euvd-2026-330009 https://cve.radiocsirt.org/vuln/fkie_cve-2026-54906 <p>concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7.</p> <p>concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-54906 https://cve.radiocsirt.org/vuln/ghsa-6wx8-w4f5-wwcr <p><strong>Affected:</strong> RubyGems: concurrent-ruby</p> <p>### Summary `Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.</p> <p>`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.</p> <p>This is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.</p> <p>### Version Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab</p> <p>### Details</p> <p>`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:</p> <p>```ruby def release_write_lock return true unless running_writer? c = @Counter.update { |counter| counter - RUNNING_WRITER } @ReadLock.broadcast @WriteLock.signal if waiting_writers(c) &gt; 0 true end ```</p> <p>Because ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first…</p> <p><strong>Affected:</strong> RubyGems: concurrent-ruby</p> <p>### Summary `Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.</p> <p>`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.</p> <p>This is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.</p> <p>### Version Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab</p> <p>### Details</p> <p>`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:</p> <p>```ruby def release_write_lock return true unless running_writer? c = @Counter.update { |counter| counter - RUNNING_WRITER } @ReadLock.broadcast @WriteLock.signal if waiting_writers(c) &gt; 0 true end ```</p> <p>Because ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first…</p> https://cve.radiocsirt.org/vuln/ghsa-6wx8-w4f5-wwcr https://cve.radiocsirt.org/vuln/msrc_cve-2026-54906 msrc_CVE-2026-54906 https://cve.radiocsirt.org/vuln/msrc_cve-2026-54906 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54906 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-concurrent, Ubuntu:18.04:LTS: ruby-concurrent, Ubuntu:20.04:LTS: ruby-concurrent, Ubuntu:22.04:LTS: ruby-concurrent, Ubuntu:24.04:LTS: ruby-concurrent, Ubuntu:25.10: ruby-concurrent, Ubuntu:26.04:LTS: ruby-concurrent</p> <p>concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-concurrent, Ubuntu:18.04:LTS: ruby-concurrent, Ubuntu:20.04:LTS: ruby-concurrent, Ubuntu:22.04:LTS: ruby-concurrent, Ubuntu:24.04:LTS: ruby-concurrent, Ubuntu:25.10: ruby-concurrent, Ubuntu:26.04:LTS: ruby-concurrent</p> <p>concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54906