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

  - Oracle MySQL 的 MySQL Server MySQL Cluster 產品中的弱點 （元件：伺服器：複製外掛程式）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60177）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：效能架構）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。容易利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致對 MySQL Server 子集、MySQL 叢集可存取資料進行未經授權的讀取存取。（CVE-2026-61081）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。易於惡意利用的弱點允許未經驗證的攻擊者登入執行 MySQL Server、MySQL Cluster 的基礎架構，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。
    (CVE-2026-60747)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - Oracle MySQL 的 MySQL Server MySQL Cluster 產品中的弱點 （元件：伺服器：X 外掛程式）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。容易利用的弱點允許未經身份驗證的攻擊者透過多種通訊協定存取網路，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL Cluster 的停擺或經常重複的損毀 （完整 DOS），以及對 MySQL Server、MySQL Cluster 可存取資料的子集進行未經授權的讀取存取。（CVE-2026-60315）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：Pluggable Auth）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許未經驗證的攻擊者登入執行 MySQL Server、MySQL 叢集的基礎架構，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致未經授權更新、插入或刪除某些 MySQL Server、MySQL 叢集可存取資料的存取權。（CVE-2026-61096）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60189）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60187）

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

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

  - Oracle MySQL 的 MySQL Server MySQL Cluster 產品中的弱點 （元件：伺服器：X 外掛程式）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。容易利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致 MySQL Server、MySQL Cluster 接管。（CVE-2026-60316）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：JSON）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。容易被利用的漏洞允許透過多種通訊協定存取網路的低權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-61109）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許高權限攻擊者登入執行 MySQL Server、MySQL 叢集的基礎架構，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致 MySQL Server、MySQL Cluster 接管。（CVE-2026-60331）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：最佳化工具）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。容易利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60145）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致 MySQL Server、MySQL Cluster 接管。（CVE-2026-60585）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：群組複製外掛程式）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;
    MySQL 叢集： 8.0.0-8.0.47、 8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。
    成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60186）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許高權限攻擊者登入執行 MySQL Server、MySQL 叢集的基礎架構，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。
    (CVE-2026-60191)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - Oracle MySQL 的 MySQL Server MySQL Cluster 產品中的弱點 （元件：伺服器：複製外掛程式）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致 MySQL Server、MySQL Cluster 接管。（CVE-2026-60178）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：群組複製外掛程式）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;
    MySQL 叢集： 8.0.0-8.0.47、 8.4.0-8.4.10 和 9.7.0-9.7.1。易於惡意利用的弱點允許未經驗證的攻擊者登入執行 MySQL Server、MySQL Cluster 的基礎架構，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致 MySQL Server、MySQL Cluster 接管。（CVE-2026-60163）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60184）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：群組複製 GCS）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集： 8.0.0-8.0.47、 8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許高權限攻擊者登入執行 MySQL Server、MySQL 叢集的基礎架構，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致 MySQL Server、MySQL Cluster 接管。（CVE-2026-60332）

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

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

  - NLTK （自然語言工具組） 之前 3.9.3 的版本在 nltk.collocations 模組中包含一個評估插入弱點，允許控制命令列引數的攻擊者執行任意 Python 程式碼。直接叫用 collocations.py 時，__main__ 區塊會將命令列引數直接傳遞給 eval（） 作為 BigramAssocMeasures 的尾碼，而無需進行允許清單驗證或清理，因此攻擊者能夠提供 Python 運算式來逸出預期的屬性查詢，並透過 OS 模組執行任意程式碼，包括作業系統命令。（CVE-2025-71408）

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

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

  - Oracle MySQL 的 MySQL Server MySQL Cluster 產品中的弱點 （元件：伺服器：複製外掛程式）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許高權限攻擊者登入執行 MySQL Server、MySQL 叢集的基礎架構，入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可導致 MySQL Server、MySQL Cluster 接管。（CVE-2026-60183）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60188）

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

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

  - Oracle MySQL 的 MySQL Server MySQL Cluster 產品中的弱點 （元件：伺服器：複製外掛程式）。受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60182）

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

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

  - MySQL Server 中的弱點，MySQL Oracle MySQL 的叢集產品 （元件：伺服器：複寫）。
    受影響的支援版本有 MySQL Server： 8.4.0-8.4.10， 9.7.0-9.7.1;MySQL 叢集：
    8.0.0-8.0.47、8.4.0-8.4.10 和 9.7.0-9.7.1。難以利用的弱點允許具有多種通訊協定存取網路的高權限攻擊者入侵 MySQL Server、MySQL Cluster。成功攻擊此弱點可能會導致未經授權的能力，導致 MySQL Server、MySQL 叢集停擺或經常重複當機 （完整 DOS）。（CVE-2026-60185）

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

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

  - Debian Linux - qemu - 無 Ubuntu Linux - [hw/9pfs：上限 Treaddir 分配] （CVE-2026-9238）

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

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

  - 在 Google go-attestation 中，輸入弱點中指定索引、位置或偏移的驗證不當。parseEfiSignatureList（） 不會在讀取項目之前將緩衝區推進超過供應商位元組。
    對於 hashSHA256SigGUID 清單，這允許將攻擊者控制的供應商標頭位元組附加到受信任 SHA256 的雜湊清單中。特製的 TPM 事件記錄可能會將任意 SHA256 雜湊注入驗證者的受信任測量資料庫，使遠端證明驗證者能夠接受受損的啟動狀態。
    此問題會影響 go-attestation：透過 0.6.0。（CVE-2026-12681）

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

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

  - 在 QEMU 的VNC伺服器實作 （ui/vnc.c） 中，set_pixel_format（） 函式無法正確驗證用戶端 SetPixelFormat 訊息中的 red_max、green_max 和 blue_max 欄位。這些欄位會以 16 位元值接收，但在內部儲存為 uint8_t。惡意 VNC 用戶端可傳送超過 255 的最大值 （例如 0x0100），該值會通過現有的非零驗證檢查，但在指派時會無訊息地截斷為 0，導致 Tight PNG 調色板編碼路徑中除以零。這允許遠端攻擊者損毀 QEMU 處理程序，導致該 QEMU 執行個體所服務的所有客體遭到拒絕服務。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-15578） 在 QEMU 的 USB 重新導向 （usbredir） 實作中，hw/usb/redirect.c 中的 usbredir_buffered_bulk_packet（） 函式中存在釋放後使用弱點。處理分割成最大封包大小區塊的多片段緩衝大量封包時，只有最終片段擁有共用剖析器記憶體配置 （透過 free_on_destroy）。如果 bufp_alloc（）由於佇列溢位而刪除最終片段，則會釋放支援緩衝區，而先前已排入佇列的片段仍保留內部指標。然後，後續客體大量傳入會從釋放的堆積記憶體讀取。惡意或受損的 USB 裝置 （或特製的 usbredir 串流） 可能會觸發此狀況，進而可能導致堆積記憶體的資訊洩露或 QEMU 處理程序崩潰 （拒絕服務）。此弱點自 QEMU v1.4.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修正。（CVE-2026-15705） 追蹤背景工作執行緒中有損矩形時，界限條件的錯誤計算會導致 OOB 寫入，進而損毀進一步的背景工作狀態，和/或觸發可能位於 VncWorker 結構之外的任何保護頁面。這可以透過無特權使用者仔細選擇客體作業系統中的顯示解析度來觸發。（CVE-2026-48002） vnc_update_freq中的迴圈邊界不正確會導致反覆運算超過最後一列，並越過 VNC stats 陣列中的最後一列。
    使用適當選擇的維度，這可能是 OOB 讀取，可存取內嵌統計資料陣列所在 VncDisplay 結構以外的記憶體。如果這擊中保護頁面，可能會觸發訪客崩潰。如果沒有，則 VNC 頻率統計資料將使用垃圾更新。（CVE-2026-48003） 在 QEMU 的 VNC 伺服器實作 （ui/vnc.c） 中，vnc_refresh_lossy_rect（） 函式在有損圖塊重新整理期間標記已變更點陣圖列時，包含越界寫入弱點。此函式會無條件地為每個圖塊標示已變更點陣圖的完整 VNC_STAT_RECT （64） 列。當顯示高度不是 64 像素的倍數時，最後一個磚列是部分磚，而迴圈會寫入 vs->dirty[VNC_MAX_HEIGHT] 陣列的結尾。例如，使用 2160 像素高的顯示器，最後一個統計資料磚從 y=2112 開始，而 64 列迴圈寫入列 2112-2175，將 16 列 （640 位元組） 溢位，越過已變更點陣圖進入後續 VncState 欄位。惡意 VNC 用戶端可能會利用此堆積緩衝區溢位，該用戶端協商特定的顯示解析度以損毀 QEMU 處理程序記憶體，從而導致拒絕服務或可能執行任意程式碼。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-61475） 在 QEMU 的 USB 重新導向 （usbredir） 實作 （hw/usb/redirect.c） 中，惡意 usbredir 對等體可以傳送 ep_info 訊息，在大量接收已經開始後，將 max_packet_size 重設為 0。這會導致多種可利用的條件：（1） usbredir_buffered_bulk_packet（） 中的無限循環，其中分割循環遞增 max_packet_size （0） 並且從未進展，（2） usbredir_buffered_bulk_in_complete_ftdi（） 中的 SIGFPE（浮點異常）來自模除以零運算，以及 （3） usbredir_handle_buffered_bulk_in_data（） 中的 SIGFPE，在計算bytes_per_transfer時從除以零。惡意的 USB 重新導向對等體可以利用此漏洞使 QEMU 處理程序當機 （拒絕服務） 或導致其無限期停擺。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-63319） 在 QEMU 的 9pfs （virtio-9p） 實作中，TXATTRCREATE 和 TXATTRWALK 要求處理常式不會限制同時開啟的 xattr FID 的數量。每個 xattr FID 都會為擴充屬性值配置主機記憶體緩衝區。具有直接 9p 伺服器存取權的惡意特權訪客使用者可以透過重複建立 xattr FID 而不關閉它們來利用這一點，從而導致無限的主機記憶體消耗和最終的主機記憶體耗盡 （拒絕服務）。此弱點自 QEMU v0.14.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修復。（CVE-2026-8348） 在虛擬化管理程式主機環境 （例如 QEMU） 上，v4.9.2 之前 freedesktop.org libslirp 版本的 TCP 緊急資料處理 （sosendoob） 中的越界堆積讀取和整數反向溢位，允許特權客體虛擬機器攻擊者 （root 或 CAP_NET_RAW） 透過傳送帶有操縱的 URG 旗標和緊急指標 （ti_urp） 的特製 TCP 區段，洩漏 GB 的敏感主機處理堆記憶體。（CVE-2026-9539）CVE-2026-15578 （）

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

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

  - ImageMagick 之前在 magick 命令 7.1.2-27 列介面中包含提供無效選項時的記憶體洩漏弱點。攻擊者可藉由重複提供格式錯誤的命令列引數來耗用系統資源，以觸發記憶體耗盡。（CVE-2026-66011）

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

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

  - 在 QEMU 的VNC伺服器實作 （ui/vnc.c） 中，set_pixel_format（） 函式無法正確驗證用戶端 SetPixelFormat 訊息中的 red_max、green_max 和 blue_max 欄位。這些欄位會以 16 位元值接收，但在內部儲存為 uint8_t。惡意 VNC 用戶端可傳送超過 255 的最大值 （例如 0x0100），該值會通過現有的非零驗證檢查，但在指派時會無訊息地截斷為 0，導致 Tight PNG 調色板編碼路徑中除以零。這允許遠端攻擊者損毀 QEMU 處理程序，導致該 QEMU 執行個體所服務的所有客體遭到拒絕服務。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-15578） 在 QEMU 的 USB 重新導向 （usbredir） 實作中，hw/usb/redirect.c 中的 usbredir_buffered_bulk_packet（） 函式中存在釋放後使用弱點。處理分割成最大封包大小區塊的多片段緩衝大量封包時，只有最終片段擁有共用剖析器記憶體配置 （透過 free_on_destroy）。如果 bufp_alloc（）由於佇列溢位而刪除最終片段，則會釋放支援緩衝區，而先前已排入佇列的片段仍保留內部指標。然後，後續客體大量傳入會從釋放的堆積記憶體讀取。惡意或受損的 USB 裝置 （或特製的 usbredir 串流） 可能會觸發此狀況，進而可能導致堆積記憶體的資訊洩露或 QEMU 處理程序崩潰 （拒絕服務）。此弱點自 QEMU v1.4.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修正。（CVE-2026-15705） 追蹤背景工作執行緒中有損矩形時，界限條件的錯誤計算會導致 OOB 寫入，進而損毀進一步的背景工作狀態，和/或觸發可能位於 VncWorker 結構之外的任何保護頁面。這可以透過無特權使用者仔細選擇客體作業系統中的顯示解析度來觸發。（CVE-2026-48002） vnc_update_freq中的迴圈邊界不正確會導致反覆運算超過最後一列，並越過 VNC stats 陣列中的最後一列。
    使用適當選擇的維度，這可能是 OOB 讀取，可存取內嵌統計資料陣列所在 VncDisplay 結構以外的記憶體。如果這擊中保護頁面，可能會觸發訪客崩潰。如果沒有，則 VNC 頻率統計資料將使用垃圾更新。（CVE-2026-48003） 在 QEMU 的 VNC 伺服器實作 （ui/vnc.c） 中，vnc_refresh_lossy_rect（） 函式在有損圖塊重新整理期間標記已變更點陣圖列時，包含越界寫入弱點。此函式會無條件地為每個圖塊標示已變更點陣圖的完整 VNC_STAT_RECT （64） 列。當顯示高度不是 64 像素的倍數時，最後一個磚列是部分磚，而迴圈會寫入 vs->dirty[VNC_MAX_HEIGHT] 陣列的結尾。例如，使用 2160 像素高的顯示器，最後一個統計資料磚從 y=2112 開始，而 64 列迴圈寫入列 2112-2175，將 16 列 （640 位元組） 溢位，越過已變更點陣圖進入後續 VncState 欄位。惡意 VNC 用戶端可能會利用此堆積緩衝區溢位，該用戶端協商特定的顯示解析度以損毀 QEMU 處理程序記憶體，從而導致拒絕服務或可能執行任意程式碼。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-61475） 在 QEMU 的 USB 重新導向 （usbredir） 實作 （hw/usb/redirect.c） 中，惡意 usbredir 對等體可以傳送 ep_info 訊息，在大量接收已經開始後，將 max_packet_size 重設為 0。這會導致多種可利用的條件：（1） usbredir_buffered_bulk_packet（） 中的無限循環，其中分割循環遞增 max_packet_size （0） 並且從未進展，（2） usbredir_buffered_bulk_in_complete_ftdi（） 中的 SIGFPE（浮點異常）來自模除以零運算，以及 （3） usbredir_handle_buffered_bulk_in_data（） 中的 SIGFPE，在計算bytes_per_transfer時從除以零。惡意的 USB 重新導向對等體可以利用此漏洞使 QEMU 處理程序當機 （拒絕服務） 或導致其無限期停擺。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-63319） 在 QEMU 的 9pfs （virtio-9p） 實作中，TXATTRCREATE 和 TXATTRWALK 要求處理常式不會限制同時開啟的 xattr FID 的數量。每個 xattr FID 都會為擴充屬性值配置主機記憶體緩衝區。具有直接 9p 伺服器存取權的惡意特權訪客使用者可以透過重複建立 xattr FID 而不關閉它們來利用這一點，從而導致無限的主機記憶體消耗和最終的主機記憶體耗盡 （拒絕服務）。此弱點自 QEMU v0.14.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修復。（CVE-2026-8348） 在虛擬化管理程式主機環境 （例如 QEMU） 上，v4.9.2 之前 freedesktop.org libslirp 版本的 TCP 緊急資料處理 （sosendoob） 中的越界堆積讀取和整數反向溢位，允許特權客體虛擬機器攻擊者 （root 或 CAP_NET_RAW） 透過傳送帶有操縱的 URG 旗標和緊急指標 （ti_urp） 的特製 TCP 區段，洩漏 GB 的敏感主機處理堆記憶體。（CVE-2026-9539）CVE-2026-8348 （）

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

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

  - Debian Linux - qemu - 無 Ubuntu Linux - QEMU xHCI 中斷器 暫存器 OOB 存取 （非預設設定） （CVE-2026-16043）

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

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

  - 在 QEMU 的VNC伺服器實作 （ui/vnc.c） 中，set_pixel_format（） 函式無法正確驗證用戶端 SetPixelFormat 訊息中的 red_max、green_max 和 blue_max 欄位。這些欄位會以 16 位元值接收，但在內部儲存為 uint8_t。惡意 VNC 用戶端可傳送超過 255 的最大值 （例如 0x0100），該值會通過現有的非零驗證檢查，但在指派時會無訊息地截斷為 0，導致 Tight PNG 調色板編碼路徑中除以零。這允許遠端攻擊者損毀 QEMU 處理程序，導致該 QEMU 執行個體所服務的所有客體遭到拒絕服務。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-15578） 在 QEMU 的 USB 重新導向 （usbredir） 實作中，hw/usb/redirect.c 中的 usbredir_buffered_bulk_packet（） 函式中存在釋放後使用弱點。處理分割成最大封包大小區塊的多片段緩衝大量封包時，只有最終片段擁有共用剖析器記憶體配置 （透過 free_on_destroy）。如果 bufp_alloc（）由於佇列溢位而刪除最終片段，則會釋放支援緩衝區，而先前已排入佇列的片段仍保留內部指標。然後，後續客體大量傳入會從釋放的堆積記憶體讀取。惡意或受損的 USB 裝置 （或特製的 usbredir 串流） 可能會觸發此狀況，進而可能導致堆積記憶體的資訊洩露或 QEMU 處理程序崩潰 （拒絕服務）。此弱點自 QEMU v1.4.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修正。（CVE-2026-15705） 追蹤背景工作執行緒中有損矩形時，界限條件的錯誤計算會導致 OOB 寫入，進而損毀進一步的背景工作狀態，和/或觸發可能位於 VncWorker 結構之外的任何保護頁面。這可以透過無特權使用者仔細選擇客體作業系統中的顯示解析度來觸發。（CVE-2026-48002） vnc_update_freq中的迴圈邊界不正確會導致反覆運算超過最後一列，並越過 VNC stats 陣列中的最後一列。
    使用適當選擇的維度，這可能是 OOB 讀取，可存取內嵌統計資料陣列所在 VncDisplay 結構以外的記憶體。如果這擊中保護頁面，可能會觸發訪客崩潰。如果沒有，則 VNC 頻率統計資料將使用垃圾更新。（CVE-2026-48003） 在 QEMU 的 VNC 伺服器實作 （ui/vnc.c） 中，vnc_refresh_lossy_rect（） 函式在有損圖塊重新整理期間標記已變更點陣圖列時，包含越界寫入弱點。此函式會無條件地為每個圖塊標示已變更點陣圖的完整 VNC_STAT_RECT （64） 列。當顯示高度不是 64 像素的倍數時，最後一個磚列是部分磚，而迴圈會寫入 vs->dirty[VNC_MAX_HEIGHT] 陣列的結尾。例如，使用 2160 像素高的顯示器，最後一個統計資料磚從 y=2112 開始，而 64 列迴圈寫入列 2112-2175，將 16 列 （640 位元組） 溢位，越過已變更點陣圖進入後續 VncState 欄位。惡意 VNC 用戶端可能會利用此堆積緩衝區溢位，該用戶端協商特定的顯示解析度以損毀 QEMU 處理程序記憶體，從而導致拒絕服務或可能執行任意程式碼。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-61475） 在 QEMU 的 USB 重新導向 （usbredir） 實作 （hw/usb/redirect.c） 中，惡意 usbredir 對等體可以傳送 ep_info 訊息，在大量接收已經開始後，將 max_packet_size 重設為 0。這會導致多種可利用的條件：（1） usbredir_buffered_bulk_packet（） 中的無限循環，其中分割循環遞增 max_packet_size （0） 並且從未進展，（2） usbredir_buffered_bulk_in_complete_ftdi（） 中的 SIGFPE（浮點異常）來自模除以零運算，以及 （3） usbredir_handle_buffered_bulk_in_data（） 中的 SIGFPE，在計算bytes_per_transfer時從除以零。惡意的 USB 重新導向對等體可以利用此漏洞使 QEMU 處理程序當機 （拒絕服務） 或導致其無限期停擺。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-63319） 在 QEMU 的 9pfs （virtio-9p） 實作中，TXATTRCREATE 和 TXATTRWALK 要求處理常式不會限制同時開啟的 xattr FID 的數量。每個 xattr FID 都會為擴充屬性值配置主機記憶體緩衝區。具有直接 9p 伺服器存取權的惡意特權訪客使用者可以透過重複建立 xattr FID 而不關閉它們來利用這一點，從而導致無限的主機記憶體消耗和最終的主機記憶體耗盡 （拒絕服務）。此弱點自 QEMU v0.14.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修復。（CVE-2026-8348） 在虛擬化管理程式主機環境 （例如 QEMU） 上，v4.9.2 之前 freedesktop.org libslirp 版本的 TCP 緊急資料處理 （sosendoob） 中的越界堆積讀取和整數反向溢位，允許特權客體虛擬機器攻擊者 （root 或 CAP_NET_RAW） 透過傳送帶有操縱的 URG 旗標和緊急指標 （ti_urp） 的特製 TCP 區段，洩漏 GB 的敏感主機處理堆記憶體。（CVE-2026-9539）CVE-2026-61475 （）

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

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

  - seunshare of selinux policycoreutils 中的一個 Time-of-check Time-of-use （TOCTOU） 爭用情形弱點，允許呼叫在不受限制的 SELinux 網域中執行的 seunshare 的使用者刪除任意 root 擁有的檔案，此問題會透過 3.10影響 policycoreutils。（CVE-2026-59676）

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

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

  - Unity Link 公告 UTSA-2026-124431 （CVE-2026-15705） （CVE-2026-15705）

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

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

  - 在 QEMU 的VNC伺服器實作 （ui/vnc.c） 中，set_pixel_format（） 函式無法正確驗證用戶端 SetPixelFormat 訊息中的 red_max、green_max 和 blue_max 欄位。這些欄位會以 16 位元值接收，但在內部儲存為 uint8_t。惡意 VNC 用戶端可傳送超過 255 的最大值 （例如 0x0100），該值會通過現有的非零驗證檢查，但在指派時會無訊息地截斷為 0，導致 Tight PNG 調色板編碼路徑中除以零。這允許遠端攻擊者損毀 QEMU 處理程序，導致該 QEMU 執行個體所服務的所有客體遭到拒絕服務。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-15578） 在 QEMU 的 USB 重新導向 （usbredir） 實作中，hw/usb/redirect.c 中的 usbredir_buffered_bulk_packet（） 函式中存在釋放後使用弱點。處理分割成最大封包大小區塊的多片段緩衝大量封包時，只有最終片段擁有共用剖析器記憶體配置 （透過 free_on_destroy）。如果 bufp_alloc（）由於佇列溢位而刪除最終片段，則會釋放支援緩衝區，而先前已排入佇列的片段仍保留內部指標。然後，後續客體大量傳入會從釋放的堆積記憶體讀取。惡意或受損的 USB 裝置 （或特製的 usbredir 串流） 可能會觸發此狀況，進而可能導致堆積記憶體的資訊洩露或 QEMU 處理程序崩潰 （拒絕服務）。此弱點自 QEMU v1.4.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修正。（CVE-2026-15705） 追蹤背景工作執行緒中有損矩形時，界限條件的錯誤計算會導致 OOB 寫入，進而損毀進一步的背景工作狀態，和/或觸發可能位於 VncWorker 結構之外的任何保護頁面。這可以透過無特權使用者仔細選擇客體作業系統中的顯示解析度來觸發。（CVE-2026-48002） vnc_update_freq中的迴圈邊界不正確會導致反覆運算超過最後一列，並越過 VNC stats 陣列中的最後一列。
    使用適當選擇的維度，這可能是 OOB 讀取，可存取內嵌統計資料陣列所在 VncDisplay 結構以外的記憶體。如果這擊中保護頁面，可能會觸發訪客崩潰。如果沒有，則 VNC 頻率統計資料將使用垃圾更新。（CVE-2026-48003） 在 QEMU 的 VNC 伺服器實作 （ui/vnc.c） 中，vnc_refresh_lossy_rect（） 函式在有損圖塊重新整理期間標記已變更點陣圖列時，包含越界寫入弱點。此函式會無條件地為每個圖塊標示已變更點陣圖的完整 VNC_STAT_RECT （64） 列。當顯示高度不是 64 像素的倍數時，最後一個磚列是部分磚，而迴圈會寫入 vs->dirty[VNC_MAX_HEIGHT] 陣列的結尾。例如，使用 2160 像素高的顯示器，最後一個統計資料磚從 y=2112 開始，而 64 列迴圈寫入列 2112-2175，將 16 列 （640 位元組） 溢位，越過已變更點陣圖進入後續 VncState 欄位。惡意 VNC 用戶端可能會利用此堆積緩衝區溢位，該用戶端協商特定的顯示解析度以損毀 QEMU 處理程序記憶體，從而導致拒絕服務或可能執行任意程式碼。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-61475） 在 QEMU 的 USB 重新導向 （usbredir） 實作 （hw/usb/redirect.c） 中，惡意 usbredir 對等體可以傳送 ep_info 訊息，在大量接收已經開始後，將 max_packet_size 重設為 0。這會導致多種可利用的條件：（1） usbredir_buffered_bulk_packet（） 中的無限循環，其中分割循環遞增 max_packet_size （0） 並且從未進展，（2） usbredir_buffered_bulk_in_complete_ftdi（） 中的 SIGFPE（浮點異常）來自模除以零運算，以及 （3） usbredir_handle_buffered_bulk_in_data（） 中的 SIGFPE，在計算bytes_per_transfer時從除以零。惡意的 USB 重新導向對等體可以利用此漏洞使 QEMU 處理程序當機 （拒絕服務） 或導致其無限期停擺。在 QEMU v11.0.3 和 v10.0.12 中修正。（CVE-2026-63319） 在 QEMU 的 9pfs （virtio-9p） 實作中，TXATTRCREATE 和 TXATTRWALK 要求處理常式不會限制同時開啟的 xattr FID 的數量。每個 xattr FID 都會為擴充屬性值配置主機記憶體緩衝區。具有直接 9p 伺服器存取權的惡意特權訪客使用者可以透過重複建立 xattr FID 而不關閉它們來利用這一點，從而導致無限的主機記憶體消耗和最終的主機記憶體耗盡 （拒絕服務）。此弱點自 QEMU v0.14.0-rc0 以來一直存在，並在 v11.0.3 和 v10.0.12 中修復。（CVE-2026-8348） 在虛擬化管理程式主機環境 （例如 QEMU） 上，v4.9.2 之前 freedesktop.org libslirp 版本的 TCP 緊急資料處理 （sosendoob） 中的越界堆積讀取和整數反向溢位，允許特權客體虛擬機器攻擊者 （root 或 CAP_NET_RAW） 透過傳送帶有操縱的 URG 旗標和緊急指標 （ti_urp） 的特製 TCP 區段，洩漏 GB 的敏感主機處理堆記憶體。（CVE-2026-9539）CVE-2026-63319 （）

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

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

  - Redis 之前 8.8.0，在經過驗證的攻擊者可以執行 RESTORE 的不尋常情況下，允許透過 RESTORE 承載執行遠端程式碼，其中多個消費者參照相同的 NACK （擱置項目），因為透過 XGROUP DELCONSUMER 刪除兩個消費者會導致雙重釋放。注意：此問題之所以存在，是因為 CVE-2026-25243 的修正不完整。(CVE-2026-66373)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - net：nexthop：增加權重至 u16 在 CLOS 網路中，當網路中的各個點發生鏈路故障時，會調整相關節點的 ECMP 權重以進行補償。由於相關節點的扇出率很高，而且節點數量總數較多，因此我們想要設定的 （非） ECMP 權重比不適合 8 位元。我們可能想要配置類似 1000:999的 ，而不是 255:254。對於這些部署，8 位元權重可能不夠。為此，在此補丁中，將下一跳權重從 u8 增加到 u16。增加整數類型的寬度可能很棘手，因為當程式碼仍在編譯時，類型可能不再簽出，並且會出現數值錯誤。為了防止這種情況發生，轉換分兩個步驟完成。首先，類型從 u8 更改為單成員結構，這使得該字段的所有用途都無效。這允許逐一檢查它們並審核類型正確性。然後該結構再次被香草 u16 取代。這應該確保不會錯過任何位置。用於設定 nexthop 群組成員的 UAPI 是屬性NHA_GROUP攜帶結構nexthop_grp項目陣列： struct nexthop_grp { __u32 id; /* nexthop id - 必須存在 */ __u8權重;
    /* 此 nexthop 的權重 */ __u8 resvd1;__u16 resvd2;};欄位 resvd1 目前已驗證，且必須為零。我們可以提升此要求，並在保留欄位中攜帶權重的高階位元： struct nexthop_grp { __u32 id; /* nexthop id - 必須存在 */ __u8權重; /* 此 nexthop 的權重
    */ __u8 weight_high;__u16 resvd2;};選擇以這種方式分割欄位是為了防止現有使用者空間對權重欄位的寬度做出假設，並避免任何字節碼問題。
    權重欄位目前編碼為權重值減一，因為權重 0 無效。同樣的技巧對於新的weight_high場來說是不可能的，因為零必須意味著實際的零。有了這個： - 保證舊使用者空間承載 0 的weight_high，因此請視需要配置 8 位元權重。轉儲具有 16 位權重的 nexthop 時，它只會顯示較低的 8 位。但配置此類 nexthop 意味著首先存在意識到擴展的用戶空間。- 只要新使用者空間僅嘗試設定 8 位元權重（其中高階位元為零），即可與舊核心通訊。舊核心會退回設定 >8 位元權重的嘗試。在 Linux 中，通常會在為某些目的分配保留欄位時重新命名保留欄位。任何接觸保留場地的人都將自行承擔風險。特別是 nexthop_grp：：resvd1 目前至少由 strace 使用，但是它們帶有自己的 UAPI 標頭副本，並且轉換應該是微不足道的。提供了一個輔助程式來解碼兩個字段的權重。強制轉換似乎比向後彎曲並引入匿名聯合或其他什麼更可取。（CVE-2024-14040）

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

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

  - net/sched： cls_api：當碎片整理引擎保留 skb 時，tcf_qevent_handle tcf_classify（） 中的處理TC_ACT_CONSUMED可以傳回TC_ACT_CONSUMED （例如，act_ct無序片段）。發生這種情況時，skb 不再屬於呼叫者所有，不得再次觸摸。tcf_qevent_handle（） 未處理TC_ACT_CONSUMED：它通過交換器並將 skb 返回給調用方，就好像分類已通過一樣。今天唯一連接 qevents 的 qdisc 是 RED，通過三個調用站點（RED_PROB_MARK/HARD_MARK 上的 qe_mark，congestion_drop 上的qe_early_drop）red_enqueue（） 繼續在它不再擁有的 skb 上運行——將其排入隊列、刪除它或更新統計數據。
    導致 UAF。tc qdisc 新增 dev eth0 根控點 1：紅色 ...qevent early_drop區塊 10 tc 篩選器 新增區塊 10 ...動作 CT （啟用 CT 碎片整理和產生無序片段的流量，例如片段化的 UDP 資料流） 處理 tcf_qevent_handle（） 中的TC_ACT_CONSUMED，就像輸入和輸出快速路徑一樣：將其視為被盜，並在不接觸 skb 的情況下傳回 NULL。與TC_ACT_STOLEN情況不同，skb 不得在這裡丟棄/釋放，因為它不再屬於我們所有。（CVE-2026-64530）

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

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

  - 在轉寄訊息時剖析 MIME 標頭以供顯示的程式碼 （如果啟用了檢視所有標頭的設定） 出現差一錯誤，允許在標頭緩衝區之後的記憶體中讀取單一位元組，並可能使 Thunderbird 當機。此漏洞已在 Thunderbird 153 和 Thunderbird 140.13中修復。（CVE-2026-14899）

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

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

  - netfilter： ebtables：模組名稱必須以 null 終止我們需要明確檢查長度，否則我們可能會將非 null 終止的字串傳遞給 request_module（）。（CVE-2026-64412）

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

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

  - udf：根據 VAT inode 大小驗證 VAT 標頭長度 udf_load_vat（） 會直接從磁碟上的 VAT 2.0 標頭取得虛擬分割區的起始偏移量，而不針對 VAT inode 大小進行檢查：
    map->s_type_specific.s_virtual.s_start_offset = le16_to_cpu（vat20->lengthHeader）;
    map->s_type_specific.s_virtual.s_num_entries = （sbi->s_vat_inode->i_size - map->s_type_specific.s_virtual.s_start_offset） >> 2;lengthHeader 是一個完全由攻擊者控制的 16 位元值。如果它超過 VAT inode 大小，則s_num_entries減法將下溢到一個巨大的計數，這會破壞 udf_get_pblock_virt15（） 中> s_num_entries限制的區塊;在 ICB 內聯路徑上，該函數讀取 （（__le32 *）（iinfo->i_data + s_start_offset））[block]，因此大量s_start_offset索引超過 inode 的 ICB 內資料。然後，使用虛擬 （VAT） 分割區掛載特製的 UDF 映像檔會觸發越界讀取。拒絕標頭長度未為 VAT inode 內至少一個項目留出空間的 VAT。（CVE-2026-64323）

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

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

  - 藍牙：btusb：修正 marvell 探查失敗的釋放後使用 請務必在稍後的探查失敗時停止在 Marvell OOB 喚醒設定期間提交的任何 TX URB，以避免在完成回呼中發生釋放後使用。此問題是由 Sashiko 在檢閱 btusb 探查錯誤路徑中喚醒來源洩漏的修正時報告的。（CVE-2026-64470）

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

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

  - ACPI： NFIT： core：修正 acpi_nfit_init（） 錯誤清除 如果 acpi_nfit_init（） 在將 acpi_desc 物件新增至acpi_descs清單後失敗，則永遠不會從該清單中移除該物件，因為在此情況下，不會為 NFIT 裝置新增 acpi_nfit_shutdown（） devm 動作。接下來，acpi_nfit_init（） 失敗導致 acpi_nfit_probe（） 失敗，acpi_desc物件被釋放，並且acpi_descs中留下一個懸空指標。任何後續的 ACPI 電腦檢查例外狀況都會觸發 nfit_handle_mce（），反覆運算 acpi_descs，因此會發生釋放後使用。此外，如果 acpi_nfit_probe（） 在為 NFIT 裝置安裝通知處理常式後傳回 0，且未配置 acpi_desc 物件並設定 NFIT 裝置的驅動程式資料指標，則 acpi_desc 物件將由 acpi_nfit_update_notify（） 分配，並呼叫 acpi_nfit_init（） 來初始化它。在此情況下，無論 acpi_nfit_init（） 是否失敗，都不會為 NFIT 裝置新增 acpi_nfit_shutdown（） devm 動作，也永遠不會從acpi_descs清單中移除acpi_desc。如果acpi_desc物件隨後在驅動程式移除時釋放，則任何後續的 ACPI MCE 都會導致釋放後使用，如前一種案例所示。若要解決上述第一個問題，請在 acpi_nfit_init（） 失敗時直接進行 acpi_nfit_probe（） 呼叫 acpi_nfit_shutdown（），若要解決另一個問題，請將移除回呼新增至驅動程式，並使其呼叫 acpi_nfit_shutdown（） 。此外，由於現在可以將 NULL 傳遞給 acpi_nfit_shutdown（），或者傳給它的acpi_desc物件可能尚未初始化，因此請將 acpi_desc 及其nvdimm_bus欄位的 NULL 檢查新增至該函式，並在取消註冊 NVDIMM 匯流排後使 acpi_nfit_unregister（） 清除後者。CVE-2026-64510

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

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

  - 藍牙：btusb：修正註冊失敗時的釋放後使用 確保釋放同級介面，以防控制器註冊失敗，以避免在最終中斷連線時發生釋放後使用和雙重釋放。此問題是由 Sashiko 在檢閱 btusb 探查錯誤路徑中喚醒來源洩漏的修正時報告的。（CVE-2026-64471）

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

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

  - 已解決 Linux 核心中的下列弱點：PCI/IOV: Skip VF Resizable BAR restore on read error sriov_restore_vf_rebar_state() uses the VF Resizable BAR Control register to decide how many VF BARs to restore (nbars) and which VF BAR each iteration addresses (bar_idx). bar_idx indexes into dev->sriov->barsz[], which has only PCI_SRIOV_NUM_BARS (6) entries. When a device does not respond, config reads typically return PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx both evaluate to 7. The barsz[] access then goes out of bounds. UBSAN reports this as: UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51 index 7 is out of range for type 'resource_size_t [6]' Observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that stopped responding during a failed GC6 power state exit. The subsequent pci_restore_state() invoked sriov_restore_vf_rebar_state() while config reads returned 0xffffffff, triggering the splat. Bail out if any VF Resizable BAR Control read returns PCI_ERROR_RESPONSE. No further VF BARs are touched, which is safe because a config read that returns PCI_ERROR_RESPONSE indicates the device is unreachable and restoration is pointless. This mirrors the guard in pci_restore_rebar_state(). (CVE-2026-64460)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - 已解決 Linux 核心中的下列弱點：mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host lookup_swap_cgroup_id() passes swap_cgroup_ctrl[type].map to
    __swap_cgroup_id_lookup() without checking that the type was ever registered via swap_cgroup_swapon(). On a swapless host every ctrl->map is NULL, so __swap_cgroup_id_lookup() dereferences NULL + a scaled swp_offset(). Since commit bea67dcc5eea (mm: attempt to batch free swap entries for zap_pte_range()), zap_pte_range() -> swap_pte_batch() calls lookup_swap_cgroup_id() on any non-present, non-none PTE that decodes as a real swap entry, without first validating it against swap_info[]. A single PTE corrupted into a type-0 swap entry takes the host down at process exit. We hit this in production on a swapless 6.12.58 host: ~1s of get_swap_device: Bad swap file entry 3f800204222bb (do_swap_page() being correctly defensive about the same entry) followed by BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookup_swap_cgroup_id+0x2b/0x60 Call Trace: swap_pte_batch+0xbf/0x230 zap_pte_range+0x4c8/0x780 unmap_page_range+0x190/0x3e0 exit_mmap+0xd9/0x3c0 do_exit+0x20c/0x4b0 syzbot has reported the identical stack. The source of the PTE corruption is a separate bug; this change makes the teardown path as robust as the fault path already is. Every other caller of lookup_swap_cgroup_id() is downstream of a get_swap_device() that has already validated the entry, so the new branch is cold. (CVE-2026-64416)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - ALSA： ice1712：檢查 snd_ctl_new1（） 傳回值 snd_ctl_new1（） 可以在記憶體配置失敗時傳回 NULL。ice1712 驅動程式在多個位置 （ice1712.c、ice1724.c、aureon.c） 取消參照指標之前，會呼叫 snd_ctl_new1（），而不檢查傳回值，這可能會導致 NULL 指標解除參照。
    在 snd_ctl_new1（） 呼叫後新增 NULL 檢查，如果有失敗，則傳回 -ENOMEM。（CVE-2026-64480）

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

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

  - KVM：arm64：排清 pKVM hyp vCPU 時綁定used_lrs flush_hyp_vcpu（） 會在每次執行時將主機 vGIC 狀態複製到 hyp 的私有 vCPU 中。vGIC 清單暫存器儲存及還原會使用 used_lrs 作為其迴圈界限，並預期它會保持在實作清單暫存器的數目內。雖然通常是這種情況，但 flush_hyp_vcpu（） 逐字複製vgic_v3並且不會強制執行此操作，因此主機提供的值在 EL2 上用於索引 vgic_lr[] 和存取 ICH_LR<n>_EL2 （主機 -> EL2）。透過將used_lrs限制在複製後實作的清單暫存器數量來修正，就像受信任路徑在 vgic_flush_lr_state（） 中已經做的那樣。實作清單暫存器的數量在初始化後是恆定的，因此它會從 kvm_vgic_global_state.nr_lr 複製一次到hyp_gicv3_nr_lr，而不是在每個項目上讀取。
    (CVE-2026-64287)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - 已解決 Linux 核心中的下列弱點：netfilter: flowtable: IPIP tunnel hardware offload is not yet support No driver supports for IPIP tunnels yet, give up early on setting up the hardware offload for this scenario. This patch adds a stub that can be enhanced to add more configuration that are currently not supported. As of now, the offload work is enqueued to the worker, then ignored if the hardware offload configuration is not supported. Check the NF_FLOW_HW flag to know if this entry was already tried once to be offloaded so this is not retried on refresh when unsupported. Move NF_FLOW_HW flag check to nf_flow_offload_add(). If this NF_FLOW_HW flag is unset the _del and _stats variants are never called. This can be updated later on to skip hardware offload work to be queued in case hardware offload does not support it. (CVE-2026-64410)

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

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

  - mm： shrinker：修正shrinker_info拆卸爭用，擴充 expand_shrinker_info（） 會反覆運算 shrinker_mutex 下所有可見的 memcg，包括尚未完成 ->css_online（） 的 memcg。一旦 pn->shrinker_info 發布，拆卸必須保持使用 expand_shrinker_info（） 序列化，直到該 memcg 完全在線或不再對迭代可見。今天 alloc_shrinker_info（） 打破了該規則，在釋放部分初始化的 shrinker_info 陣列之前刪除了 shrinker_mutex，這可能會導致以下爭用： CPU0 CPU1 ==== ==== css_create --> list_add_tail_rcu（&css->sibling， &parent_css->children）;online_css --> mem_cgroup_css_online --> alloc_shrinker_info --> alloc node0 info rcu_assign_pointer（C->node0->shrinker_info， old0） alloc node1 info -> FAIL -> goto err mutex_unlock（shrinker_mutex） shrinker_alloc（） --> shrinker_memcg_alloc --> mutex_lock（shrinker_mutex） expand_shrinker_info --> mem_cgroup_iter 查看 memcg expand_one_shrinker_info --> old0 = C->node0->shrinker_info memcpy（new->unit， old0->單位，...）;free_shrinker_info --> kvfree（old0）;/* 雙倍免費！！*/ kvfree_rcu（old0， rcu）;後面的 mem_cgroup_css_online（） 中也存在同樣的問題。如果 alloc_shrinker_info（） 成功，但後續的 objcg 配置失敗，則free_objcg -> free_shrinker_info（） 展開路徑會拆除已發佈的 pn->shrinker_info 陣列，而不會shrinker_mutex。expand_one_shrinker_info（） 可以以相同的方式與該拆解競爭，導致舊shrinker_info的釋放後使用或雙重釋放。透過使用 shrinker_mutex 序列化shrinker_info拆卸，並將 alloc_shrinker_info（） 錯誤清除保留在鎖定區段內來修正此問題。
    (CVE-2026-64418)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - USB：misc：uss720：探查失敗時取消註冊 parport uss720_probe（） 會在讀取用於偵測不支援的 Belkin F5U002 配接器的 1284 暫存器之前註冊 parport。如果 get_1284_register（） 失敗，錯誤路徑會捨棄驅動程式私有資料和 USB 裝置參照，但會保留 parport 裝置已註冊。讓連接埠註冊不僅僅是私有分配洩露：parport_register_port（） 已經保留了一個 parport 號碼並註冊了 parport 匯流排設備，而 pp->private_data 仍然指向常見錯誤路徑即將釋放的私有資料。在跳至通用私有資料清除路徑之前，先復原 get_1284_register（） 失敗分支中的預先宣告註冊。先清除 priv->pp，以符合中斷連線路徑，並避免私有資料中出現過時的指標。
    此問題是在我們正在進行的靜態分析研究中發現的，同時檢閱核心程式碼。
    (CVE-2026-64338)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - USB：在提交失敗的 EHCI 和 FOTG210 同步提交時釋放 ISO 排程，在將 URB 連結至端點佇列之前建置ehci_iso_sched，並將暫存排程保留在 urb->hcpriv 中，直到 iso_stream_schedule（） 和連結協助程式取用它為止。如果控制器無法再存取，或 usb_hcd_link_urb_to_ep（） 失敗，請在交接發生之前提交跳轉至done_not_linked，並洩漏仍附加至 urb->hcpriv 的暫存排程。在連結 URB 之前，當提交失敗時，從done_not_linked釋放暫存排程釋放，並在釋放後清除 urb->hcpriv。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。
    該工具仍在開發中，尚未公開。手動檢查確認該錯誤在 v7.1.1 中仍然存在。x86_64 allyesconfig 組建沒有顯示新的警告。由於我們沒有帶有 USB 同步設備的 EHCI 主機控制器進行測試，因此無法執行運行時間測試。（CVE-2026-64348）

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

