根據應用程式自我報告的版本號碼，遠端主機上執行的 Tenable Identity Exposure 低於 3.77.17 版。因此根據公告會受到多個弱點影響 TNS-2026-11

  - Node.js 的特權模型中有一個缺陷，允許攻擊者使用特製的相對符號連結路徑繞過 --allow-fs-read 和 --allow-fs-write 限制。藉由鏈結目錄和符號連結，僅獲授予目前目錄存取權的指令碼可逸出允許的路徑並讀取敏感檔案。這會破壞預期的隔離保證並啟用任意檔案讀取/寫入進而導致可能的系統入侵。 (CVE-2025-55130)

  - 若未正確驗證 SQL Server 中的指定輸入類型經授權的攻擊者即可提升網路權限。 (CVE-2026-26115)

  - Curl 中的不當存取控制允許經授權的攻擊者提升網路權限。
    (CVE-2026-21262)

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

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

  - 在某些情況下被要求執行交涉驗證的 HTTP 或 HTTPS 要求時libcurl 可重複使用錯誤的連線。 libcurl 設有近期連線集區以便後續要求可重複使用現有連線以避免額外負荷。重複使用連線時必須先符合一系列準則。由於程式碼中的邏輯錯誤由應用程式發出的要求可錯誤地重複使用相同伺服器 (已使用不同認證進行驗證) 的現有連線。其中一個根本原因是交涉有時會驗證 *連線*而非 *要求*這與 HTTP 的運作方式相反。有一個應用程式其允許使用 `user1:password1` 對伺服器 (回應需要的 Negotiate) 交涉驗證然後對同樣使用 Negotiate 但具有 `user2:password2` 的相同伺服器執行另一個作業 (在之前的連線仍然有效時) -第二個要求錯誤地重複使用了相同的連線而且因為之後它會看到已經進行了交涉交涉所以它只是透過該連線認為它使用的是 user2 認證來傳送要求而實際上它仍在使用已針對 user1... 驗證的連線使用 `CURLOPT_HTTPAUTH` 設定要使用的一組驗證方法。應用程式可停用 libcurl 的連線重複使用功能進而減輕此問題的方法是使用下列其中一個 libcurl 選項來變更連線重複使用或不重複使用的方式「CURLOPT_FRESH_CONNECT」、「CURLOPT_MAXCONNECTS」和「CURLMOPT_MAX_HOST_CONNECTIONS」(若使用 curl_multi API)。 (CVE-2026-1965)

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

遠端 Ubuntu 22.04 LTS/24.04 LTS/25.10 主機上安裝的套件受到 USN-8084-1 公告中所提及的多個弱點影響。

    Zhicheng Chen 發現，curl 可能會針對 Negotiate 驗證的 HTTP 或 HTTPS 要求，不正確地重複使用錯誤的連線。這可導致使用來自不同連線的憑證，這與預期行為相反。(CVE-2026-1965)

    據發現，curl 在遵循重新導向時，會錯誤地洩漏 OAuth2 持有人 token。這可導致將 token 傳送至錯誤的主機，這與預期行為相反。(CVE-2026-3783)

    Muhamad Arga Reksapati 發現 curl 會不正確地重複使用現有的 HTTP Proxy 連線，即使要求使用不同的憑證亦然。這可導致使用錯誤的憑證，這與預期行為相反。(CVE-2026-3784)

    Daniel Wade 發現，curl 在對相同主機提出第二個 SMB 要求時，未正確處理某些記憶體作業。攻擊者可利用此問題造成 curl 損毀，進而導致拒絕服務或可能執行任意程式碼。此問題只會影響 Ubuntu 25.10。(CVE-2026-3805)

    Yihang Zhou 發現在遵循重新導向時，curl 未正確重複使用 .netrc 檔案憑證。這可導致使用不同主機的憑證，這與預期行為相反。此問題僅影響 Ubuntu 22.04 LTS 和 Ubuntu 24.04 LTS。(CVE-2025-0167)

