遠端主機上安裝的 Plone 版本在 2.5.x 之前 、 3.3.63.x 之前 、 4.0.44.x 之前 、 之前 。 4.1.x4.1.12.5.5 因此，該應用程式受到以下弱點影響：

  - 跨網站指令碼 （XSS） 漏洞允許遠端攻擊者透過特製的 URL （CVE-2011-1948） 插入任意 Web 指令碼或 HTML

  - Products.PortalTransforms 中safe_html過濾器中的跨網站指令碼 （XSS） 弱點允許遠端驗證使用者透過未指定的向量 （CVE-2011-1949） 插入任意 Web 指令碼或 HTML

  - plone.app.users 允許遠端驗證使用者透過未指定的向量修改任意帳戶的屬性，正如 2011 年 6 月在野外利用的那樣 （CVE-2011-1950）

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。由於廠商 Hotfix （PloneHotfix20110531） 可以在不升級版本的情況下修復此問題，因此此外掛程式只會在 Paranoid 模式下執行時報告。

遠端主機上安裝的 Plone 版本早於 5.2.3。因此，該應用程式受到以下弱點影響：

  - Plone 允許透過僅對管理員角色明確可用的功能進行 XXE 攻擊。
    (CVE-2020-28734)

  - Plone 允許透過回溯功能進行 SSRF 攻擊 （僅適用於管理員角色）。
    (CVE-2020-28735)

  - Plone 允許透過一項功能進行 XXE 攻擊，該功能受 plone.schemaeditor.ManageSchemata 未套用的權限保護 （因此，僅適用於管理員角色）。（CVE-2020-28736）

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

遠端主機上安裝的 Plone 版本早於 3.1.8。因此，主機受到攔截式弱點影響。Plone 在計算驗證 Cookie 的 HMAC-SHA1 值時使用不變資料 （用戶端使用者名稱和伺服器密碼），這使得遠端攻擊者更容易透過嗅探網路來永久存取帳戶。

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

遠端主機上安裝的 Plone 版本低於 3.0.0。因此，該應用程式受到以下弱點影響：

  - Plone 將 base64 編碼形式的使用者名稱和密碼放在管理員帳戶的 __ac cookie 中，這使得遠端攻擊者更易透過嗅探網路來獲得管理特權。
    (CVE-2008-1393)

  - 3 之前的 Plone CMS 將 base64 編碼形式的使用者名稱和密碼放在所有使用者帳戶的 __ac cookie 中，這使得遠端攻擊者更易透過嗅探網路來獲得存取權限。
    (CVE-2008-1394)

  - Plone CMS 不會記錄使用者的驗證狀態，僅在客戶端部署登出功能，這使得依賴上下文的攻擊者更易重複使用已登出的工作階段。
    (CVE-2008-1395)

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

遠端主機上安裝的 Coherence 12.2.1.4.0、14.1.1.0.0、14.1.2.0.0、15.1.1.0.0 版本受到 2026 年 7 月 CPU 公告中提及的多個弱點影響。

  - Oracle Fusion Middleware 的 Oracle Coherence 產品中存在弱點 (元件：Core)。受影響的支援版本是 12.2.1.4.0、14.1.1.0.0、14.1.2.0.0 和 15.1.1.0.0。具有網路存取權的未經驗證攻擊者可利用易受利用的弱點，透過 TCP 入侵 Oracle Coherence。
    雖然弱點位於 Oracle Coherence 中，但攻擊可能對其他產品造成重大影響 (範圍變更)。若成功攻擊此弱點，則可能導致接管 Oracle Coherence。
    (CVE-2026-60217)

  - Oracle Fusion Middleware 的 Oracle Coherence 產品中存在弱點 (元件：Core)。受影響的支援版本是 12.2.1.4.0、14.1.1.0.0、14.1.2.0.0 和 15.1.1.0.0。攻擊此弱點的難度較小，經由 HTTP 存取網路的未經驗證攻擊者可藉以入侵 Oracle Coherence。
    若成功攻擊此弱點，則可接管 Oracle Coherence。(CVE-2026-60225)

  - Oracle Fusion Middleware 的 Oracle Coherence 產品中的弱點 (元件：Centralized Third Party Jars (Apache Log4j))。受影響的支援版本是 12.2.1.4.0、14.1.1.0.0、14.1.2.0.0 和 15.1.1.0.0。攻擊此弱點的難度較小，經由 HTTP 存取網路的未經驗證攻擊者可藉以入侵 Oracle Coherence。若攻擊成功，攻擊者可在未經授權的情況下，建立、刪除或修改重要資料或所有 Oracle Coherence 可存取資料。
    (CVE-2026-34481)

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

根據其自我報告的版本號碼，遠端主機上執行的 Tenable Security Center 是介於 6.7.0 和 6.8.0 之間。因此，它會受到 TNS-2026-19 公告中所提及的多個弱點影響。

  - Redis 是一個記憶體內資料結構儲存區。在 redis-server 版本 7.2.0 至 8.6.3 中，重新執行封鎖的命令時，解除封鎖用戶端流程不會處理來自「processCommandAndResetClient」的錯誤傳回。如果在此流程期間撤回封鎖的用戶端，則經過驗證的攻擊者可觸發釋放後使用，進而導致遠端程式碼執行。現已在 8.6.3 版本中修補此問題。
    (CVE-2026-23479)

  - Redis 是一個記憶體內資料結構儲存區。在 8.6.3 之前的 redis-server 版本中，RESTORE 命令無法正確驗證序列化值。具有執行 RESTORE 權限的已驗證攻擊者可以提供特製的序列化承載，以觸發無效的記憶體存取，並可能導致遠端程式碼執行。因應措施是使用 ACL 規則來限制對 RESTORE 命令的存取。此問題已在 8.6.3 版中修正。(CVE-2026-25243)

  - RedisTimeSeries 是 Redis 的時間序列模組。在 1.12.14 之前的 RedisTimeSeries 的所有版本中，模組都無法正確驗證透過 Redis RESTORE 命令處理的序列化值。在載入了 RedisTimeSeries 模組的伺服器上，具有執行 RESTORE 權限的已驗證攻擊者可以提供特製的序列化承載，以觸發無效的記憶體存取，並可能導致遠端程式碼執行。因應措施是使用 ACL 規則來限制對 RESTORE 命令的存取。現已在 1.12.14 版本中修補此問題。(CVE-2026-25588)

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

根據其自我報告的版本號碼，遠端主機上執行的 Tenable Security Center 是介於 6.6.0 和 6.8.0 之間。因此，它會受到 TNS-2026-19 公告中所提及的多個弱點影響。

  - Tenable Security Center 受到 SQL 插入攻擊弱點的影響。(CVE-2026-64877)

  - 採用 HTTP/2 通訊協定的 Apache HTTP 伺服器中存在雙重釋放和可能的 RCE 弱點。此問題會影響 Apache HTTP Server：2.4.66。建議使用者升級至 2.4.67 版，即可修正此問題。(CVE-2026-23918)

  - PostgreSQL 模組 refint 中的堆疊緩衝區溢位漏洞，允許非特權資料庫使用者以執行資料庫的作業系統使用者身分執行任意程式碼。如果應用程式將一個使用者控制的欄位宣告為 refint 級聯主鍵，並允許使用者對該欄位進行更新，則可能發生一種特殊的攻擊。在這種情況下，SQL 注入會讓主鍵更新值提供者得以假冒執行主鍵更新的資料庫使用者身分，來執行任意的 SQL 指令。PostgreSQL 18.4、17.10、16.14、15.18 和 14.23 之前版本均會受到影響。(CVE-2026-6637)

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

