Missing Lock Check Affecting ruby3.3-fluentd-kubernetes-daemonset-1.18 package, versions <1.18.0.1.5-r5


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-WOLFILATEST-RUBY33FLUENTDKUBERNETESDAEMONSET118-17671973
  • published29 Jun 2026
  • disclosed24 Jun 2026

Introduced: 24 Jun 2026

NewCVE-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 Wolfi ruby3.3-fluentd-kubernetes-daemonset-1.18 to version 1.18.0.1.5-r5 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream ruby3.3-fluentd-kubernetes-daemonset-1.18 package and not the ruby3.3-fluentd-kubernetes-daemonset-1.18 package as distributed by Wolfi. See How to fix? for Wolfi 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