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 密钥设置和最终的 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 的判定取決於廠商所報告的套件是否存在。

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

  - bcrypt-ruby は、OpenBSD bcrypt() パスワードハッシュアルゴリズム用の Ruby バインディングです。バージョン 3.1.22より前では、JRuby 用の Java BCrypt の実装での整数オーバーフローにより、強化ループでゼロ反復が発生する可能性があります。影響を受けるアプリケーションは、コストを 31 に設定している必要があります。bcrypt-ruby`BCrypt.java`の JRuby 実装は、鍵強化ラウンドカウントを符号付き 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	名称	产品	系列	发布时间	最近更新时间	严重程度
439244	SCA: security update for bcrypt (GHSA-f27w-vcwj-c954)	Tenable Cloud Security	SCA Checks	2026/3/26	2026/7/2	high
439244	SCA: security update for bcrypt (GHSA-f27w-vcwj-c954)	Tenable Self-Hosted Container Security	SCA Checks	2026/3/26	2026/7/2	high
303306	Linux Distros 未修补的漏洞：CVE-2026-33306	Nessus	Misc.	2026/3/22	2026/4/6	high
303306	Linux Distros 未修補的弱點：CVE-2026-33306	Nessus	Misc.	2026/3/22	2026/4/6	high
303306	Linux Distros のパッチ未適用の脆弱性: CVE-2026-33306	Nessus	Misc.	2026/3/22	2026/4/6	high
303306	Linux Distros Unpatched Vulnerability : CVE-2026-33306	Nessus	Misc.	2026/3/22	2026/4/6	high

检测

插件搜索

high

high

high

high

high

high