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

  - OpenIDC/cjose 是實作 Javascript Object Signing and Encryption (JOSE) 的 C 程式庫。在 的0.6.2.5版本0.6.1中，當 cjose 使用 AES-CBC-HMAC 內容加密演算法 （「A128CBC-HS256」、「A192CBC-HS384」或「A256CBC-HS512」） 以及任何產生新內容加密金鑰 （CEK） 的金鑰管理演算法來加密 JWE 時，CEK 都是零位元組，而不是隨機產生。因此，產生的 JWE 在固定的、公開已知的金鑰下進行加密和身份驗證，因此任何獲得 JWE 的人都可以恢復純文字並偽造或修改內容。此問題已透過「_cjose_jwe_set_cek_aes_cbc（）」從「RAND_bytes」產生 CEK 來修正 0.6.2.6 。迴歸測試斷言，每個 AES-CBC-HMAC 變體的兩種加密的「encrypted_key」都不同。在升級之前，對於使用 cjose 加密的資料，有三個選項可用。使用 AES-GCM 'ENC' （'A128GCM' / 'A192GCM' / 'A256GCM'） 取代 AES-CBC-HMAC 'enc'，搭配呼叫端提供的 CEK 使用 'alg=dir'，或避免使用 cjose 進行受影響演算法組的 JWE 加密。這些只是針對新密文的緩解措施;已在零金鑰下加密的資料仍會遭到入侵，應重新加密 （並輪換其中包含的任何密碼）。（CVE-2026-53939）

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

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

  - OpenIDC/cjose 是实现 Javascript 对象签名和加密 (JOSE) 的 C 库。在 之后的0.6.2.5版本0.6.1中，当 cjose 使用 AES-CBC-HMAC 内容加密算法（“A128CBC-HS256”、“A192CBC-HS384”或“A256CBC-HS512”）以及任何可生成全新内容加密密钥 （CEK） 的密钥管理算法对 JWE 进行加密时，CEK 全部为零字节，而不是随机生成。因此，生成的 JWE 会使用固定的公开密钥进行加密和认证，因此获得 JWE 的任何人都可以恢复明文和伪造或修改内容。在版本 0.6.2.6 中已通过“_cjose_jwe_set_cek_aes_cbc（）”从“RAND_bytes”生成 CEK 来修复此问题。回归测试断言每个 AES-CBC-HMAC 变体的两种加密中的“encrypted_key”不同。在升级之前，对于使用 cjose 加密的数据，有三个选项可用。使用 AES-GCM“enc”（“A128GCM”/“A192GCM”/“A256GCM”）而不是 AES-CBC-HMAC“ENC”，对调用程序提供的 CEK 使用“alg=dir”，或避免与受影响的算法对一起使用 cjose 进行 JWE 加密。这些仅是针对新密文的缓解措施;已在零密钥下加密的数据仍然会受到影响，应重新加密（以及其中包含的任何机密已轮换）。（CVE-2026-53939）

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

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

  - OpenIDC/cjose は、Javascript Object Signing and Encryption (JOSE) を実装する C ライブラリです。0.6.1 から 0.6.2.5 までのバージョンでは、cjose が AES-CBC-HMAC コンテンツ暗号化アルゴリズム(「A128CBC-HS256」、「A192CBC-HS384」、または「A256CBC-HS512」)と、新しいコンテンツ暗号化キー(CEK)を生成する何らかの鍵管理アルゴリズムを使用して JWE を暗号化する際に、CEK はランダムに生成されるのではなく、すべてゼロバイトになります。このため、結果として生成される JWE は、固定された、公知の鍵で暗号化および認証されます。このため、JWE を取得した者は誰でも、平文を復元し、コンテンツを偽造または改ざんすることができます。これは、バージョン 0.6.2.6 で、「RAND_bytes」から CEK を生成する「_cjose_jwe_set_cek_aes_cbc()」によって修正されています。回帰テストでは、「encrypted_key」が各 AES-CBC-HMAC バリアントの 2 つの暗号化間で異なることをアサートします。アップグレードまでは、cjose で暗号化されたデータの場合、3 つのオプションが利用可能です。AES-CBC-HMAC「enc」の代わりに AES-GCM「enc」(「A128GCM」/「A192GCM」/「A256GCM」)を使用するか、呼び出し元指定の CEK を指定して「alg=dir」を使用するか、影響を受けるアルゴリズムペアで JWE 暗号化に cjose を使用しないようにします。これらは、新しい暗号文のみに対する緩和策です。すでにゼロキーで暗号化されているデータは侵害されたままであるため、再暗号化する必要があります (含まれていた機密情報もローテーション)。(CVE-2026-53939)

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

