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

  - netfilter： flowtable：publish GC-visible tuple last nf_flow_table_iterate（） 僅將原始方向元組節點視為擁有項目。先發佈原始節點可讓 GC 在 flow_offload_add（） 仍在插入回覆節點時觀察並釋放流程。先發佈回覆節點，最後發佈原始節點，讓 GC 永遠不會看到部分安裝的流程。KASAN 可以在 flowtable/rhashtable 路徑（rht_deferred_worker、jhash、flow_offload_del、flow_offload_lookup 等）中觸發 slab-use-after-free 讀寫報告。（CVE-2026-74746）

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

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

  - 已透過改進狀態管理解決此問題。此問題已在 Safari 26.6.1、 iOS 18.7.10 和 iPadOS 18.7.10、 iOS 26.6.1 和 iPadOS 26.6.1、 macOS Tahoe 26.6.2、 visionOS 27 中修復。處理惡意特製的 Web 內容可能會導致 Safari 意外當機 (CVE-2026-65336)。

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

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

  - crypto： qce - 修正 devm_qce_register_algs 中的錯誤路徑 如果 ops->register_algs（） 失敗，錯誤路徑會重複呼叫來自失敗註冊的相同 ops->unregister_algs（）。改用迴圈索引來取消註冊先前註冊的演算法。（CVE-2026-80565）

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

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

  - 改善鎖定後，解決了一個記憶體損毀弱點。已在 Safari 26.6.1、iOS 18.7.10 和 iPadOS 18.7.10、iOS 26.6.1 和 iPadOS 26.6.1、macOS Tahoe 26.6.2、visionOS 27 中修復此問題。
    處理惡意特製的 Web 內容可能會導致 Safari 意外當機 (CVE-2026-64782)。

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

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

  - 已解決 Linux 核心中的下列弱點：s390/zcrypt: Pad trailing CCA or EP11 message with zeros The both functions xcrb_msg_to_type6cprb_msgx() and xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a kernel buffer based on the message length. But on further processing the message is supposed to be 4 byte length adjusted. Thus up to 3 bytes of uninitialized kernel memory are forwarded to further processing steps and may unwanted expose kernel memory to the crypto card firmware. This patch contains code to pad the gap between user space copied message and message buffer length sent down to further processing of the CCA or EP11 message to zeros. (CVE-2026-80543)

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

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

  - block：釋放從未新增的磁碟時停止逾時計時器 disk_release（） 會復原 blk_mq_init_allocated_queue（） 對於在 add_disk（） 之前探查失敗的磁碟，但它只會呼叫 blk_mq_exit_queue（）。那裡沒有任何東西會停止 q->timeout，並且該計時器會向前滾動：它會保持擱置狀態，直到下次到期，而不是直到最後一個請求完成。因此，如果驅動程式在新增磁碟之前發出任何 I/O，則request_queue會釋放，同時仍連結至計時器滾輪貯體。提交 6f8191fdf41d （區塊：簡化磁碟關機） 丟棄了用來停止它的 blk_cleanup_queue（） 呼叫。
    __del_gendisk（） 和 blk_mq_destroy_queue（） 仍然如此;只有探查失敗路徑遺失了它。nvme 之所以到達那裡，是因為 nvme_update_ns_info（） 在新增磁碟之前在 ns->queue 上提交報告區域或 FDP io-mgmt-recv，因此稍後的故障 - 並行重設設定NVME_CTRL_FROZEN，或 device_add_disk（） 失敗 - 在計時器布防的情況下落在 put_disk（） 中： 錯誤： KASAN：在 detach_if_pending+0x30c/0x340 中釋放後使用 slab-use-after-free by task kworker/u8：2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c 在 addr ffff888004d71310 寫入大小 8 +/ kernel/time/timer.c：1621 blk_sync_queue+0x22/0x40 block/blk-core.c：222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c：5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c：3264 由工作 34 分配： __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c：4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c：4146 由工作 0 釋放： blk_free_queue_rcu+0x3a/0x50 block/blk-core.c：254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c：2857 在那裡同步的佇列是 ctrl->admin_q，只有受害者與釋放佇列的懸空條目共用一個計時器輪桶;在 enqueue_timer（） 中跳閘的其他執行，
    __run_timers（） 或 blk_mq_timeout_work（）。使用除錯修補程式失敗的 nvme_alloc_ns（） 使其具有確定性：一個洩漏的計時器在幾秒鐘內使 KASAN 跳閘，而 1987 年修補的版本不會產生 splat。
    在 blk_mq_exit_queue（） 之前停止計時器和佇列工作專案，就像 blk_mq_destroy_queue（） 一樣。
    由 FuzzNvme 發現。（CVE-2026-80589）

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

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

  - drm/amdgpu：禁止在每個區塊的一次提交 amdgpu_cs_pass1（） 分派中出現多個 FENCE 區塊chunk_id，而不會拒絕重複的 ID。p->uf_bo 是單插槽欄位，因此攜帶兩個 AMDGPU_CHUNK_ID_FENCE 區塊的提交會執行 amdgpu_cs_p1_user_fence（） 兩次，第二次執行會以新引用的 BO 覆寫 p->uf_bo，而不會刪除第一個執行所取得的參考。amdgpu_cs_parser_fini（） 僅取消引用最終的 p->uf_bo，因此除了最後一個區塊之外，每個 FENCE 區塊都會洩露一個 BO 引用。洩漏的 BO 比處理關閉和處理程序退出的壽命還要長。拒絕重複的 FENCE 區塊，就像提交 fec5f8e8c6bc （drm/amdgpu：不允許在一次提交中使用多個BO_HANDLES區塊） 一樣，用於 p->bo_list。（從提交 665b1fc2a1845206408f9a2c6da67101789edb82 中挑選）（CVE-2026-80539）

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

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

  - ASoC：tas2562：磁區寫入的驗證值 tas2562_volume_control_put（） 不會對使用者空間寫入的控制值執行任何驗證，它會使用它來在固定大小陣列中查詢值，該值很容易溢位，然後將它取得的任何值寫回裝置。新增驗證，確認我們正在載入陣列中的值。（CVE-2026-80526）

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

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

  - ASoC： SOF： ipc4-pcm： 在 IPC 逾時的情況下繼續管線觸發程式 如果韌體狀態損毀或 IPC 逾時，請忽略管線狀態變更的 IPC 錯誤。如果韌體崩潰，核心仍需要經歷狀態變更以重設其內部，以便下次啟動 DSP 時能夠正常運作。IPC 逾時的情況有點問題，但它的根本原因是系統調度阻塞的結果，韌體確實接收並處理了訊息，但回覆處理被 SOF 堆疊外部的問題阻塞。到目前為止，處理此問題的最佳方法是繼續設定狀態。（CVE-2026-80581）

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

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

  - drm/panthor：當韌體區段 VA 範圍為空時，跳過零大小韌體區段 panthor_fw_load_section_entry（） 會跳過 BO 建立。如果將這類區段新增至韌體區段清單，則 section->mem 會保留為 NULL。稍後重新載入和拔除路徑會逐一查看所有韌體區段並取消參照 section->mem，這可能會導致 NULL 指標解除參照。零大小的韌體區段有效，因此請接受它們作為無操作項目，但跳過將它們新增至區段清單。（CVE-2026-80577）

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

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

  - s390/vfio_ccw：確保讀取/寫入區域的索引在範圍內 功能鏈的引入正確地將區域索引限制在功能本身的範圍內，但忽略了對現有讀取/寫入區域也應該強制執行的這樣做。（CVE-2026-80552）

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

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

  - 已解決 Linux 核心中的下列弱點：s390/zcrypt: Improve EP11 CPRB length and overflow checks The xcrb_msg_to_type6_ep11cprb_msgx() function lacks proper input validation, creating security vulnerabilities: 1. Missing minimum size validation: The ep11_cprb structure and subsequent payload fields (pld_tag, pld_lenfmt) are copied from userspace without verifying sufficient buffer length.
    2. Arithmetic overflow in length calculations: CEIL4 alignment could overflow, bypassing size checks and enabling buffer overflows. 3. The payload is asn1 encoded but the function just uses a simple c struct overlay to access some fields of the payload. Fix by using size_t for length calculations, adding U32_MAX boundary checks after alignment, and validating minimum request size and minimum reply size before copying from userspace. Do a very simple asn1 parsing of the payload up to the function value field.
    (CVE-2026-80545)

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

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

  - s390/vfio_ccw： 將 cp 清除移出無法運作 當裝置遺失且 （根據定義） 不再運作時，會呼叫 fsm_notoper（） 常式。由於這可能會從驅動程式的正常行為以非同步方式發生，因此在呼叫序列中保留其他鎖定時可能會發生清除， （特別是 cio 子通道鎖定） 。將 private->cp 資源的清除推送至工作佇列，可從該鎖定序列下完成，而未來的修補程式可以安全地管理鎖定需求。（CVE-2026-80549）

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

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

  - libceph：避免使用來自 primary_temp 的無效 osd 索引 從 Ceph 監視器或 OSD 收到的損毀的 osdmap 可能包含不存在的 pg_temp、primary_temp、pg_upmap 和 pg_upmap_items 部分的 osd 索引，即大於 max_osd 或小於 CEPH_HOMELESS_OSD （-1）。這些索引用於在 ceph_pg_to_up_acting_osds（） 中建立向上和執行的集合，從 calc_target（） 呼叫。雖然大多數這些 osd 索引都經過檢查，但來自 primary_temp 的索引卻沒有。隨後，這可能會導致 calc_target（） 傳回此 （可能無效的） 索引作為 （linger） 要求的目標 osd。因為 osd_state、osd_weight 和 osd_addr 陣列只包含max_osd項目 （索引為 0 到 max_osd -1） ，所以在嘗試從這些陣列讀取值時，這會導致越界存取。此修補程式透過向 get_temp_osds（） 新增檢查來修正此問題，以便僅使用primary_temp中的有效 osd 索引，如果無效，則會回復為使用 pg_temp 中的主要索引或向上集。[ 伊德里奧莫夫：變更日誌 ]（CVE-2026-80558）

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

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

  - mptcp：在 RX 路徑錯誤上回收向前配置的記憶體 在提交 9db5b3cec4ec （mptcp：從子流借用前置記憶體） 之後，在將 skb 排入接收佇列之前，接收路徑中的錯誤不會觸發向前配置的記憶體回收。在捨棄 skb 時明確回收記憶體，以防止在病理性捨棄情況下無限增長前置記憶體。（CVE-2026-80588）

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

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

  - s390/vfio_ccw： 如果 cp_init（） 失敗，則釋放所有記憶體 一旦 I/O 成功完成，或 cp_prefetch（） 失敗，則呼叫常式 cp_free（） 以取消釘選/釋放任何記憶體。但如果 cp_init（） 失敗，且未啟用 cp->initialized，則無法使用相同的常式來釋放所有記憶體。嘗試在 ccwchain_handle_ccw（） 中解決此問題，其中針對目前處理的 CCW 區段進行對 ccwchain_free（） 的單一呼叫。但這會洩漏已配置為相同通道程式一部分的其他區段 （作為通道傳輸的結果而建立）。透過在遞迴 ccwchain_handle_ccw（）/ccwchain_loop_tic（） 邏輯之外執行清理來解決此問題。（CVE-2026-80555）

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

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

  - drm/amdgpu：修正 UVD 解碼影像最小大小計算 這需要使用間距而不是寬度。還要拒絕超過 4096 的音高以避免溢出。（從提交 b41c8cb12e202b220353332ab87dc01a11f69304 中挑選）（CVE-2026-80540）

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

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

  - s390/qeth：驗證 SNMP 和 ARP 查詢 ioctls 中的使用者緩衝區長度 qeth_snmp_command（） 和 qeth_l3_arp_query（） 配置以使用者提供的長度 （udata_len） 大小調整的緩衝區，而不檢查下限，然後將 udata_offset 設定為固定的非零值，並將兩者傳遞至回覆回呼。回呼使用 if （（udata_len - udata_offset） < len） 對副本進行邊界檢查）兩個欄位都是 u32，因此小於 udata_offset 的udata_len會使減法換行和檢查通過，並且後面的 memcpy（） 寫入超過分配。udata_len為 0 也會產生來自 kzalloc（） 的ZERO_SIZE_PTR，而現有的 NULL 檢查無法擷取此。在配置之前拒絕小於 udata_offset 的緩衝區，因此回呼減法無法再反向溢位。（CVE-2026-80584）

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

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

  - mmc：atmel-mci：修正 atmci_remove 中由於爭用情形造成的釋放後使用 atmci_probe，&host->bh_work 與 atmci_work_func 綁定，atmci_interrupt、atmci_timeout_timer 和 atmci_dma_complete 都可以在 system_bh_wq 上將這項工作排入佇列。如果我們移除模組，atmci_remove會進行清理，並在移除回呼傳回後釋放配置給具有 devm_kzalloc（） 的主機的記憶體，而上述工作可能仍處於擱置狀態或正在執行中。可能導致 UAF 錯誤的操作順序如下： CPU0 CPU1 |atmci_interrupt |queue_work（system_bh_wq， | &host->bh_work） atmci_remove |atmci_cleanup_slot（...） |atmci_writel（主機，ATMCI_IDR，~0UL） |timer_delete_sync（&host->timer） |dma_release_channel（host->dma.chan） |free_irq（platform_get_irq（pdev， 0）， host） | |atmci_work_func |使用主機 // 之後發行的 devm 資源 |移除傳回，主機已釋放 | |使用主機 （釋放後使用） 在所有可以排程工作的來源 （IRQ 處理常式、逾時計時器和 DMA 完成回呼） 停止之後，以及在繼續執行 atmci_remove 中的剩餘清理之前，請先取消工作來修正它。（CVE-2026-80556）

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

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

  - ceph：修正過時mds_wanted懸置的 __ceph_get_caps（） 當用戶端不再保留「FILE_RD」時，讀取器可以在 __ceph_get_caps（） 中永久停擺，但本機上限狀態仍會指出已需要該功能 （透過「mds_wanted」）。觸發此問題的一種方法是撤銷 MDS 上限。如果另一個用戶端執行衝突的作業，MDS 可以撤銷讀取器的「FILE_RD」;然後，下一次讀取必須重新取得「FILE_RD」。如果在引發 'cap->mds_wanted' 之後，應該要求 'FILE_RD' 的上限更新從未到達 MDS，則讀取器只會保留非檔案上限，而本機 'mds_wanted' 仍包含檔案讀取上限。在該狀態下，try_get_cap_refs（） 看到「需要 <= mds_wanted」並傳回 0，因此
    __ceph_get_caps（） 只是等待「i_cap_wq」。如果本應要求「FILE_RD的上限更新在引發「上限>mds_wanted之後從未到達 MDS，則不會傳送進一步的要求，而且服務員可以無限期地休眠，直到不相關的上限流量碰巧喚醒它為止。排序問題是，在「CEPH_MSG_CLIENT_CAPS 訊息」實際排入佇列等待傳送之前，__prep_cap（） 中更新了「cap->mds_wanted」。這使得一個字段同時提供兩種不同的含義：該客戶端想要什麼，以及客戶認為 MDS 已經知道它想要什麼。適當的修復方法是拆分這些狀態並追蹤上限更新是否實際在進行中或 MDS 已觀察到。然而，稍後簡單地移動「上限>mds_wanted分配」是不夠的：將訊息排入信使中的佇列並不能保證 MDS 處理了該特定的想要集，並且重新連接或訊息遺失仍然可能使該假設失效。正確修復此問題需要對上限狀態機進行更大的重做。
    為了允許更簡單的反向移植到穩定的核心，此修補程式實施了更簡單的解決方法：- 停止在 __ceph_get_caps（） 中永遠等待;經過有限等待後，回退到續約路徑 - 每當 inode 仍然沒有實際持有所需的上限時，使 ceph_renew_caps（） 發出同步「OPEN」請求，而不是只調用 ceph_check_caps（） 額外的 issued-vs-wanted 簽入 ceph_renew_caps（） 是必要的，因為之前的測試只檢查了 inode 是否仍然有任何真正的上限。撤銷後這還不夠：用戶端仍然可以保留類似「pL」的內容，但完全缺少「FILE_RD」。在這種情況下，回退到 ceph_check_caps（） 是不夠的，因為它仍然信任「cap->mds_wanted」並且可能不重新發送任何內容。透過在採用非同步路徑之前要求 '（issued &; wanted） == wanted'，程式碼僅在實際發出「通緝上限」時才使用 ceph_check_caps（）。否則，它會傳送同步「OPEN」續約。當所需的上限已發出時，這會保留現有的非同步快速路徑、避免變更上限狀態語意，並透過保證停滯的等候程式最終透過不依賴過時「mds_wanted」狀態的路徑重試來修正懸置。[ idryomov：將CEPH_GET_CAPS_WAIT_TIMEOUT從 libceph.h 移至 mds_client.h，格式化]（CVE-2026-80527）

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

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

  - 已透過改進記憶體管理解決釋放後使用問題。已在 Safari 26.6.1, iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6.1 and iPadOS 26.6.1, macOS Tahoe 26.6.2, tvOS 27, visionOS 27, watchOS 27 中修復此問題。處理惡意特製的 Web 內容可能導致處理程序意外損毀。(CVE-2026-64715)

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

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

  - Hugo 的預設 fenced-code-block 渲染器會將從 code-fence 資訊字串取得的屬性值寫入轉譯的 HTML 中，而不會逸出它們。markup/internal/attributes/attributes.go 中的新功能在儲存時將每個屬性值從位元組切片轉換為字串，故意刪除過去在那裡發生的逸出，並且同一檔案中的 RenderAttributes 僅轉義仍然是位元組切片的值，因此永遠不會到達其逸出分支，並且每個值都是逐字寫入的。該函數的文件指出它執行字串屬性的 HTML 逸出，但它沒有。因此，資訊字串中屬性值內的引號會終止屬性，並允許將其他屬性（包括事件處理常式）放置在包裝函式元素上，且指令碼會針對載入頁面的每位訪客執行。此路徑是在預設配置下到達的，啟用了程式碼圍欄，並且沒有 goldmark 的不安全設定或任何自訂渲染鉤子。剖析屬性時，會篩選以 on 開頭的屬性名稱，因此透過值而不是名稱來完成插入。
    (CVE-2026-10618)

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

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

  - s390/vfio_ccw：實作 crw 鎖定 與涵蓋同步 I/O 提交和非同步中斷的 channel_program 結構不同，CRW 區域完全依賴來自硬體的非同步事件。實作鎖定來管理這些承載的清單，以確保讀取它們一致。
    (CVE-2026-80547)

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

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

  - 已解決 Linux 核心中的下列弱點：riscv: lib: Fix ZBB strnlen reading past count boundary The ZBB-optimized strnlen loop loads one word ahead before checking the aligned boundary: REG_L t1, SZREG(t0) // load next word addi t0, t0, SZREG // advance orc.b t1, t1 bgeu t0, t4, 4f // boundary check AFTER load where t4 = (s + count) & -SZREG. When s is aligned and count is a multiple of SZREG, t4 equals s + count and the loop loads a full word starting at exactly s + count. If s + count falls on a page boundary with the next page unmapped, this faults. Fix by computing the aligned boundary from the last valid byte (s + count - 1) instead of s + count. This makes the loop stop at the word containing the last valid byte rather than potentially loading the word after it. The count == 0 case is already handled by the beqz early exit. Also add a pre-loop guard (bgeu t0, t4) for the case where all valid bytes fit within the first word. With the adjusted boundary, t4 can equal t0, and entering the loop with stale register state from the first-word processing would produce incorrect results. The final minu clamp ensures the result is still correct when the last loaded word extends past s + count - 1 within the same aligned word. (CVE-2026-74751)

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

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

  - Hugo 的 security.http.urls 允許清單是資源對出站擷取的唯一控制。GetRemote，它只會檢查 URL 文字。config/security/securityConfig.go 中的 CheckAllowedHTTPURL 會套用已設定的模式清單，然後重新檢查整數、十六進位或八進位 IPv4 主機的規範化形式，但它永遠不會解析主機名稱，也永遠不會檢查 HTTP 用戶端實際連線的位址。resources/resource_factories/create/create.go 中建構的用戶端不會安裝撥號時間勾點，因此在連線時也不會進行檢查。因此，解析為回送、私有或雲端中繼資料位址的主機名稱符合原則，且回應內文會內嵌在產生的網站中。攻擊者若能透過內容提供 URL，例如 front-matter 欄位或 CMS 欄位，就可以讓組建擷取內部端點，並在靜態輸出中發佈回應，讓組建成品本身執行資料。（CVE-2026-10582）

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

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

  - mptcp： options：在大小意外的情況下重設 DSS 欄位 遠端對等可能會傳送大小錯誤的格式錯誤的 DSS，然後傳送另一個 DSS 或 MPC + 資料。在這種情況下，第一個子選項將被忽略，但會留下一些欄位的寫入，這可能會導致不一致或存取未初始化的資料。
    明確重設可能已修改的欄位，以防出現非預期的大小。（CVE-2026-80586）

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

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

  - 輸入：iforce - 驗證輸入封包長度 iforce_process_packet（） 從搖桿、滾輪和狀態封包讀取固定欄位，而無需先檢查其長度。特別是，共用帽子和按鈕協助程式會無條件讀取資料[6]。狀態尾部是一連串 16 位元效果位址，但也會消耗不完整的最終位址。成功的零長度 USB URB 會在呼叫一般剖析器之前，額外讀取封包識別碼。拒絕零長度 USB 傳輸，需要七位元組的搖桿和滾輪前置詞以及兩位元組的狀態前置詞，並且僅使用完整的狀態尾部位址。（CVE-2026-80573）

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

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

  - 輸入：sur40 - 修正輸入裝置註冊順序 在 sur40_probe（） 中，先前在 V4L2 視訊裝置和vb2_queue元件完全初始化之前就呼叫了 input_register_device（）。如果使用者空間在註冊後立即開啟輸入裝置，則 sur40_open（） 會觸發並啟動 sur40_poll（） 工作執行緒。此工作執行緒呼叫 sur40_process_video（） 並存取未初始化的vb2_queue結構，從而導致資料爭用和潛在的系統崩潰。此外，如果 V4L2 或視訊註冊在 input_register_device（） 成功後失敗，錯誤路徑會變成在成功註冊的裝置上呼叫 input_free_device（） 而不是 input_unregister_device（），從而損壞輸入核心狀態。將 input_register_device（） 移至 sur40_probe（） 的最後。這可確保 V4L2 和視訊佇列結構在輪詢開始之前完全初始化，並自然解決錯誤路徑錯誤，因為現在只有在輸入註冊尚未發生時才會呼叫 input_free_device（）。若要維持嚴格的 LIFO （後進先出） 拆卸順序，也請將 input_unregister_device（） 移至 sur40_disconnect（） 的開頭。這可確保在取消註冊 V4L2 視訊元件或控制處理常式之前，輸入輪詢背景工作執行緒會停止。
    (CVE-2026-80559)

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

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

  - 已透過改進狀態管理解決此問題。已在 Safari 26.6.1、iOS 18.7.10 和 iPadOS 18.7.10、iOS 26.6.1 和 iPadOS 26.6.1、macOS Tahoe 26.6.2、visionOS 27 中修復此問題。處理惡意特製的 Web 內容可能會導致 Safari 意外當機 (CVE-2026-65335)。

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

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

  - fbdev：綁定模式 sysfs 輸出到 sysfs 緩衝區 mode_string（） 使用 snprintf（），它可以傳回大於剩餘緩衝區空間的值。show_modes（） 會將傳回值累積到 i 中，而不檢查 i 是否已達到 PAGE_SIZE，如果 modelist 足夠長，則會導致偏移量通過 sysfs 緩衝區。將 size 參數新增至 mode_string（） 並使用 scnprintf（） 僅傳回實際寫入的位元組。當位移已超過緩衝區時，新增提前傳回。在 show_modes（） 中，一旦緩衝區已滿，就停止累積。（CVE-2026-80580）

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

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

  - NLTK 之前 3.10.3 的 tgrep 模組中包含一個規則運算式拒絕服務 （ReDoS） 弱點。_tgrep_node_action 函數會編譯嵌入在 /regex/ 模式節點中的使用者提供的規則運算式，並透過 re.search 針對樹狀節點標籤執行它們，而無需任何驗證或逾時。
    控制 tgrep 模式的攻擊者 （例如，透過暴露於外部輸入的 tgrep_positions（） 或 tgrep_compile（） ） ） 可以提供觸發災難性回溯的模式，導致無限期的 CPU 飽和，從而阻止 Python 進程。（CVE-2026-80206）

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

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

  - ASoC： SOF： ipc4-topology： 在小組件設定之前重新整理影印機 IPC 有效負載 影印機小組件的ipc_config_data緩衝區會在ipc_prepare期間建置一次 （從sof_pcm_setup_connected_widgets呼叫） 並快取以供重複使用。針對主機影印機，此緩衝區包含具有 gtw_cfg.node_id （主機 DMA 識別碼） 的copier_data。對於 DAI 影印機，它還包括一個帶有 HDA 連結 DMA stream_id和dma_channel_id的dma_config_tlv預告片。暫停/繼續時，主機和連結 DMA 資料流程都會釋放，並使用可能不同的資料流程標籤重新配置。基礎copier_data和dma_config_tlv結構分別由 host_config 和 sdw_hda_dai_hw_params 正確更新。不過，由於小工具清單 （spcm->stream[].list） 會在暫停期間持續存在，因此sof_pcm_hw_params會跳過sof_pcm_setup_connected_widgets，而且ipc_prepare永遠不會再次執行以重建ipc_config_data。然後，過時的快取承載會傳送至具有開機時長 DMA 通道指派的韌體，導致 DMA 通道衝突，進而導致韌體錯誤和損毀。透過在傳送 IPC 訊息之前重新整理 sof_ipc4_widget_setup 中的copier_data和dma_config_tlv部分ipc_config_data來修正此問題。如此可確保承載一律反映目前的 DMA 狀態，而不論ipc_prepare是否已執行。對於 DAI 影印機，copier_data 中的 gtw_cfg.config_length 會在複製之前暫時膨脹，以包含 TLV 大小 （符合 ipc_config_data 配置），然後還原，以鏡像 sof_ipc4_prepare_copier_module 第一次建置緩衝區時所做的動作。（CVE-2026-80525）

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

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

  - 輸入：synaptics-rmi4 - 將 F54 背景工作錯誤傳播至 V4L2 佇列 以前，rmi_f54_buffer_queue（） 會等待背景工作執行緒完成，但會忽略其是否成功。如果背景工作程式失敗 （例如，因為逾時或暫存器讀取失敗），佇列執行緒會以無訊息方式傳回成功，將過時或未初始化的記憶體傳遞至使用者空間。新增「report_error」欄位以結構f54_data以儲存背景工作者的退出狀態。背景工作完成後，在 rmi_f54_buffer_queue（） 中檢查此欄位，並在發生錯誤時將緩衝區標記為VB2_BUF_STATE_ERROR。（CVE-2026-80567）

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

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

  - s390/vfio_ccw：確保第一個 IDAW 保持不變 清單中的第一個 IDAW 不需要像所有其他 IDAW 一樣位於 2K/4K 邊界上，因此會單獨讀取，以準確計算讀取完整 IDAL 所需的緩衝區大小。驗證在第一個 IDAW 中找到的位址在讀取之間是否不變，以確保使用一組一致的 IDAW。（CVE-2026-80551）

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

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

  - xfs：傳播 xfs_rtginode_load xfs_rtginode_ensure（） 的錯誤會將除 -ENOENT 以外的所有 xfs_rtginode_load（） 錯誤視為成功。這可能會在 I/O、分配或損毀錯誤後，使即時群組 inode 處於未設定狀態。然後 Growfs 繼續前進，就好像 inode 已經加載一樣。只有 -ENOENT 表示需要建立 inode。將所有其他錯誤傳回給 growfs 呼叫端。（CVE-2026-80538）

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

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

  - 之前的 3.10.0 NLTK 版本在 Text.findall（） 和 TokenSearcher.findall（） 方法中包含一個規則運算式拒絕服務弱點，這些方法接受使用者提供的規則運算式，而無需驗證或逾時。攻擊者可以提供特製的正則運算式模式，導致災難性的回溯，導致 Python 進程的所有使用者無限期的 CPU 飽和和拒絕服務。（CVE-2026-80205）

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

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

  - ipvlan：從phy_dev繼承needed_headroom和needed_tailroom ipvlan 裝置在 ipvlan_init（） 期間從 phy_dev 繼承hard_header_len，但保留 needed_headroom 和 needed_tailroom 設定為 0。當底層phy_dev（或堆疊的下部裝置）需要額外的標頭/尾部空間（例如 macsec、ipsec、wireguard、隧道或具有 rx 餘量的 veth）時，計算封包餘量和尾部空間的上層無法保留足夠的空間。當 dev_hard_header（） / ipvlan_hard_header（） 在標頭資料前面加上或較低的裝置附加尾部時，這可能會導致重新配置額外負荷、skb 餘量反向溢位或 KASAN slab-use-after-free 當機。透過以下方式解決此問題： 1. 繼承 ipvlan_init（） 中phy_dev的needed_headroom和needed_tailroom。2. 當收到NETDEV_FEAT_CHANGE事件時，將needed_headroom和needed_tailroom更新傳播到 ipvlan_device_event（） 中附加的 ipvlan。（CVE-2026-74744）

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

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

  - 已透過改善記憶體處理解決此問題。此問題已在 Safari 26.6.1、 iOS 18.7.10 和 iPadOS 18.7.10、 iOS 26.6.1 和 iPadOS 26.6.1、 macOS Tahoe 26.6.2、 visionOS 27 中修復。處理惡意特製的 Web 內容可能會導致 Safari 意外當機 (CVE-2026-65338)。

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

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

  - 輸入：synaptics-rmi4 - 佇列忙碌時的 F54 區塊s_input 中途變更輸入 （診斷報告類型） 會變更報告大小。由於 V4L2 緩衝區是根據資料流程開始時的大小來配置，因此如果新的大小大於配置的緩衝區，在串流時變更輸入可能會導致堆積緩衝區溢位。如果 V4L2 佇列忙碌 （串流），則使用 -EBUSY 封鎖VIDIOC_S_INPUT來防止此情況發生。（CVE-2026-80568）

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

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

  - 已透過改善記憶體處理解決此問題。已在 Safari 26.6.1, iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6.1 and iPadOS 26.6.1, macOS Tahoe 26.6.2, tvOS 27, visionOS 27, watchOS 27 中修復此問題。
    處理惡意特製的 Web 內容可能導致記憶體損毀。(CVE-2026-65341)

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

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

  - gpio：sloppy-logic-analyzer：透過解除綁定時的 debugfs 觸發程序修正釋放後使用 觸發程序 debugfs 檔案有一個手動滾動的 ->write 處理常式 （trigger_write（）），可取消參照每個裝置的gpio_la_poll_priv。
    該檔案是使用 debugfs_create_file_unsafe（） 建立的，並且處理常式永遠不會採用 debugfs 參照。
    當處理常式執行時，沒有任何內容會讓物件保持作用中。priv 是使用 devm_kzalloc（） 配置的。當平台裝置解除綁定時，devres 會釋放它。debugfs_create_file_unsafe（） 不安裝full_proxy包裝函式，因此 gpio_la_poll_remove（） 中的 debugfs_remove_recursive（） 不會等待正在進行的 trigger_write（）。那裡的blob_lock無濟於事，因為 trigger_write（） 從不接受它。因此，爭用解除綁定的寫入會寫入釋放的記憶體： trigger_write（） gpio_la_poll_remove（） priv = m->private buf = memdup_user（） [可能休眠] mutex_lock（&priv->blob_lock） debugfs_remove_recursive（） [no wait] mutex_unlock（&priv->blob_lock） （移除傳回; devres 釋放 priv） priv->trig_data = buf <-- use-after-free write priv->trig_len = count root 可透過 /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind 存取爭用。請改用 debugfs_create_file（） 建立觸發程序。它的full_proxy包裝器使 debugfs_remove_recursive（） 在返回之前耗盡任何正在進行的 ->write。釋放後使用在 KASAN 下得到確認，具有相同 debugfs_create_file_unsafe（） 和 devm_kzalloc（） 模式的最小再現（可根據要求提供）;它會在處理常式中產生 slab-use-after-free 寫入。（CVE-2026-80563）

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

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

  - 輸入：focaltech - 修正 focaltech_process_rel_packet 中的陣列越界 使 finger2 （以及 finger1） 無符號，這樣如果封包中的手指食指是 0，則減去 1 會建立一個陣列索引，該索引會溢位在現有的 FOC_MAX_FINGERS 檢查之上，正如現有註解所說，而不是寫入 state->fingers[-1]。（CVE-2026-80574）

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

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

  - 已透過改善邊界存取解決超出邊界寫入問題。已在 Safari 26.6.1、iOS 18.7.10 和 iPadOS 18.7.10、iOS 26.6.1 和 iPadOS 26.6.1、macOS Tahoe 26.6.2、visionOS 27 中修復此問題。
    處理惡意特製的 Web 內容可能會導致 Safari 意外當機 (CVE-2026-64784)。

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

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

  - eth： bnxt：取消 IRQ 關聯通知程式時避免鎖死 取消註冊 IRQ 關聯通知程式會同步等待回呼。bnxt 會在通知程式中鎖定 netdev 實例 （以重新啟動佇列），並取消相同鎖定下的工作。這顯然可能陷入僵局。將重新啟動移至非同步服務工作。佇列重新啟動對時間不太敏感。儲存新的 TPH 標籤，排程任務。
    安全取消服務任務已經解決。在 bnxt_request_irq（） 中，註冊通知程式、關聯和初始 TPH 程式設計的順序必須顛倒。我認為它以前是活潑的，因為用戶可以在安裝通知程序後立即觸發更新。有一個小的已知差距 - 如果 pcie_tph_get_cpu_st（） 在 init 時失敗並且目標標籤為 0，我們可能會錯過對條目進行編程。這似乎不值得修復，無論如何，程式碼到處都是跳過失敗。（CVE-2026-74745）

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

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

  - s390/vfio_ccw：取消現有工作佇列 io_work和crw_work工作佇列的初始化引出了一個問題，即是否應該取消初始化它們。在_release_dev中新增對應的清理標籤，以確保在私有結構釋放後不會分派工作。（CVE-2026-80553）

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

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

  - Nagios Core 之前 4.5.12 在 cmd.cgi 中包含一個跨網站要求偽造弱點，其中 CSRF 保護機制會在 NagFormId Cookie 缺失時通過驗證。攻擊者可以在他們不知情或未同意的情況下，製作惡意的跨網站 POST 請求，以目前經過驗證的使用者身分執行任意 Nagios 命令。（CVE-2026-48548）

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

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

  - 處理來自 Dia XML 專案檔案的網路匯流排物件時，Dia 圖編輯器中存在堆疊型緩衝區溢位弱點。在 objects/network/bus.c 中，bus_load（） bus_handles使用 attribute_num_data（） 從檔案屬性讀取匯流排控點的數量，而不驗證上限：
    匯流排>num_handles = attribute_num_data（attr）;後續移動匯流排控點時，bus_handle_moved（） 會在堆疊上配置兩個臨時陣列：parallel = （real *）g_alloca（num_handles * sizeof（real））;perp = （實數 *）g_alloca（num_handles * sizeof（實數））;由於num_handles完全由攻擊者透過專案檔控制，因此足夠大的值 （例如 262144 或更高） 會導致 g_alloca（） 消耗的堆疊空間超過預設執行緒堆疊限制 （在 Linux 上通常為 8 MB），從而導致堆疊溢位、SIGSEGV 和潛在的堆疊框架/傳回位址損毀。攻擊者可將bus_handles計數過多的匯流排物件內嵌在惡意 .dia 檔案中。利用攻擊要求受害者在 Dia 中開啟檔案（檔案對話方塊、命令列或檔案關聯）並觸發句柄操作（移動匯流排句柄），從而執行易受攻擊的程式碼路徑。objects/Misc/tree.c （複製自 bus.c） 中也存在相同的 g_alloca 模式，並且可能容易透過 Tree 物件遭受相同類別的攻擊。受影響的版本：Dia 0.98.0 和包含此程式碼的舊版;截至 2026 年 8 月 21 日，上游主機上已確認問題。上游報告： https://gitlab.gnome.org/GNOME/dia/-/issues/581(CVE-2026-77658）

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

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

  - libceph：修正 decode_locker（） 中的多個不安全解碼 cls_lock_client.c 中的 decode_locker（） 包含三個不安全的解碼操作，允許惡意或已入侵的 OSD 觸發 slab-out-of-bounds 讀取： 1. locker_id_t 名稱欄位的 ceph_decode_copy（） 沒有先前的邊界檢查。在 ceph_start_decoding（） 接受 struct_len=0 之後，如果 p == end，則讀取 sizeof（ceph_entity_name） = 9 位元組，超出已驗證的緩衝區邊界。2. locker_info_t標頭後的 *p += sizeof（struct ceph_timespec） 是未檢查的指標前進。惡意 OSD 可將 p 置於末尾，導致所有後續_safe檢查都針對虛假邊界通過。3. len = ceph_decode_32（p） 沒有前面的邊界檢查，緊接在後面的 *p += len 是無上限的。惡意 OSD 可以發送 len=0xffffffff，將 p GB 推進到末端並完全逃脫解碼視窗。透過將裸操作替換為安全變體來修正這三個操作： ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof（...） -> ceph_decode_skip_n ceph_decode_32（p） -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n 新增一個新標籤，以在任何邊界違規時傳回 -EINVAL。-EINVAL 在這裡是合適的：從 OSD 接收的資料在結構上是格式錯誤的，無論呼叫者或有線是否有過錯，這都是解碼合約的無效引數。攻擊者模型：多租用戶 Ceph 部署中的惡意或已入侵的 OSD 可針對任何發出 lock.get_info 類別方法的核心用戶端 （例如
    在 RBD 獨佔鎖定取得期間），除了建立 OSD 工作階段之外，沒有任何進一步的權限。[idryomov：使用 ceph_decode_skip_string（） 跳過描述，修剪變更日誌]（CVE-2026-80561）

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

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

  - libjpeg-turbo 3.2.0 在 PNG 載入器中包含整數除以零弱點。使用預設圖元格式，透過 tj3LoadImage12（） 或 tj3LoadImage16（） 處理具有非灰色調色盤的有效索引彩色 PNG 影像時，應用程式可能會觸發 alloc_sarray（） 中的除以零，從而導致 SIGFPE 和拒絕服務。（CVE-2026-75466）

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

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

  - 在 Linux 上，數個 OpenZFS ioctl 授權檢查會接受僅在使用者建立的無權限命名空間內保留的功能，作為等同於實際主機權限的功能，讓無權限的本機使用者執行需要 root 權限的作業。受影響的作業包括集區管理作業 （例如建立、匯入、銷毀）、集區事件記錄存取 （zpool events） 和錯誤插入 （zinject）。
    若要利用此問題，只需要允許本機使用者開啟 /dev/zfs （受本機裝置權限控管），且核心允許建立無權限的使用者命名空間。不需要事先存取目標集區或其基礎裝置。（CVE-2026-79619）

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