ID	名稱	嚴重性
330071	Linux Distros 未修補弱點：CVE-2026-60177	medium
330070	Linux Distros 未修補弱點：CVE-2026-61081	low
330069	Linux Distros 未修補弱點：CVE-2026-60747	medium
330068	Linux Distros 未修補弱點：CVE-2026-60315	high
330067	Linux Distros 未修補弱點：CVE-2026-61096	low
330048	Linux Distros 未修補弱點：CVE-2026-60189	medium
330047	Linux Distros 未修補弱點：CVE-2026-60187	medium
330046	Linux Distros 未修補弱點：CVE-2026-60316	high
330045	Linux Distros 未修補弱點：CVE-2026-61109	medium
330044	Linux Distros 未修補弱點：CVE-2026-60331	medium
330043	Linux Distros 未修補弱點：CVE-2026-60145	medium
330042	Linux Distros 未修補弱點：CVE-2026-60585	medium
330041	Linux Distros 未修補弱點：CVE-2026-60186	medium
330040	Linux Distros 未修補弱點：CVE-2026-60191	medium
330039	Linux Distros 未修補弱點：CVE-2026-60178	medium
330038	Linux Distros 未修補弱點：CVE-2026-60163	high
330037	Linux Distros 未修補弱點：CVE-2026-60184	medium
330036	Linux Distros 未修補弱點：CVE-2026-60332	medium
330035	Linux Distros 未修補弱點：CVE-2025-71408	high
330034	Linux Distros 未修補弱點：CVE-2026-60183	medium
330033	Linux Distros 未修補弱點：CVE-2026-60188	medium
330032	Linux Distros 未修補弱點：CVE-2026-60182	medium
330031	Linux Distros 未修補弱點：CVE-2026-60185	medium
330030	Linux Distros 未修補弱點：CVE-2026-9238	medium
330029	Linux Distros 未修補弱點：CVE-2026-12681	high
330028	Linux Distros 未修補弱點：CVE-2026-15578	high
330027	Linux Distros 未修補弱點：CVE-2026-66011	medium
330026	Linux Distros 未修補弱點：CVE-2026-8348	medium
330025	Linux Distros 未修補弱點：CVE-2026-16043	medium
330024	Linux Distros 未修補弱點：CVE-2026-61475	high
330023	Linux Distros 未修補弱點：CVE-2026-59676	medium
330022	Linux Distros 未修補弱點：CVE-2026-15705	high
330021	Linux Distros 未修補弱點：CVE-2026-63319	high
330019	Linux Distros 未修補弱點：CVE-2026-66373	high
330018	Linux Distros 未修補弱點：CVE-2024-14040	high
330017	Linux Distros 未修補弱點：CVE-2026-64530	critical
330016	Linux Distros 未修補弱點：CVE-2026-14899	high
329997	Linux Distros 未修補弱點：CVE-2026-64412	high
329996	Linux Distros 未修補弱點：CVE-2026-64323	high
329995	Linux Distros 未修補弱點：CVE-2026-64470	high
329994	Linux Distros 未修補弱點：CVE-2026-64510	high
329993	Linux Distros 未修補弱點：CVE-2026-64471	high
329992	Linux Distros 未修補弱點：CVE-2026-64460	high
329991	Linux Distros 未修補弱點：CVE-2026-64416	medium
329990	Linux Distros 未修補弱點：CVE-2026-64480	medium
329989	Linux Distros 未修補弱點：CVE-2026-64287	high
329988	Linux Distros 未修補弱點：CVE-2026-64410	critical
329987	Linux Distros 未修補弱點：CVE-2026-64418	high
329986	Linux Distros 未修補弱點：CVE-2026-64338	medium
329985	Linux Distros 未修補弱點：CVE-2026-64348	high

偵測

Nessus 的 Misc. 系列

medium

low

medium

high

low

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

medium

medium

high

high

medium

medium

medium

high

medium

high

high

high

high

critical

high

high

high

high

high

high

high

medium

medium

high

critical

high

medium

high