CentOS Linux 8.4 主機已安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2026：1774259220 公告中提及的多個弱點影響。

  - 在某些情況下，當要求執行 Negotiate 驗證的 HTTP 或 HTTPS 要求時，libcurl 可重複使用錯誤的連線。libcurl 具有最近連線集區，因此後續要求可重複使用現有連線以避免造成額外負擔。重複使用連線時，必須先符合一系列準則。由於程式碼中的邏輯錯誤，應用程式發出的要求可能會錯誤地重複使用相同伺服器的現有連線，而該伺服器已使用不同的憑證進行驗證。一個根本原因是 Negotiate 有時會驗證 *connections* 而不是 *requests*，這與 HTTP 的設計工作方式相反。允許使用「user1：password1」對伺服器進行協商驗證 （回應想要協商） 的應用程式，然後對同樣使用 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)

  - 當 OAuth2 持有人權杖用於 HTTP(S) 傳輸，且該傳輸執行重新導向至第二個 URL，curl 在某些情況下可將該 token 洩漏給第二個主機名稱。如果將第一個要求重新導向至的主機名稱在所用的 .netrc 檔案中有「machine」或「default」關鍵字資訊，curl 會將第一個主機的持有人權杖集也傳遞給第二個主機。(CVE-2026-3783)

  - curl 會錯誤地重複使用現有的 HTTP Proxy 連線來執行 CONNECT 至伺服器，即使新要求針對 HTTP Proxy 使用不同的認證也一樣。正確的行為是建立或使用單獨的連線。（CVE-2026-3784）

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

偵測

CentOS Linux 8.4 [TuxCare] 安全性更新：curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal 多個弱點（CENTOS8.4：CLSA-2026：1774259220）

medium Nessus Plugin ID 352768

找不到變更記錄

偵測

CentOS Linux 8.4 [TuxCare] 安全性更新：curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal 多個弱點 （CENTOS8.4：CLSA-2026：1774259220）

medium Nessus Plugin ID 352768

找不到變更記錄

CentOS Linux 8.4 [TuxCare] 安全性更新：curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal 多個弱點（CENTOS8.4：CLSA-2026：1774259220）