Missing Lock Check Affecting ruby4.0-fluentd-kubernetes-daemonset-1.19-kinesis package, versions <1.19.3.1.0-r0


Severity

Recommended
low

Based on default assessment until relevant scores are available.

Threat Intelligence

EPSS
0.16% (6th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-MINIMOSLATEST-RUBY40FLUENTDKUBERNETESDAEMONSET119KINESIS-17741644
  • published1 Jul 2026
  • disclosed24 Jun 2026

Introduced: 24 Jun 2026

CVE-2026-54906  (opens in a new tab)
CWE-414  (opens in a new tab)
CWE-667  (opens in a new tab)

How to fix?

Upgrade Minimos:latest ruby4.0-fluentd-kubernetes-daemonset-1.19-kinesis to version 1.19.3.1.0-r0 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream ruby4.0-fluentd-kubernetes-daemonset-1.19-kinesis package and not the ruby4.0-fluentd-kubernetes-daemonset-1.19-kinesis package as distributed by Minimos. See How to fix? for Minimos:latest relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1