遠端主機上安裝的 Amazon Corretto 是 17.0.20.8.1 之前的 17 版本，因此，其會受到 corretto-17-2026-Jul-21 公告中提及的多個弱點影響。

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：Libraries) 受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。此弱點較易攻擊成功，能夠透過多個通訊協定存取網路的未經驗證攻擊者可惡意利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。成功攻擊此弱點可導致在未經授權的情況下，建立、刪除或修改重要資料或所有可存取的 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM Enterprise 版本資料。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47063)

  - Little CMS （lcms2） through 2.18 在 cmslut.c 的 CubeSize 中有一個整數溢位，因為溢位檢查是在乘法之後執行的。（CVE-2026-41254）

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：JSSE)。受影響的支援版本是 Oracle Java SE: 11.0.31、17.0.19、21.0.11、25.0.3; Oracle GraalVM for JDK: 26.0.1、17.0.19、21.0.11; Oracle GraalVM 企業版: 21.3.18。此弱點較易攻擊成功，能夠透過 LTS 存取網路的未經驗證攻擊者可利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下造成 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版局部拒絕服務 (局部 DOS)。注意：此弱點僅可透過以下方式遭到惡意利用：提供資料給指定元件中的 API 而不使用未受信任的 Java Web Start 應用程式或是未受信任的 Java Applet，如透過 Web 服務。
    (CVE-2026-46917)

  - Oracle Java SE 的弱點 (元件：JSSE)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。難以惡意利用的弱點允許具有網路存取權的未經驗證攻擊者透過 TLS 來危害 Oracle Java SE。若攻擊成功，攻擊者未經授權即可建立、刪除或修改重要資料或所有 Oracle Java SE 可存取資料。注意：此弱點僅可透過以下方式遭到惡意利用：提供資料給指定元件中的 API 而不使用未受信任的 Java Web Start 應用程式或是未受信任的 Java Applet，如透過 Web 服務。(CVE-2026-46968)

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：ImageIO)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。攻擊此弱點具有難度，能夠透過多個通訊協定存取網路的未經驗證的攻擊者可利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下更新、插入或刪除 Oracle Java SE、Oracle GraalVM for JDK 和 Oracle GraalVM Enterprise Edition 的部分可存取資料。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47010)

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

遠端主機上安裝的 Amazon Corretto 版本是 8.502.07.1 之前的 8 版本。因此，其會受到 corretto-8-2026-Jul-21 公告中提及的多個弱點影響。

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：Libraries) 受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。此弱點較易攻擊成功，能夠透過多個通訊協定存取網路的未經驗證攻擊者可惡意利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。成功攻擊此弱點可導致在未經授權的情況下，建立、刪除或修改重要資料或所有可存取的 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM Enterprise 版本資料。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47063)

  - Little CMS （lcms2） through 2.18 在 cmslut.c 的 CubeSize 中有一個整數溢位，因為溢位檢查是在乘法之後執行的。（CVE-2026-41254）

  - Oracle Java SE 的弱點 (元件：JSSE)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。難以惡意利用的弱點允許具有網路存取權的未經驗證攻擊者透過 TLS 來危害 Oracle Java SE。若攻擊成功，攻擊者未經授權即可建立、刪除或修改重要資料或所有 Oracle Java SE 可存取資料。注意：此弱點僅可透過以下方式遭到惡意利用：提供資料給指定元件中的 API 而不使用未受信任的 Java Web Start 應用程式或是未受信任的 Java Applet，如透過 Web 服務。(CVE-2026-46968)

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：ImageIO)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。攻擊此弱點具有難度，能夠透過多個通訊協定存取網路的未經驗證的攻擊者可利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下更新、插入或刪除 Oracle Java SE、Oracle GraalVM for JDK 和 Oracle GraalVM Enterprise Edition 的部分可存取資料。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47010)

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：2D)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。此弱點較易攻擊成功，能夠透過多個通訊協定存取網路的未經驗證攻擊者可惡意利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下造成 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版局部拒絕服務 (局部 DOS)。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47021)

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

遠端主機上安裝的 Amazon Corretto 是 11.0.32.9.1 之前的 11 版本，因此，其會受到 corretto-11-2026-Jul-21 公告中提及的多個弱點影響。

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：Libraries) 受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。此弱點較易攻擊成功，能夠透過多個通訊協定存取網路的未經驗證攻擊者可惡意利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。成功攻擊此弱點可導致在未經授權的情況下，建立、刪除或修改重要資料或所有可存取的 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM Enterprise 版本資料。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47063)

  - Little CMS （lcms2） through 2.18 在 cmslut.c 的 CubeSize 中有一個整數溢位，因為溢位檢查是在乘法之後執行的。（CVE-2026-41254）

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：JSSE)。受影響的支援版本是 Oracle Java SE: 11.0.31、17.0.19、21.0.11、25.0.3; Oracle GraalVM for JDK: 26.0.1、17.0.19、21.0.11; Oracle GraalVM 企業版: 21.3.18。此弱點較易攻擊成功，能夠透過 LTS 存取網路的未經驗證攻擊者可利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下造成 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版局部拒絕服務 (局部 DOS)。注意：此弱點僅可透過以下方式遭到惡意利用：提供資料給指定元件中的 API 而不使用未受信任的 Java Web Start 應用程式或是未受信任的 Java Applet，如透過 Web 服務。
    (CVE-2026-46917)

  - Oracle Java SE 的弱點 (元件：JSSE)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。難以惡意利用的弱點允許具有網路存取權的未經驗證攻擊者透過 TLS 來危害 Oracle Java SE。若攻擊成功，攻擊者未經授權即可建立、刪除或修改重要資料或所有 Oracle Java SE 可存取資料。注意：此弱點僅可透過以下方式遭到惡意利用：提供資料給指定元件中的 API 而不使用未受信任的 Java Web Start 應用程式或是未受信任的 Java Applet，如透過 Web 服務。(CVE-2026-46968)

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：ImageIO)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。攻擊此弱點具有難度，能夠透過多個通訊協定存取網路的未經驗證的攻擊者可利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下更新、插入或刪除 Oracle Java SE、Oracle GraalVM for JDK 和 Oracle GraalVM Enterprise Edition 的部分可存取資料。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47010)

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

