遠端主機上安裝的 OpenSSL 為 3.4.6 之前版本。因此，它會受到 3.4.6 公告中所提及的多個弱點影響。

  - 問題摘要：特製 PKCS#7 或 S/MIME 簽章訊息可能會在 PKCS#7 簽章驗證期間觸發釋放後使用。影響摘要：釋放後使用可能會導致處理程序當機、堆積損毀，或可能的遠端程式碼執行。處理 PKCS#7 或 S/MIME 簽章訊息時，如果 SignedData digestAlgorithms 欄位以空白 ASN.1 SET 形式存在，則 OpenSSL 可能會在 PKCS7_verify() 期間錯誤地釋放呼叫端擁有的 BIO。呼叫端應用程式後續使用 BIO 會導致釋放後使用狀況。在常見情況下，當應用程式稍後在最初傳遞給 PKCS7_verify() 的 BIO 上呼叫 BIO_free() 時，就會發生這種情況。視乎配置器行為和應用程式特定的 BIO 使用模式而定，這可能會導致當機或其他記憶體損毀。在某些應用程式環境中，這可能可用於遠端程式碼執行。使用 OpenSSL PKCS#7 API 處理 PKCS#7 或 S/MIME 簽章訊息的應用程式可能會受到影響。使用 CMS API 進行此處理的應用程式不受影響。4.0、3.6、3.5、3.4 和 3.0 中的 FIPS 模組不受此問題影響，因為受影響程式碼位於 OpenSSL FIPS 模組邊界之外。(CVE-2026-45447)

  - 問題摘要：當 CMS 密碼型解密 (RFC 3211/PWRI 金鑰解包) 處理攻擊者提供的 CMS 資料時，攻擊者選擇的串流模式 KEK 加密可觸發 kek_unwrap_key() 中的堆積越界讀取。影響摘要：如果輸入緩衝區在記憶體頁面界限處結束，且下一頁未對應，堆積緩衝區過度讀取可能會觸發損毀，進而導致應用程式拒絕服務。由於過度讀取的位元組不會洩露給攻擊者，因此不會洩露資訊。金鑰展開函式會執行 RFC 中指定的檢查位元組測試，該測試會根據訊息中包裝的金鑰長度，從堆積配置中讀取 7 個位元組。會根據包裝密碼的區塊長度進行最小長度檢查。不過，加密是從攻擊者的 PWRI keyEncryptionAlgorithm 中攜帶的 OID 中選取，而不要求加密必須是區塊密碼。當攻擊者選取串流模式加密時，防護將無效，而且包含未包裝金鑰的配置緩衝區可能太小，不符合 RFC 中指定的檢查位元組，進而可能導致緩衝區過度讀取。在不受信任的 CMS 資料上調用 CMS_decrypt() 或 CMS_decrypt_set1_password()
    的應用程式 (相當於 openssl cms-decrypt -pwri_password ...) 容易受到此問題的影響。不需要任何密碼知識：在任何驗證成功之前，會在嘗試展開期間發生過度讀取。過度讀取僅限於幾個位元組，不會寫入輸出，因此不會有資訊洩露。
    觸發損毀需要配置的邊界緊鄰未對應的記憶體，這對於一般配置器來說不太可能發生。FIPS 模組不受此問題影響。(CVE-2026-9076)

  - 問題摘要：在 ASN1_mbstring_ncopy() 中調整 Unicode 輸出的目標緩衝區大小時，帶正負號的整數溢位可能會導致堆積緩衝區溢位。影響摘要：堆積緩衝區溢位可能導致當機，或可能導致攻擊者控製程式碼執行或其他未定義的行為。在 ASN1_mbstring_copy() 和 ASN1_mbstring_ncopy() 中，Unicode 輸出的目標大小以帶正負號的整數計算：透過將 BMPSTRING (UTF-16) 和 UNIVERSALSTRING (UTF-32) 的輸入字元計數左移，以及將 UTF8STRING 的每個字元位元組計數相加。當輸入達到大約 2^30 個字元時，計算會溢位。在最壞的情況下 (2^30 個字元的 UNIVERSALSTRING)，大小會包裝為零，會呼叫 OPENSSL_malloc(1)，後續字元副本會在單位元組配置後面寫入幾 GB。X.509 憑證處理會透過 ASN1_STRING_set_by_NID() 路由，其 DIRSTRING_TYPE 遮罩會排除 UNIVERSALSTRING，且其對於 NID 的大小限制可限制輸入長度；OpenSSL 中沒有任何網路通訊協定或憑證處理路徑會執行溢位。觸發錯誤需要應用程式直接呼叫 ASN1_mbstring_copy() 或 ASN1_mbstring_ncopy()，或透過 ASN1_STRING_TABLE_add() 註冊自訂字串類型，且攻擊者控制的輸入的量級為半 GB 或更多。基於這些原因，我們將此問題的嚴重性指定為「低危」。4.0、3.6、3.5、3.4 和 3.0 中的 FIPS 模組不受此問題影響，因為受影響程式碼位於 OpenSSL FIPS 模組邊界之外。(CVE-2026-7383)

  - 問題摘要：AES-SIV (RFC 5297) 和 AES-GCM-SIV (RFC 8452) 的實作未正確處理具有空密文的 AAD (附加驗證資料) 的驗證，因而允許偽造此類訊息。影響摘要：攻擊者可以使用這些加密方式，向受害者的應用程式偽造帶有任意 AAD 的空白訊息。AES-SIV (RFC 5297) 和 AES-GCM-SIV (RFC 8452) 是防隨機濫用的 AEAD 模式：它們接受金鑰、隨機、選用 AAD (已驗證但未加密的位元組) 和純文字，並產生密文加上 16 位元組標籤。解密期間，只有在標籤成功驗證時，「EVP_DecryptFinal_ex()」才會記錄為傳回成功。在這些加密方式的 OpenSSL 提供者實作中，只有在使用非空白資料叫用解密函式時，才會計算預期的標籤。如果調用端提供 AAD，然後呼叫「EVP_DecryptFinal_ex()」，而不叫用加密文字更新 (當收到的加密文字長度為零時可能會發生)，則系統永遠不會重新計算標籤，且仍會保留其全零值。使用 AES-GCM-SIV 時，傳送任意 AAD、空密文和全零標籤的攻擊者會以他們不知道的任何金鑰通過身份驗證 (僅單次)。使用 AES-SIV 時，若要實現掛載攻擊，應用程式必須重複使用解密內容，而不重設金鑰。AES-SIV 是從 OpenSSL 3.0 開始實作的。AES-GCM-SIV 是從 OpenSSL 3.2 開始實作的。OpenSSL 本身 (TLS/CMS/PKCS7/HPKE/QUIC) 實作的任何通訊協定均不支援 AES-GCM-SIV 或 AES-SIV。若要實現掛載攻擊，應用程式必須實作自己的通訊協定，並使用 EVP 介面。此外，當帶有空密文的訊息到達時，他們必須跳過密文更新。4.0、3.6、3.5、3.4 和 3.0 中的 FIPS 模組不受此問題影響，因為這些演算法未經 FIPS 核准，且受影響程式碼位於 OpenSSL FIPS 模組邊界之外。(CVE-2026-45446)

  - 問題摘要：當應用程式透過公用 EVP_Cipher() 一次性介面驅動 AES-OCB 內容時，應用程式提供的初始化向量 (IV) 會以無訊息方式捨棄。影響摘要：
    不論調用者提供的 IV 為何，在相同金鑰下加密的每則訊息都會使用相同的有效隨機數，導致 (金鑰、隨機數) 重複使用和機密性遺失。如果使用相同的程式碼路徑來計算驗證標籤，則標籤僅依賴於 (key, IV) 對，而不依賴於純文字或密文，因此允許從單一擷取的訊息中全域偽造任意密文。OpenSSL 提供兩種驅動密碼的方法：記錄在案的串流介面 (EVP_CipherUpdate/EVP_CipherFinal_ex) 和較低層級的一次性 EVP_Cipher()，其文件明確建議應用程式不要使用，而應使用 EVP_CipherUpdate() 和 EVP_CipherFinal_ex()。OCB 提供者的串流處理常式會在處理資料之前，將應用程式提供的 IV 排清至 OCB 內容；一次性處理常式並無這種行為。因此，無論調用方的 IV 為何，在 AES-OCB 內容中對 EVP_Cipher() 的每次調用都會以加密初始化留下的全零鍵派生偏移狀態運行。如果隨後使用 EVP_EncryptFinal_ex() 來取得驗證標籤，則延遲的 IV 設定會在該點執行，並清除應該在純文字上累積的執行總和檢查碼。產生的標籤僅是 (key, IV) 的函數，並會針對相同 (key, IV) 對下產生的任何密文進行驗證。OpenSSL SSL/TLS 實作不受影響：AES-OCB 不是 TLS 加密套件，libssl 在任何情況下都不會呼叫 EVP_Cipher()。透過記載的串流 AEAD API (EVP_CipherUpdate/EVP_CipherFinal_ex) 驅動 AES-OCB 的應用程式不受影響。只有將 AES-OCB 加密與 EVP_Cipher() 一次性 API 結合的應用程式才容易受到攻擊。4.0、3.6、3.5、3.4 和 3.0 中的 FIPS 模組不受此問題影響，因為 AES-OCB 位於 OpenSSL FIPS 模組邊界之外。(CVE-2026-45445)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

OpenSSL 3.4.0 < 3.4.6 多個弱點

critical Nessus Plugin ID 320138

版本 1.5