リモートホストにインストールされている FreeBSD のバージョンは、テスト済みバージョンより前です。したがって、3a38fdda-b05a-11f1-9369-b42e991fc52e のアドバイザリに記載されている脆弱性の影響を受けます。

    https://github.com/OpenIDC/cjose/security/advisories/GHSA-f6wf-pqg3-6wqq による報告:

            OpenIDC/cjose は、Javascript Object Signing and Encryption(JOSE)を実装する C ライブラリです。0.6.1 から 0.6.2.5 までのバージョンでは、cjose が AES-CBC-HMAC コンテンツ暗号化アルゴリズム(「A128CBC-HS256」、「A192CBC-HS384」、または「A256CBC-HS512」)と、新しいコンテンツ暗号化キー(CEK)を生成する何らかの鍵管理アルゴリズムを使用して JWE を暗号化する際に、CEK はランダムに生成されるのではなく、すべてゼロバイトになります。このため、結果として生成される JWE は、固定された、公知の鍵で暗号化および認証されます。このため、JWE を取得した者は誰でも、平文を復元し、コンテンツを偽造または改ざんすることができます。これは、バージョン 0.6.2.6 で、「RAND_bytes」から CEK を生成する「_cjose_jwe_set_cek_aes_cbc()」によって修正されています。回帰テストでは、「encrypted_key」が各 AES-CBC-HMAC バリアントの 2 つの暗号化間で異なることをアサートします。アップグレードまでは、cjose で暗号化されたデータの場合、3 つのオプションが利用可能です。AES-CBC-HMAC「enc」の代わりに AES-GCM「enc」(「A128GCM」/「A192GCM」/「A256GCM」)を使用するか、呼び出し元指定の CEK を指定して「alg=dir」を使用するか、影響を受けるアルゴリズムペアで JWE 暗号化に cjose を使用しないようにします。これらは、新しい暗号文のみに対する緩和策です。すでにゼロキーで暗号化されているデータは侵害されたままであるため、再暗号化する必要があります (含まれていた機密情報もローテーション)。


Tenable は、前述の記述ブロックを FreeBSD セキュリティアドバイザリから直接抽出しています。

Nessus はこの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