Tenable 已直接從 Ubuntu 安全公告擷取前置描述區塊。

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

遠端 Ubuntu 18.04 LTS/20.04 LTS 主機上安裝的套件受到 USN-8099-1 公告中所提及的多個弱點影響。

    Zhicheng Chen 發現，curl 可能會針對 Negotiate 驗證的 HTTP 或 HTTPS 要求，不正確地重複使用錯誤的連線。這可導致使用來自不同連線的憑證，這與預期行為相反。這個問題只會影響 Ubuntu 20.04 LTS。(CVE-2026-1965)

    據發現，curl 在遵循重新導向時，會錯誤地洩漏 OAuth2 持有人 token。這可導致將 token 傳送至錯誤的主機，這與預期行為相反。這個問題只會影響 Ubuntu 20.04 LTS。(CVE-2026-3783)

    Muhamad Arga Reksapati 發現 curl 會不正確地重複使用現有的 HTTP Proxy 連線，即使要求使用不同的憑證亦然。這可導致使用錯誤的憑證，這與預期行為相反。(CVE-2026-3784)

Tenable 已直接從 Ubuntu 安全公告擷取前置描述區塊。

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

遠端主機上安裝的 curl 版本為早於 8.19.0 的 7.10.6 版本。因此，它會受到驗證繞過弱點影響：

  - 在某些情況下，當要求執行 Negotiate 驗證的 HTTP 或 HTTPS 要求時，libcurl 可重複使用錯誤的連線。libcurl 具有最近連線集區，因此後續要求可重複使用現有連線以避免造成額外負擔。重複使用連線時，必須先符合一系列準則。由於程式碼中的邏輯錯誤，應用程式發出的要求可能會錯誤地重複使用相同伺服器的現有連線，而該伺服器已使用不同的憑證進行驗證。一個根本原因是，交涉有時會驗證*連線*而不是 
    *要求*，這與 HTTP 的設計運作方式相反。一個應用程式允許使用「user1:password1」透過 Negotiate 驗證連線至某伺服器 (該伺服器回應要求使用 Negotiate)，然後在前一個連線仍然存在的情況下，再次對同一伺服器執行另一個同樣使用 Negotiate、但採用「user2:password2」的操作——第二個要求錯誤地重用了同一條連線，而且由於系統認為 Negotiate 驗證已經完成，便直接透過該連線送出要求，以為使用的是 user2 的憑證，但實際上仍是在使用為 user1 驗證的連線… 使用「CURLOPT_HTTPAUTH」設定要使用的一組驗證方法。應用程式可以停用 libcurl 的連線重複使用功能，藉此減輕此問題的影響，方法是使用下列其中一個 libcurl 選項，變更連線重複使用或不重複使用的方式：「CURLOPT_FRESH_CONNECT」、「CURLOPT_MAXCONNECTS」和「CURLMOPT_MAX_HOST_CONNECTIONS」(若使用 curl_multi API)。(CVE-2026-1965)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
307436	Tenable Identity Exposure < 3.77.17 多個弱點 (TNS-2026-11)	Nessus	Misc.	2026/4/18	2026/4/20	high
301847	Linux Distros 未修補的弱點：CVE-2026-1965	Nessus	Misc.	2026/3/11	2026/3/18	medium
302211	Ubuntu 22.04 LTS / 24.04 LTS / 25.10：curl 弱點 (USN-8084-1)	Nessus	Ubuntu Local Security Checks	2026/3/13	2026/5/8	medium
302762	Ubuntu 18.04 LTS / 20.04 LTS：curl 弱點 (USN-8099-1)	Nessus	Ubuntu Local Security Checks	2026/3/17	2026/5/8	medium
302776	Curl 7.10.6 < 8.19.0 驗證繞過	Nessus	Misc.	2026/3/17	2026/5/8	medium

偵測

搜尋 Plugin

high

medium

medium

medium

medium