There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - bcrypt-ruby is a Ruby binding for the OpenBSD bcrypt() password hashing algorithm. Prior to version
    3.1.22, an integer overflow in the Java BCrypt implementation for JRuby can cause zero iterations in the
    strengthening loop. Impacted applications must be setting the cost to 31 to see this happen. The JRuby
    implementation of bcrypt-ruby (`BCrypt.java`) computes the key-strengthening round count as a signed
    32-bit integer. When `cost=31` (the maximum allowed by the gem), signed integer overflow causes the round
    count to become negative, and the strengthening loop executes **zero iterations**. This collapses bcrypt
    from 2^31 rounds of exponential key-strengthening to effectively constant-time computation — only the
    initial EksBlowfish key setup and final 64x encryption phase remain. The resulting hash looks valid
    (`$2a$31$...`) and verifies correctly via `checkpw`, making the weakness invisible to the application.
    This issue is triggered only when cost=31 is used or when verifying a `$2a$31$` hash. This problem has
    been fixed in version 3.1.22. As a workaround, set the cost to something less than 31. (CVE-2026-33306)

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - bcrypt-ruby 是 OpenBSD bcrypt（） 密碼雜湊演算法的 Ruby 綁定。在版本 3.1.22之前，JRuby 的 Java BCrypt 實作中的整數溢位可能會導致強化迴圈中的零迭代。受影響的應用程式必須將成本設定為 31，才能看到這種情況發生。bcrypt-ruby 的 JRuby 實作 （'BCrypt.java'） 將金鑰強化輪數計算為帶正負號的 32 位元整數。當 'cost=31'（gem 允許的最大值）時，帶正負號的整數溢位會導致輪數計數變為負數，並且強化迴圈執行 **零迭代**。這將 bcrypt 從 2^31 輪指數密鑰強化崩潰為有效的恆定時間計算，只剩下初始 EksBlowfish 密鑰設置和最終的 64 倍加密階段。產生的雜湊看起來有效 （'$2a$31$...'），並透過「checkpw」正確驗證，使應用程式不可見弱點。
    只有在使用 cost=31 或驗證「$2a$31$」雜湊時，才會觸發此問題。此問題已在 3.1.22 版中修正。作為因應措施，請將成本設定為小於 31。（CVE-2026-33306）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - bcrypt-ruby 是 OpenBSD bcrypt（） 密码哈希算法的 Ruby 绑定。在低于版本之前 3.1.22，JRuby 的 Java BCrypt 实现中的整数溢出可造成强化循环中的零迭代。受影响的应用程序必须将成本设置为 31 才能看到这种情况发生。bcrypt-ruby 的 JRuby 实现（“BCrypt.java”）将密钥增强轮次计算为有符号的 32 位整数。当 'cost=31'（gem 允许的最大值）时，有符号的整数溢出会导致舍数计数变为负数，并且强化循环执行 **零迭代**。这将 bcrypt 从 2^31 轮指数密钥强化崩溃为有效恒定时间计算，只剩下初始 EksBlowfish 密钥设置和最终 64x 加密阶段。生成的哈希看起来有效 （“$2a$31$...”） 并通过“checkpw”进行正确验证，从而使漏洞对应用程序不可见。
    仅当使用 cost=31 或验证“$2a$31$”哈希时才会触发此问题。已在版本 3.1.22 中修复此问题。变通方案是将成本设为小于 31。（CVE-2026-33306）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - bcrypt-ruby は、OpenBSD bcrypt() パスワードハッシュアルゴリズム用の Ruby バインディングです。バージョン 3.1.22 より前では、JRuby の Java BCrypt 実装の整数オーバーフローにより、強化ループで反復がゼロになることがあります。これを実現するには、影響を受けるアプリケーションでコストを 31 に設定する必要があります。bcrypt-ruby の JRuby 実装(「BCrypt.java」)は、キー強化ラウンドカウントを符号付き 32 ビット整数として計算します。「cost=31」(gemが許容する最大値)の場合、符号付き整数オーバーフローによりラウンドカウントが負数になり、強化ループが**ゼロ反復**を実行します。これにより、bcrypt が 2^31 ラウンドの指数関数的な鍵強化から効果的な定数時間計算に崩壊し、最初の EksBlowfish 鍵セットアップと最後の 64x 暗号化フェーズだけが残ります。結果として得られるハッシュは有効(「$2a$31$...」)、「checkpw」で正しく検証されるため、アプリケーションから弱点は見えなくなります。
    この問題は、cost=31が使用されるとき、または「$2a$31$」ハッシュを検証するときにのみトリガーされます。この問題は、バージョン 3.1.22 で修正されました。回避策として、コストを 31 未満に設定します。(CVE-2026-33306)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - bcrypt-ruby is a Ruby binding for the OpenBSD bcrypt() password hashing algorithm. Prior to version     3.1.22, an integer overflow in the Java BCrypt implementation for JRuby can cause zero iterations in the     strengthening loop. Impacted applications must be setting the cost to 31 to see this happen. The JRuby     implementation of bcrypt-ruby (`BCrypt.java`) computes the key-strengthening round count as a signed     32-bit integer. When `cost=31` (the maximum allowed by the gem), signed integer overflow causes the round     count to become negative, and the strengthening loop executes **zero iterations**. This collapses bcrypt     from 2^31 rounds of exponential key-strengthening to effectively constant-time computation  only the     initial EksBlowfish key setup and final 64x encryption phase remain. The resulting hash looks valid     (`$2a$31$...`) and verifies correctly via `checkpw`, making the weakness invisible to the application.
    This issue is triggered only when cost=31 is used or when verifying a `$2a$31$` hash. This problem has     been fixed in version 3.1.22. As a workaround, set the cost to something less than 31. (CVE-2026-33306)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
439244	SCA: security update for bcrypt (GHSA-f27w-vcwj-c954)	Tenable Cloud Security	SCA Checks	3/26/2026	7/2/2026	high
439244	SCA: security update for bcrypt (GHSA-f27w-vcwj-c954)	Tenable Self-Hosted Container Security	SCA Checks	3/26/2026	7/2/2026	high
303306	Linux Distros 未修補弱點：CVE-2026-33306	Nessus	Misc.	3/22/2026	9/2/2026	high
303306	Linux Distros 未修补的漏洞：CVE-2026-33306	Nessus	Misc.	3/22/2026	9/2/2026	high
303306	Linux Distros のパッチ未適用の脆弱性: CVE-2026-33306	Nessus	Misc.	3/22/2026	9/2/2026	high
303306	Linux Distros Unpatched Vulnerability : CVE-2026-33306	Nessus	Misc.	3/22/2026	9/2/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high