The remote Debian 13 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6499 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6499-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     September 15, 2026                    https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : cjose     CVE ID         : CVE-2026-53938 CVE-2026-53939

    Two vulnerabilities were discovered in cjose, a C library implementing     the JOSE standard, which could result in denial of service, execution of     arbitrary code or plain text recovery in specific setups.

    For the stable distribution (trixie), these problems have been fixed in     version 0.6.2.3-1+deb13u1.

    We recommend that you upgrade your cjose packages.

    For the detailed security status of cjose please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/cjose

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

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

  - OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). In versions     0.6.1 through 0.6.2.5, when cjose encrypts a JWE using an AES-CBC-HMAC content-encryption algorithm     (`A128CBC-HS256`, `A192CBC-HS384`, or `A256CBC-HS512`) together with any key-management algorithm that     generates a fresh content-encryption key (CEK), the CEK is all zero bytes instead of being randomly     generated. The resulting JWE is therefore encrypted and authenticated under a fixed, publicly known key,     so anyone who obtains the JWE can recover the plaintext and forge or modify the content. This is fixed in     version 0.6.2.6 by `_cjose_jwe_set_cek_aes_cbc()` generating the CEK from `RAND_bytes`. A regression test     asserts that the `encrypted_key` differs across two encryptions for each AES-CBC-HMAC variant. Until     upgrading, for data encrypted with cjose, three options are available. Use an AES-GCM `enc` (`A128GCM` /     `A192GCM` / `A256GCM`) instead of an AES-CBC-HMAC `enc`, use `alg=dir` with a caller-supplied CEK, or     avoid using cjose for JWE encryption with the affected algorithm pair. These are mitigations for new     ciphertexts only; data already encrypted under the zero key remains compromised and should be re-encrypted     (and any secrets it contained rotated). (CVE-2026-53939)

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

The version of FreeBSD installed on the remote host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the 3a38fdda-b05a-11f1-9369-b42e991fc52e advisory.

    https://github.com/OpenIDC/cjose/security/advisories/GHSA-f6wf-pqg3-6wqq reports:

            OpenIDC/cjose is a C library implementing the Javascript             Object Signing and Encryption (JOSE). In versions 0.6.1             through 0.6.2.5, when cjose encrypts a JWE using an             AES-CBC-HMAC content-encryption algorithm (`A128CBC-HS256`,             `A192CBC-HS384`, or `A256CBC-HS512`) together with any             key-management algorithm that generates a fresh             content-encryption key (CEK), the CEK is all zero bytes             instead of being randomly generated. The resulting JWE is             therefore encrypted and authenticated under a fixed,             publicly known key, so anyone who obtains the JWE can             recover the plaintext and forge or modify the content. This             is fixed in version 0.6.2.6 by             `_cjose_jwe_set_cek_aes_cbc()` generating the CEK from             `RAND_bytes`. A regression test asserts that the             `encrypted_key` differs across two encryptions for each             AES-CBC-HMAC variant. Until upgrading, for data encrypted             with cjose, three options are available. Use an AES-GCM             `enc` (`A128GCM` / `A192GCM` / `A256GCM`) instead of an             AES-CBC-HMAC `enc`, use `alg=dir` with a caller-supplied             CEK, or avoid using cjose for JWE encryption with the             affected algorithm pair. These are mitigations for new             ciphertexts only; data already encrypted under the zero key             remains compromised and should be             re-encrypted (and any secrets it contained rotated).


Tenable has extracted the preceding description block directly from the FreeBSD security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
344528	Linux Distros 未修補弱點：CVE-2026-53939	Nessus	Misc.	2026/9/10	2026/9/15	critical
344528	Linux Distros 未修补的漏洞：CVE-2026-53939	Nessus	Misc.	2026/9/10	2026/9/15	critical
344528	Linux Distros のパッチ未適用の脆弱性: CVE-2026-53939	Nessus	Misc.	2026/9/10	2026/9/15	critical
345680	FreeBSD:cjose:ハードコードされた暗号鍵の使用(3a38fdda-b05a-11f1-9369-b42e991fc52e)	Nessus	FreeBSD Local Security Checks	2026/9/14	2026/9/15	critical
346044	Debian dsa-6499 : libcjose-dev - security update	Nessus	Debian Local Security Checks	2026/9/15	2026/9/15	critical
344528	Linux Distros Unpatched Vulnerability : CVE-2026-53939	Nessus	Misc.	2026/9/10	2026/9/15	critical
345680	FreeBSD : cjose -- Use of Hard-coded Cryptographic Key (3a38fdda-b05a-11f1-9369-b42e991fc52e)	Nessus	FreeBSD Local Security Checks	2026/9/14	2026/9/15	critical

检测

插件搜索

critical

critical

critical

critical

critical

critical

critical