ID	名稱	嚴重性
340859	Linux Distros 未修補弱點：CVE-2026-74746	critical
340857	Linux Distros 未修補弱點：CVE-2026-65336	medium
340856	Linux Distros 未修補弱點：CVE-2026-80565	high
340855	Linux Distros 未修補弱點：CVE-2026-64782	low
340854	Linux Distros 未修補弱點：CVE-2026-80543	high
340853	Linux Distros 未修補弱點：CVE-2026-80589	critical
340852	Linux Distros 未修補弱點：CVE-2026-80539	medium
340851	Linux Distros 未修補弱點：CVE-2026-80526	high
340850	Linux Distros 未修補弱點：CVE-2026-80581	medium
340849	Linux Distros 未修補弱點：CVE-2026-80577	medium
340848	Linux Distros 未修補弱點：CVE-2026-80552	high
340847	Linux Distros 未修補弱點：CVE-2026-80545	high
340846	Linux Distros 未修補弱點：CVE-2026-80549	high
340845	Linux Distros 未修補弱點：CVE-2026-80558	critical
340844	Linux Distros 未修補弱點：CVE-2026-80588	high
340843	Linux Distros 未修補弱點：CVE-2026-80555	high
340842	Linux Distros 未修補弱點：CVE-2026-80540	high
340841	Linux Distros 未修補弱點：CVE-2026-80584	high
340840	Linux Distros 未修補弱點：CVE-2026-80556	high
340839	Linux Distros 未修補弱點：CVE-2026-80527	high
340838	Linux Distros 未修補弱點：CVE-2026-64715	medium
340837	Linux Distros 未修補弱點：CVE-2026-10618	medium
340836	Linux Distros 未修補弱點：CVE-2026-80547	high
340835	Linux Distros 未修補弱點：CVE-2026-74751	critical
340834	Linux Distros 未修補弱點：CVE-2026-10582	high
340833	Linux Distros 未修補弱點：CVE-2026-80586	critical
340832	Linux Distros 未修補弱點：CVE-2026-80573	medium
340831	Linux Distros 未修補弱點：CVE-2026-80559	high
340830	Linux Distros 未修補弱點：CVE-2026-65335	medium
340829	Linux Distros 未修補弱點：CVE-2026-80580	high
340828	Linux Distros 未修補弱點：CVE-2026-80206	high
340827	Linux Distros 未修補弱點：CVE-2026-80525	high
340826	Linux Distros 未修補弱點：CVE-2026-80567	medium
340825	Linux Distros 未修補弱點：CVE-2026-80551	critical
340824	Linux Distros 未修補弱點：CVE-2026-80538	high
340823	Linux Distros 未修補弱點：CVE-2026-80205	high
340822	Linux Distros 未修補弱點：CVE-2026-74744	critical
340821	Linux Distros 未修補弱點：CVE-2026-65338	medium
340820	Linux Distros 未修補弱點：CVE-2026-80568	high
340819	Linux Distros 未修補弱點：CVE-2026-65341	medium
340818	Linux Distros 未修補弱點：CVE-2026-80563	high
340817	Linux Distros 未修補弱點：CVE-2026-80574	high
340816	Linux Distros 未修補弱點：CVE-2026-64784	medium
340815	Linux Distros 未修補弱點：CVE-2026-74745	high
340814	Linux Distros 未修補弱點：CVE-2026-80553	high
340813	Linux Distros 未修補弱點：CVE-2026-48548	medium
340812	Linux Distros 未修補弱點：CVE-2026-77658	high
340811	Linux Distros 未修補弱點：CVE-2026-80561	critical
340810	Linux Distros 未修補弱點：CVE-2026-75466	medium
340809	Linux Distros 未修補弱點：CVE-2026-79619	high

偵測

Nessus 的 Misc. 系列

critical

medium

high

low

high

critical

medium

high

medium

medium

high

high

high

critical

high

high

high

high

high

high

medium

medium

high

critical

high

critical

medium

high

medium

high

high

high

medium

critical

high

high

critical

medium

high

medium

high

high

medium

high

high

medium

high

critical

medium

high