遠端主機上安裝的 Azul Zulu 版本是 6.81.0.14 之前的 6 版 / 7.87.0.14 之前的 7 版 / 8.95.0.14 之前的 8 版 / 11.89.14 之前的 11 版 / 17.67.14 之前的 17 版 / 21.51.14 之前的 21 版 / 25.35.14 之前的 25 版 / 25.35.12 之前的 25 版 / 26.32.14 之前的 26 版。因此，會受到 2026-07-21 公告中所提及的多個弱點影響。

  - Little CMS （lcms2） through 2.18 在 cmslut.c 的 CubeSize 中有一個整數溢位，因為溢位檢查是在乘法之後執行的。（CVE-2026-41254）

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：JSSE)。受影響的支援版本是 Oracle Java SE: 11.0.31、17.0.19、21.0.11、25.0.3; Oracle GraalVM for JDK: 26.0.1、17.0.19、21.0.11; Oracle GraalVM 企業版: 21.3.18。此弱點較易攻擊成功，能夠透過 LTS 存取網路的未經驗證攻擊者可利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下造成 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版局部拒絕服務 (局部 DOS)。注意：此弱點僅可透過以下方式遭到惡意利用：提供資料給指定元件中的 API 而不使用未受信任的 Java Web Start 應用程式或是未受信任的 Java Applet，如透過 Web 服務。
    (CVE-2026-46917)

  - Oracle Java SE 的弱點 (元件：JSSE)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。難以惡意利用的弱點允許具有網路存取權的未經驗證攻擊者透過 TLS 來危害 Oracle Java SE。若攻擊成功，攻擊者未經授權即可建立、刪除或修改重要資料或所有 Oracle Java SE 可存取資料。注意：此弱點僅可透過以下方式遭到惡意利用：提供資料給指定元件中的 API 而不使用未受信任的 Java Web Start 應用程式或是未受信任的 Java Applet，如透過 Web 服務。(CVE-2026-46968)

  - Oracle Java SE、Oracle GraalVM for JDK、Oracle Java SE 的 Oracle GraalVM 企業版產品中的弱點 (元件：ImageIO)。受影響的支援版本是 Oracle Java SE: 8u491, 8u491-perf、11.0.31、17.0.19、21.0.11、25.0.3、26.0.1; Oracle GraalVM for JDK: 17.0.19 和 21.0.11; Oracle GraalVM 企業版: 21.3.18。攻擊此弱點具有難度，能夠透過多個通訊協定存取網路的未經驗證的攻擊者可利用此弱點入侵 Oracle Java SE、Oracle GraalVM for JDK、Oracle GraalVM 企業版。若攻擊成功，攻擊者可在未經授權的情況下更新、插入或刪除 Oracle Java SE、Oracle GraalVM for JDK 和 Oracle GraalVM Enterprise Edition 的部分可存取資料。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47010)

  - Oracle Java SE (元件：JavaFX) 中的弱點。受影響的支援版本是 Oracle Java SE: 8u491。此弱點較易攻擊，能夠透過多個通訊協定存取網路的未經驗證攻擊者可藉此入侵 Oracle、Java SE。若成功攻擊此弱點，則可能導致在未經授權的情況下造成 Oracle Java SE 部分拒絕服務 (部分 DOS)。注意：使用指定之元件中的 API 可以惡意利用此弱點，例如，透過提供資料給 API 的 Web 服務。此弱點亦適用於 Java 部署，通常是在執行沙箱隔離的 Java Web Start 應用程式或沙箱隔離的 Java Applet 的用戶端中，這種部署會載入並執行不受信任的程式碼 (例如，來自網際網路的程式碼)，並依賴 Java 沙箱獲得安全性。(CVE-2026-47013)

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

遠端主機上安裝的 AOS 版本低於 7.6。因此，它會受到 NXSA-AOS-7.6 公告中提及的多個弱點的影響。

  - NLnet Labs Unbound 1.19.1 至 1.25.0 的 DNSSEC 驗證器中存在弱點，會造成拒絕服務並可能造成遠端程式碼執行，因深層複製資料結構和錯誤覆寫目的地指標所致。攻擊者可以透過控制惡意簽署的區域並查詢易受攻擊的 Unbound 來利用此弱點。當 DS 子查詢因 NSEC3 運算預算耗盡（在 Unbound 1.19.1 中引入）而需要暫停驗證時，Unbound 會深層複製回應訊息，以便在記憶體區域銷毀時保留這些訊息。結構指派錯誤會以來源的指標覆寫目的地的指標。釋放子查詢區域後，恢復的驗證器會取消引用此懸空指標，從而觸發崩潰或可能啟用任意程式碼執行。Unbound 1.25.1 包含的修補程式會提供相應的修復措施，可在深度複製資料結構時保留正確的指標。(CVE-2026-33278)

  - 在 GNU Binutils 2.45中發現弱點。受影響的元素是元件連結器的程式庫 bfd/elfcode.h 中的函式elf_swap_shdr。攻擊者可利用此弱點造成堆積型緩衝區溢位。
    攻擊必須在本地進行。攻擊程式已向公眾披露且可能會遭到利用。修補程式的識別碼是 9ca499644a21ceb3f946d1c179c38a83be084490。若要修正此問題，建議部署修補程式。程式碼維護者回覆了 [f]ixed 2.46for .（CVE-2025-11083）

  - 透過在 g_escape_uri_string（） 函式中錯誤計算緩衝區大小，在 glib 中發現堆積型緩衝區溢位問題。如果要逸出的字串包含大量不可接受的字元 （需要逸出），則逸出字串長度的計算可能會溢位，導致新配置字串結尾可能會註銷。（CVE-2025-13601）

  - 在 grub2 中發現缺陷。在 grub_gettext_getstr_from_position() 中讀取語言 .mo 檔案時的轉譯緩衝區計算可能溢位，進而導致超出邊界寫入。攻擊者可利用此問題來覆寫 grub2 的敏感堆積資料，最終規避安全開機保護機制。(CVE-2024-45777)

  - 在 3e474c2 之前的 Sudo 至 1.9.17p2 中，在執行郵件程式之前的特權捨棄期間，setuid、setgid 或 setgroups 呼叫失敗並非嚴重錯誤，並且可能導致特權提升。
    (CVE-2026-35535)

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

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

  - App：：Ack 版本 3.10.0 透過 Perl 在專案 .ackrc 中讀取任意檔案 --files-from 。 ack 會從目前目錄中搜尋專案 .ackrc 的目錄階層，並載入其選項。
    App：：Ack：：ConfigLoader 中的 project-source 選項封鎖清單不包含 --files-from，因此專案 .ackrc 可以將其設定為路徑，然後讀取和搜尋其列出的檔案 ack。已新增至--follow封鎖清單的版本3.10.0，--files-from仍會被接受。提交到不受信任存放庫的專案 .ackrc 可以使 ack 讀取專案外部的檔案並列印其相符的行。（CVE-2026-49145）

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

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

  - Ubuntu 中提供的 OpenJDK 套件中存在沙箱逸出弱點。這些套件所安裝的 .jar MIME 處理常式會在安裝 mailcap 套件時執行標示為可執行檔的檔案。透過 xdg-desktop-portal-gtk 存取 OpenURI 入口網站的遭入侵或惡意沙箱化應用程式，可將惡意.jar檔寫入主機檔案系統、設定其可執行位元，並觸發處理常式在沙箱環境之外執行任意程式碼。（CVE-2026-10037）

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

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

  - 在 Google Chrome 的 ANGLE 中進行未初始化使用之前， 150.0.7871.115 允許遠端攻擊者透過特製的 HTML 頁面從進程記憶體取得潛在的敏感資訊。(Chromium 安全性嚴重性 : 高) (CVE-2026-15109)

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

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

  - App：：Ack 版本通過 Perl 在 3.10.0 多種輸出模式下從文件名打印未清理的終端逸出序列。當 ack 列印基底名稱包含終端機控制位元組 （例如 ANSI 逸出序列） 的檔名時，這些位元組會以不變的方式到達終端機。版本新增 3.10.0 了一個 _safe_filename 協助程式，可清理由 -f、-g、彩色比對標題和每個比對行列印的檔案名，但 --show-types、 -l/-L 和 -c 路徑仍會發出原始檔案名稱。其名稱內嵌游標移動或顏色逸出的檔案可以覆寫或重新著色先前的終端輸出，或原封不動地傳遞給下游消費者。（CVE-2026-49147）

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

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

  - App：：Ack 之前的 Perl 版本 3.10.0 允許透過專案 .ackrc 中的無限上下文值耗盡記憶體。 ack 會從目前目錄中的目錄階層中搜尋專案 .ackrc 並載入其選項。-B 和 -C 上下文選項接受任何正整數，並且 ack 將上下文前緩衝區的大小調整為該值，因此專案 .ackrc 設定 --before-context=100000000 使 ack 配置了 100,000,000 個元素的緩衝區。提交至不受信任存放庫的專案 .ackrc 可能會因記憶體不足而中止 ack。（CVE-2026-49146）

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

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

  - Z39.50 Wireshark 4.6.04.4.04.6.64.4.16 中的協定剖析器崩潰，以允許拒絕服務 （）CVE-2026-15170

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

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

  - Immutable.js 提供許多持續式不可變資料結構。在 4.3.9 和 5.1.8之前，List#set、List#setSize、List#setIn、List#updateIn 以及函式 set、setIn 和 updateIn 錯誤地處理 src/List.js 中 setListBounds 中 2 ** 30 到 2 ** 31 範圍內的索引或大小，導致一個空的 List 進入一個無法捕獲的無限迴圈，一個填充的 List 要無限制地分配，直到進程中止， 或 setSize 以無訊息方式包裝較大值。此問題已在 4.3.9 和 5.1.8 版中修正。(CVE-2026-59879)

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

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

  - Wireshark 4.6.0 至 4.6.6 和 4.4.0 至 4.4.16 版中的 IEEE 802.11 通訊協定剖析器當機弱點可造成系統拒絕服務 (CVE-2026-15166)

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

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

  - Immutable.js 提供許多持續式不可變資料結構。在 4.3.9 和 5.1.8之前，Immutable.Map 和 Immutable.Set 會將共用相同 32 位元雜湊的金鑰保留在以線性方式掃描的 HashCollisionNode 衝突儲存桶中，因此控制插入到 Map 中的金鑰的攻擊者 （例如透過 Immutable.Map（obj）、Immutable.fromJS（obj）、state.merge（userObject） 或 mergeDeep） 來製作許多衝突金鑰，並降低插入和查詢的品質，以耗用不成比例的 CPU。此問題已在 4.3.9 和 5.1.8 版中修正。(CVE-2026-59880)

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

此外掛程式已過時，因為所有參照的 CVE 都遭到拒絕。

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

  - 在 kronosnet （<=1.34版） 密碼編譯組態管理中發現弱點。架構在執行對其密碼編譯設定的變更之後，不會正確地清零或清除敏感記憶體區段。此遺漏會在釋放相關結構後，保留原始加密金鑰駐留在記憶體中。能夠利用記憶體洩漏技術的本地攻擊者可利用此缺陷來擷取活動加密金鑰，從而解密叢集網路通訊或注入惡意封包，導致嚴重的高可用性叢集不穩定。
    (CVE-2026-15811)

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

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

  - 在 kronosnet 的內部存取控制清單 （ACL） 子系統中發現弱點 （受影響的版本：<= 1.34）。當架構明確設定為管理動態連結 （接受來自任何 IP 位址的網路流量） 而不進行網路承載加密時，驗證架構會隱含信任傳入資料封包內提供的連結識別碼。未經身份驗證的遠端攻擊者可以透過在特製的網路框架內欺騙合法連結 ID 來利用這種缺乏驗證的情況。這使得攻擊者能夠完全繞過ACL框架，將任意資料包注入應用層，可能導致資料損壞或服務不穩定。（CVE-2026-15812）

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

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

  - i2c： i801：修正錯誤路徑中的硬體狀態機器損毀 在並行模糊測試期間，在 i2c-i801 驅動程式中觀察到嚴重的活鎖和隨後的懸置任務錯誤。損毀是由 i801_access（） 錯誤處理路徑中的無條件硬體暫存器清理所造成。當 i801_check_pre（） 失敗時 （例如，傳回 -EBUSY，因為 SMBus 控制器被 BIOS/ACPI 主動使用），核心實際上並不會取得硬體擁有權。但是，程式碼會跳到「out」標籤並執行：
    iowrite8（SMBHSTSTS_INUSE_STS |STATUS_FLAGS，SMBHSTSTS（priv））;這會強制清除INUSE_STS鎖定，並在不擁有控制器的情況下重設硬體狀態旗標。這樣做會中斷正在進行的 BIOS/ACPI 交易，並完全損毀 SMBus 硬體狀態機器。因此，後續所有 i801_access（） 呼叫在預檢查階段都失敗，觸發源源不絕的 SMBus 忙碌，無法使用！錯誤記錄。在緩慢的串行控制台上，此 printk 洪水會壟斷 CPU（控制台 Livelock），使其他嘗試獲取mmap_lock down_read信號量的進程感到飢餓，最終觸發懸置任務看門狗。透過將硬體暫存器清理下方的「out」標籤移動來修正此問題。如果i801_check_pre（）失敗，我們安全地繞過iowrite8（），只釋放軟體鎖（pm_runtime和互斥），嚴格遵守不釋放從未取得的資源的規則。
    (CVE-2026-64205)

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

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

  - netfilter： ipset：修正轉儲和 ip_set_list 之間的爭用 調整大小 ip_set_dump_do（） 和 ip_set_dump_done（） 的釋放路徑透過 ip_set_ref_netlink（） 讀取 inst->ip_set_list，這是陣列指標的普通 rcu_dereference_raw（）。這些從沒有 nfnl 互斥且沒有 RCU 讀取端關鍵區段的 netlink_recvmsg（） 執行。並發 ip_set_create（） 可以增長陣列：它發布新陣列，調用 synchronize_net（），然後 kvfree（） 對舊陣列進行。由於轉儲路徑在任何 RCU 讀取器之外讀取陣列，因此 synchronize_net（） 不會等待它們，並且可以在它們仍索引到舊陣列時釋放舊陣列，從而導致釋放後使用。轉儲的集合本身會透過 set->ref_netlink 保持固定狀態，因此只有陣列載入需要保護。在它周圍取 rcu_read_lock（），匹配 ip_set_get_byname（） 和
    __ip_set_put_byindex（）。錯誤：KASAN：ip_set_dump_do 中的 slab-use-after-free （net/netfilter/ipset/ip_set_core.c：1697） 透過任務 exploit/150 在 addr ffff88800b5c4018 讀取大小 8 呼叫追蹤：...kasan_report （mm/kasan/report.c：595） ip_set_dump_do （net/netfilter/ipset/ip_set_core.c：1697） netlink_dump （net/netlink/af_netlink.c：2325） netlink_recvmsg （net/netlink/af_netlink.c：1976） sock_recvmsg （net/socket.c：1159） __sys_recvfrom （net/socket.c：2315） ... 哎呀：一般保護錯誤，可能是非規範地址...... KASAN NOPTI KASAN：也許是範圍內的 wild-memory-access [0x02d6...d0-0x02d6...d7] RIP： 0010：ip_set_dump_do （net/netfilter/ipset/ip_set_core.c：1698） 核心錯誤 - 不同步： 致命異常 （CVE-2026-64189）

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

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

  - xfs：在沒有區域的已提交日誌項目上恢復失敗 如果事務的第一個操作是裸交易標頭 （len == sizeof（struct xfs_trans_header）），則 xlog_recover_add_to_trans（） 會新增一個項目，但沒有區域，將其保留在 ri_cnt == 0 且 ri_buf == NULL 的r_itemq上。標頭可以在操作記錄之間拆分，因此以後的操作仍可能添加區域;只有在交易以 NONE 認可時，項目才會無效。執行階段認可路徑永遠不會發出這類交易，因此這只會發生在特製的記錄檔上。它來自對恢復解析器的人工智能輔助代碼審計。xlog_recover_reorder_trans（） 在項目上呼叫 ITEM_TYPE（），該項目讀取 *（無符號短 *）item->ri_buf[0].iov_base並在 NULL ri_buf上出錯。在也讀取 ri_buf[0] 的提交處理常式之前拒絕它。KASAN：範圍內 null-ptr-deref [0x0000000000000000-0x0000000000000007] RIP：0010：xlog_recover_reorder_trans （fs/xfs/xfs_log_recover.c：1836） xlog_recover_commit_trans （fs/xfs/xfs_log_recover.c：2043） xlog_recover_process_data （fs/xfs/xfs_log_recover.c：2501） xlog_do_recovery_pass （fs/xfs/xfs_log_recover.c：3244） xlog_recover （fs/xfs/xfs_log_recover.c：3493） xfs_log_mount （fs/xfs/xfs_log.c：618） xfs_mountfs （fs/xfs/xfs_mount.c：1034） xfs_fs_fill_super （fs/xfs/xfs_super.c：1938） vfs_get_tree （fs/super.c：1695） path_mount （fs/namespace.c：4161） __x64_sys_mount （fs/namespace.c：4367） （CVE-2026-64187）

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

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

  - i2c： stub：拒絕長度無效的 I2C 區塊傳輸 stub_xfer（） 中的I2C_SMBUS_I2C_BLOCK_DATA情況使用 data->block[0] 作為傳輸長度。現有的檢查僅限制它以避免溢出 chip->words[256] 暫存器陣列，但不會根據 I2C_SMBUS_BLOCK_MAX （32） 驗證它，這是 union i2c_smbus_data.block 緩衝區的限制（總共 34 個位元組）。驅動程式是開發/測試工具 （CONFIG_I2C_STUB=m，預設未建置），必須載入 chip_addr= 參數。具有 /dev/i2c-* 存取權的本機使用者可以使用 I2C_SMBUS_I2C_BLOCK_DATA 和 data->block[0] > 32 發出I2C_SMBUS ioctl，導致 stub_xfer（） 讀取或寫入超過聯集 i2c_smbus_data.block 緩衝區的結尾： 錯誤：
    KASAN：stub_xfer中堆疊越界 （drivers/i2c/i2c-stub.c：223） 任務 exploit/81 在 addr ffff88800abcfd92 讀取大小 1 呼叫追蹤： <TASK> stub_xfer （drivers/i2c/i2c-stub.c：223）
    __i2c_smbus_xfer （drivers/i2c/i2c-core-smbus.c：593） i2c_smbus_xfer （drivers/i2c/i2c-core-smbus.c：536） i2cdev_ioctl_smbus （drivers/i2c/i2c-dev.c：391） i2cdev_ioctl （drivers/i2c/i2c-dev.c：478） __x64_sys_ioctl （fs/ioctl.c：583） do_syscall_64 （arch/x86/entry/syscall_64.c：94） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：130） </TASK> 存在此錯誤是因為 i2c-stub 直接實作.smbus_xfer， 繞過 i2c_smbus_xfer_emulated（） 中的I2C_SMBUS_BLOCK_MAX驗證。相同函式中的I2C_SMBUS_BLOCK_DATA案例會針對I2C_SMBUS_BLOCK_MAX正確驗證，但I2C_SMBUS_I2C_BLOCK_DATA案例則不會。透過拒絕具有 data->block[0] == 0 或具有 -EINVAL > I2C_SMBUS_BLOCK_MAX的 data->block[0] 傳輸來修正，這與相同函式中的 I2C_SMBUS_BLOCK_DATA 情況和 i2c_smbus_xfer_emulated（） 中的I2C_SMBUS_I2C_BLOCK_DATA驗證一致。（CVE-2026-64191）

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。libvips 之前版本中的 8.18.1 「tiffload」作業可能會錯誤地判斷 TIFF 影像內 JPEG 或 JPEG2000-encoded 圖塊中的通道數，進而導致可能的緩衝區溢位。現已在 8.18.2 版本中修補此問題。(CVE-2026-35591)

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

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

  - bpf： 如果 BPF LSM 未初始化，則拒絕BPF_MAP_TYPE_INODE_STORAGE建立 當設定 CONFIG_BPF_LSM=y 時，BPF inode 儲存映射 （BPF_MAP_TYPE_INODE_STORAGE） 會編譯到核心中。但是，如果在啟動時未明確啟用 BPF LSM（例如，從 lsm= boot 參數中省略），則絕不會針對 BPF LSM 執行 lsm_prepare（）。因此，BPF inode 安全性 blob 位移 （bpf_lsm_blob_sizes.lbs_inode） 永遠不會初始化，並維持其預設編譯大小 8 位元組，而不是更新為超過保留結構rcu_head的有效位移 （通常為 16 位元組或更多）。
    當特權使用者建立並更新BPF_MAP_TYPE_INODE_STORAGE對應時，bpf_inode（） 會評估 inode->i_security + 8。這會錯誤地將 inode >i_security blob 開頭的結構 rcu_head.func 回呼指標別名。在後續的對應元素清除或 inode 銷毀期間，將 NULL 寫入 owner_storage 會清除佇列的 RCU 回呼指標。當 rcu_do_batch（） 稍後執行佇列回呼時，它會在位址0x0嘗試指令擷取，從而立即觸發核心錯誤。透過引入標有 __ro_after_init 的全域bpf_lsm_initialized布林旗標來修正此問題。當 LSM 架構成功註冊 BPF LSM 時，在 bpf_lsm_init（） 內將此標誌設定為 true。在此旗標的 inode_storage_map_alloc（） 中進行閘對應分配，如果 BPF LSM 反過來未初始化，則傳回 -EOPNOTSUPP。
    這種故障快速方法可防止使用者空間在缺少支援的 BPF LSM 基礎架構時配置 inode 儲存對應，從而避免殭屍對應狀態。（CVE-2026-64192）

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

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

  - 已解決 Linux 核心中的下列弱點：net/sched: dualpi2: fix GSO backlog accounting When DualPI2 splits a GSO skb into N segments, it propagates N additional packets to its parent before returning NET_XMIT_SUCCESS. The parent then accounts for the original skb once more, leaving its qlen one larger than the number of packets actually queued. With QFQ as the parent, after all real packets are dequeued, QFQ still has a non-zero qlen while its in-service aggregate has no active classes.
    qfq_choose_next_agg() returns NULL and qfq_dequeue() passes the result to qfq_peek_skb(), causing a NULL pointer dereference. Follow the same pattern used by tbf_segment() and taprio: count only successfully queued segments, propagate the difference between the original skb and those segments, and return NET_XMIT_SUCCESS whenever at least one segment was queued. (CVE-2026-64207)

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

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

  - 之前 3.28.0 的 FreeRDP （受影響的 <=3.27.1） 在 crypto_rsa_common（） 中包含堆積型緩衝區溢位 （libfreerdp/crypto/crypto.c）。此函式會透過 BN_bn2bin（） 將模組化冪結果寫入呼叫端的輸出緩衝區，之後才檢查output_length > out_length，因此會在邊界檢查之前寫入越界位元組。在伺服器端，當用戶端選取 RDP 標準安全性時，加密的用戶端隨機數會解密到固定的 32 位元組緩衝區中。由於伺服器發布其 RSA 公開金鑰，未經身份驗證的攻擊者可以偽造解密值高達完整模長度的密文 （例如 RSA-2048 為 256 位元組），使 32 位元組堆緩衝區溢位最多 ~224 位元組的攻擊者控制的預先身份驗證，從而導致拒絕服務。（CVE-2026-64620）

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。之前版本和版本中的 8.18.0 「vipsload」作業可能會錯誤地判斷影像尺寸，進而導致整數溢位和後續的堆積型緩衝區溢位。現已在 8.18.1 版本中修補此問題。(CVE-2026-33327)

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。在之前版本的 8.18.032 位元系統上，「gifload」作業可能會錯誤地判斷維度，進而導致整數溢位。現已在 8.18.1 版本中修補此問題。(CVE-2026-33328)

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

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

  - net： team：在模式變更期間修正 team_xmit 中的 NULL 指標解除參照 __team_change_mode（） 會使用 memset（） 清除 team->ops，然後再透過 team_adjust_ops（） 還原安全的虛擬處理常式。在另一個 CPU 上的 RCU 下執行的並行 team_xmit（） 可以在此時段內讀取 team->ops.transmit 並呼叫 NULL 函式指標，從而使核心當機。比賽需要模式更改 （CAP_NET_ADMIN） 與團隊設備上的傳輸同時進行。錯誤：核心 NULL 指標解除參照，位址：0000000000000000000 哎呀：
    0010 [#1] SMP KASAN NOPTI RIP： 0010：0x0 呼叫追蹤：team_xmit （drivers/net/team/team_core.c：1853） dev_hard_start_xmit （net/core/dev.c：3904） __dev_queue_xmit （net/core/dev.c：4871） packet_sendmsg （net/packet/af_packet.c：3109） __sys_sendto （net/socket.c：2265） 原始程式碼假設沒有連接埠意味著沒有流量，因此模式變更可以自由地 memset（）/memcpy（） 操作。強制載波的AF_PACKET打破了這一假設。防止爭用而不是使其安全：將 memset（）/memcpy（） 替換為從不接觸傳輸或接收的每個欄位更新。這兩個處理常式僅由 team_adjust_ops（） 管理，當 tx_en_port_count == 0 時，它已經安裝了虛擬（在模式變更期間始終為 true，因為不存在連接埠）。WRITE_ONCE/READ_ONCE可防止處理常式指標上的儲存/載入撕裂。exit_op（） 之前的 synchronize_net（） 會耗盡正在進行的讀取器，這些讀取器可能仍參照連接埠移除將處理常式切換為虛擬人之前的舊模式狀態。（CVE-2026-64190）

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

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

  - 藍牙：L2CAP：在進行 conn->lock 之前取消pending_rx_work l2cap_conn_del（） 採用 conn->lock，然後呼叫 cancel_work_sync（） 進行pending_rx_work。process_pending_rx（） 採用相同的互斥，因此 teardown 可能會與它正在排清的工作節點鎖死。此問題由我們的靜態分析工具發現，然後針對目前的樹狀結構手動檢閱。接地的 PoC 會保留 l2cap_conn_ready（） -> queue_work（...， &conn->pending_rx_work） 提交路徑、l2cap_conn_del（） -> cancel_work_sync（&conn->pending_rx_work） 拆卸路徑，以及 process_pending_rx（） -> mutex_lock（&conn->lock） 背景工作邊緣。Lockdep 警告：偵測到可能的循環鎖定相依性 process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** 鎖死 *** 在進行 conn->lock 之前取消pending_rx_work，以符合用於相同拆卸路徑中兩個延遲工作的現有 lock-after-drain 順序。在取消工作並取得 conn->lock 之後，仍會清除 pending_rx 佇列。（CVE-2026-64206）

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

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

  - Net：：DNS 版本 1.55 透過 Perl 允許透過 EDNS 擴充錯誤進行遠端執行插入。
    Net：：DNS：：RR：：OPT：：EXTENDED_ERROR：：_decompose 透過標記原始位元組並將結果傳遞給 Perl 的評估來剖析 EDNS EXTENDED-ERROR 選項 （RFC 8914） 的 EXTRA-TEXT 欄位。對 $ 和 @ 進行了一些逸出，但沒有針對反引號。如果在陣列內容中呼叫 ->edns->option（'EXTENDED-ERROR'），例如在 EXTRA-TEXT 中負載為 {0：'<command>'}，則$pkt可以利用此漏洞來執行命令。（CVE-2026-64193）

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

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

  - 由於 ['afsql_dd_run_query']（）https://github.com/syslog-ng/syslog-ng/blob/649e6e18e3459fb4467000a88dfb12fa97f9719c/modules/afsql/afsql.c#L219 中缺少清理呼叫，syslog-ng before 容易 4.12 受到來自不受信任來源的 SQL 插入。這不是預設設定的一部分，必須手動設定 SQL 驅動程式。修正項目位於 syslog-ng 4.12、syslog-ng 進階版 8.2 和 syslog-ng 存放區方塊 7.8 （CVE-2026-39879）

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

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

  - Perl 的 1.55 Net：：DNS 版本允許透過深層 DNS 壓縮指標鏈進行拒絕服務。
    Net：：DNS：:D omainName：:d ecode 遵循 RFC 1035 壓縮指標，遞迴到本身，沒有深度限制。可以建構一個使呼叫堆疊飽和的名稱 （至少具有較大的 TCP 回應），從而導致潛在的拒絕服務。防護裝置「$link < $offset」可防止向前和圓形鏈，但仍允許任意長的向後鏈。每個偏移快取 （'$cache'） 會在每次呼叫開始時填入，並且僅短路重新遍歷相同的偏移 - 透過新鏈的初始下降仍會在完整深度遞迴。特製的封包可以鏈結兩個位元組的壓縮指標，讓每個指標比前一個早兩個位元組指向，從而產生「位移 / 2」的鏈條長度。對於 14 位指標欄位 （最大偏移量 16383），這最多可提供 ~8191 遞迴框架。
    對於 TCP DNS 訊息，限制為 16 位元長度欄位 （~32767 幀）。Perl 的預設 C 堆疊僅處理幾千幀;除此之外，該進程會收到 SIGSEGV 或類似內容，這是對任何剖析不受信任 DNS 資料的應用程式的拒絕服務。此弱點是由「Net：：DNS：:P acket->new（\$wire）」觸發，即程式庫解碼來自網路的DNS訊息的任何點。
    (CVE-2026-64194)

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

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

  - net：qualcomm：rmnet：修正 rmnet_dellink（） 中的端點釋放後使用 rmnet_dellink（） 使用 hlist_del_init_rcu（） 從雜湊表中刪除端點，然後立即使用 kfree（） 釋放它。不過，接收路徑 （rmnet_rx_handler -> __rmnet_map_ingress_handler） 上的 RCU 讀取器可能仍會保留端點的參照，並在釋放記憶體之後取消參照 ep->egress_dev。端點是 kmalloc-32 物件，位移 8 處的過時讀取對應至egress_dev指標。錯誤：無法處理位址的頁面錯誤：ffffffffde942eef 哎呀：0002 [#1] SMP NOPTI CPU：1 UID：0 PID：137 通訊：
    poc_write 未受污染 7.0.0+ #4 PREEMPTLAZY RIP：0010：rmnet_vnd_rx_fixup （rmnet_vnd.c：27） 呼叫追蹤：
    <TASK> __rmnet_map_ingress_handler （rmnet_handlers.c：48 rmnet_handlers.c：101） rmnet_rx_handler （rmnet_handlers.c：129 rmnet_handlers.c：235） __netif_receive_skb_core.constprop.0 （net/core/dev.c：6096）
    __netif_receive_skb_one_core （net/core/dev.c：6208） netif_receive_skb （net/core/dev.c：6467） tun_get_user （drivers/net/tun.c：1955） tun_chr_write_iter （drivers/net/tun.c：2003） vfs_write （fs/read_write.c：688） ksys_write （fs/read_write.c：740） </TASK> 新增 rcu_head 欄位以結構rmnet_endpoint，並將 kfree（） 替換為 kfree_rcu（），以便端點記憶體在 RCU 寬限期內保持有效。另外，移除 rmnet_vnd_dellink（） 呼叫並僅內嵌 nr_rmnet_devs 遞減，因為 rmnet_vnd_dellink（） 會在寬限期內將 ep->egress_dev 設定為 NULL，從而產生與無鎖定讀取器的資料爭用。
    (CVE-2026-64188)

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

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

  - libvips 是一個快速圖像處理庫，內存需求低。libvips 版本之前和包含的 8.18.1 EXIF 解碼器在將資料傳遞給 libexif 之前未驗證 EXIF 標籤群組的範圍，導致可能的 NULL 指標解除參照和損毀。現已在 8.18.2 版本中修補此問題。
    (CVE-2026-35590)

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

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

  - 已解決 Linux 核心中的下列弱點：platform/x86: lenovo-wmi-helpers: Fix memory leak in lwmi_dev_evaluate_int() lwmi_dev_evaluate_int() leaks output.pointer when retval == NULL (found by sashiko.dev [1]). Fix it by moving `ret_obj = output.pointer' outside of the `if (retval)' block so that it is always freed by the __free cleanup callback. No functional change intended. (CVE-2026-63839)

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

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

  - 已解決 Linux 核心中的下列弱點：mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the last page device-exclusive via HMM_DMIRROR_EXCLUSIVE. Trigger node reclaim through sysfs. Now, in try_to_unmap_one(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nr_pages to 15. In the next pvmw walk, this nr_pages gets reused on a device-exclusive pte, thus potentially corrupting folio refcount/mapcount. At the moment, I have a userspace program which can make the kernel spit out a trace, but the blow up is in folio_referenced_one(), because there are existing bugs in the interaction between device-private and rmap (which too I am investigating). I did a one liner kernel change to avoid going into folio_referenced_one(), and the kernel blows up at folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted. Note that the bug is there not since file folio batching but lazyfree folio batching, since device-exclusive only works for anonymous folios. Userspace visible effect is simply kernel crashing somewhere due to refcount/mapcount corruption. (CVE-2026-63950)

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

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

  - batman-adv： tt：避免空的 VLAN 回應 提交 16116dac2339 （batman-adv：透過不傳送不一致的 TT TLVL 來防止 TT 請求風暴） 新增了對本機 （直接） TT 回應程式碼的檢查。但回應也可以由另一個節點使用全域 TT 狀態間接完成。若要避免原始修正中報告的此類不一致狀態，也請避免傳送空 VLAN 以從全域 TT 狀態回覆。（CVE-2026-64090）

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

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

  - IPv6：exthdrs：在 ipv6_hop_jumbo（） ipv6_hop_jumbo（） 呼叫 pskb_trim_rcsum（） 後重新整理 NH 指標，這可能會變更 skb 指標。讓我們重新計算 nh 指標，以確保任何更改都不會把事情搞砸。
    (CVE-2026-63924)

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

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

  - 已解決 Linux 核心中的下列弱點：ovpn: tcp - use cached peer pointer in ovpn_tcp_close() ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data() under rcu_read_lock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpn_peer_del(), re-dereferencing the ovpn_socket after the RCU read section has ended. Unlike ovpn_tcp_sendmsg(), which uses the same load under RCU, use after unlock pattern but is protected by lock_sock() held across the function, ovpn_tcp_close() runs without the socket lock: inet_release() invokes sk_prot->close() without taking lock_sock first. ovpn_socket_release() can therefore complete its kref_put -> detach -> synchronize_rcu -> kfree(sock) sequence concurrently, in the window after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences sock->peer. The synchronize_rcu() in ovpn_socket_release() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards. A reproducer follows the pattern of commit 94560267d6c4 (ovpn: tcp - don't deref NULL sk_socket member after tcp_close()): trigger a peer removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim. Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpn_peer_del() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpn_socket_new() under lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned up via a dedicated helper in a follow-up net-next series. (CVE-2026-64045)

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

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

  - 已解決 Linux 核心中的下列弱點：nfsd: avoid leaking pre-allocated openowner on unconfirmed retry race When find_or_alloc_open_stateowner() encounters an unconfirmed owner, it calls release_openowner() and sets oo = NULL. Control then falls through past the `if (oo)` guard -- which would have freed any pre-allocated `new` -- and unconditionally executes `new = alloc_stateowner(...)`. If `new` was already allocated on a prior iteration, the pointer is silently overwritten and the previous allocation (slab object + owner name buffer) is leaked. This requires a race:
    two NFSv4.0 OPEN threads with the same owner string, where a concurrent thread inserts a new unconfirmed owner into the hash between retry iterations. The window is narrow but repeatable under adversarial conditions. Fix by adding `goto retry` after `oo = NULL` so the already-allocated `new` is reused on the next iteration rather than overwritten. (CVE-2026-53394)

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

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

  - Meshtastic 是一個開源網狀網絡解決方案。在 2.7.23.b246bcd 版本之前，透過 iOS 應用程式管理時，通告包含格式錯誤字元編碼的User.long_name的單一節點可能會導致其他無線電無法透過 BLE 使用。格式錯誤的名稱不需要惡意製作，它可以由普通的緩衝區截斷產生，並且已觀察到在野外自然發生。至少有一個程式碼路徑可以將 NULL 終止字元放在多位元組序列的中間，從而在節點資料庫中留下格式錯誤的User.long_name。問題在下游浮出水面：iOS 應用程式強制執行編碼驗證，因此一旦節點資料庫包含中毒條目，就無法剖析該資料庫。這導致 BLE 同步進入失敗/重試循環，導致對受影響設備失去控制。對於使用 iOS 應用程式管理其無線電的典型使用者來說，在中毒節點從裝置上資料庫中老化之前，或者除非他們有替代管理路徑（例如 Python CLI，可用於手動識別和刪除違規條目），否則裝置實際上將無法使用。由於格式錯誤的名稱會透過網格傳播，因此單一受影響節點的暫時存在可能會在較長時間內降低廣大地理區域內 iOS 使用者的 BLE 管理。技術含量較低的使用者沒有直接的復原路徑。從 2.7.23.b246bcd 版開始，韌體新增了輸入清理和迴歸測試，以證明已經中毒的裝置可以恢復。這些應用程序還採取措施確保更優雅地處理格式錯誤的編碼序列。（CVE-2026-42566）

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

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

  - USB：dwc2：修正除錯程式碼中的釋放後使用 我們不允許在呼叫 usb_hcd_giveback_urb（） 之後取消參照 urb，因此請提前儲存 urb->status。（CVE-2026-63927）

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

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

  - ipv4：raw：拒絕具有 IHL < 5 的IP_HDRINCL封包 raw_send_hdrinc（） 驗證呼叫端提供的 IPv4 標頭是否符合訊息長度：iphlen = iph->IHL * 4;錯誤 = -EINVAL;if （iphlen > length） goto error_free;if （iphlen >= sizeof（*iph）） { /* 修正 saddr， tot_len， id， csum， transport_header */ } 但是，它不會拒絕 ihl < 5。對於此類封包，會跳過 if （iphlen >= sizeof（*iph）） 分支，保留特製的 iphdr，但封包仍會傳遞給 __ip_local_out（） 及以後。讀取 iph->ihl 的下游消費者假設一個合理的值：net/ipv4/ah4.c：ah_output（） 特別是從 top_iph->ihl * 4 中減去 sizeof（struct iphdr），並將 （signed-int-negative，然後轉換為 size_t） 結果傳遞給 memcpy（），從而產生長度接近 SIZE_MAX 的 OOB 存取和主機核心錯誤。根據定義，具有 ihl < 5 的 IPv4 標頭格式錯誤 （RFC 791：網際網路標頭長度是網際網路標頭的長度，以 32 位元字表示... 請注意，正確標頭的最小值為 5。核心不應該願意將這樣的封包注入自己的輸出路徑。拒絕 iphlen < sizeof（*iph） 以及現有的 iphlen >長度檢查。這符合重新進入 IP 堆疊的本機建構封包必須通過外部封包將要接受的相同基本健全性測試的原則。一旦它落地，fixup 分支周圍的 if （iphlen >= sizeof（*iph）） 包裝器就會變得多餘;保留在原處以保持補丁最小且對反向移植友好。後續行動可以解開它。請注意，提交 86f4c90a1c5c （ipv4、ipv6：確保原始通訊端訊息足夠大以容納 IP 標頭） 可確保訊息緩衝區足夠大以容納 iphdr，但不會限制自我報告的 iph->ihl。可連線性：格式錯誤的封包來源是具有 CAP_NET_RAW 的任何呼叫端，包括核心上 user+net 命名空間中的無特權處理程序 （具有 CONFIG_USER_NS=y）。重現的 AH 崩潰還需要在傳出路由上匹配的 xfrm AH 策略;授予CAP_NET_ADMIN的容器可以在其 netns 中安裝該狀態和原則。回送會繞過xfrm_output，因此觸發程式會使用真正的 netdev。在 UML + KASAN 上重現：在 addr 0x0 發生核心模式錯誤，在當機地點發生 memcpy_orig。相同的形狀在無根 Docker 容器內重現，並在 --cap-add 庫存發行版核心上進行NET_ADMIN。
    (CVE-2026-64114)

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

ID	名稱	嚴重性
329001	Plone 2.5.x < 2.5.5 / 3.x < 3.3.6 / 4.x < 4.0.4 / 4.1.x < 4.1.1 多個漏洞（HF 20110531）	medium
329000	Plone < 5.2.3 多個漏洞	high
328999	Plone < 3.1.8 MitM	critical
328998	Plone < 3.0.0 多個弱點	critical
328968	Oracle Coherence (2026 年 7 月 CPU)	medium
328967	Tenable Security Center 多個弱點 (TNS-2026-19)	high
328966	Tenable Security Center 多個弱點 (TNS-2026-19)	critical
328864	Amazon Corretto Java 17.x < 17.0.20.8.1 多個弱點	high
328862	Amazon Corretto Java 8.x < 8.502.07.1 多個弱點	high
328861	Amazon Corretto Java 11.x < 11.0.32.9.1 多個弱點	high
328860	Azul Zulu Java 多個弱點 (2026-07-21)	high
328839	Nutanix AOS：多個弱點（NXSA-AOS-7.6）	critical
328723	Linux Distros 未修補弱點：CVE-2026-49145	high
328722	Linux Distros 未修補弱點：CVE-2026-10037	high
328721	Linux Distros 未修補弱點：CVE-2026-15109	medium
328718	Linux Distros 未修補弱點：CVE-2026-49147	high
328714	Linux Distros 未修補弱點：CVE-2026-49146	high
328713	Linux Distros 未修補弱點：CVE-2026-15170	medium
328706	Linux Distros 未修補弱點：CVE-2026-59879	high
328703	Linux Distros 未修補弱點：CVE-2026-15166	medium
328696	Linux Distros 未修補弱點：CVE-2026-59880	high
328675	Linux Distros 未修補的弱點: CVE-2026-60137 (已過時)	critical
328674	Linux Distros 未修補弱點：CVE-2026-15811	medium
328673	Linux Distros 未修補弱點：CVE-2026-15812	medium
328349	Linux Distros 未修補弱點：CVE-2026-64205	medium
328348	Linux Distros 未修補弱點：CVE-2026-64189	high
328347	Linux Distros 未修補弱點：CVE-2026-64187	medium
328346	Linux Distros 未修補弱點：CVE-2026-64191	high
328345	Linux Distros 未修補弱點：CVE-2026-35591	high
328344	Linux Distros 未修補弱點：CVE-2026-64192	medium
328343	Linux Distros 未修補弱點：CVE-2026-64207	medium
328342	Linux Distros 未修補弱點：CVE-2026-64620	critical
328341	Linux Distros 未修補弱點：CVE-2026-33327	high
328340	Linux Distros 未修補弱點：CVE-2026-33328	medium
328339	Linux Distros 未修補弱點：CVE-2026-64190	medium
328338	Linux Distros 未修補弱點：CVE-2026-64206	high
328337	Linux Distros 未修補弱點：CVE-2026-64193	critical
328336	Linux Distros 未修補弱點：CVE-2026-39879	high
328335	Linux Distros 未修補弱點：CVE-2026-64194	high
328334	Linux Distros 未修補弱點：CVE-2026-64188	high
328333	Linux Distros 未修補弱點：CVE-2026-35590	medium
328330	Linux Distros 未修補弱點：CVE-2026-63839	medium
328329	Linux Distros 未修補弱點：CVE-2026-63950	high
328328	Linux Distros 未修補弱點：CVE-2026-64090	medium
328327	Linux Distros 未修補弱點：CVE-2026-63924	critical
328326	Linux Distros 未修補弱點：CVE-2026-64045	high
328325	Linux Distros 未修補弱點：CVE-2026-53394	high
328324	Linux Distros 未修補弱點：CVE-2026-42566	high
328323	Linux Distros 未修補弱點：CVE-2026-63927	high
328322	Linux Distros 未修補弱點：CVE-2026-64114	high

偵測

Nessus 的 Misc. 系列

medium

high

critical

critical

medium

high

critical

high

high

high

high

critical

high

high

medium

high

high

medium

high

medium

high

critical

medium

medium

medium

high

medium

high

high

medium

medium

critical

high

medium

medium

high

critical

high

high

high

medium

medium

high

medium

critical

high

high

high

high

high