如 TuxCare CENTOS8.4：CLSA-2026：1774259220公告所述，CentOS Linux 8.4 主机上安装的程序包受到多个漏洞的影响。

  - 在某些情况下，libcurl 在被要求执行经 Negotiate 验证的 HTTP 或 HTTPS 请求时，会重复使用错误的连接。libcurl 具有一个最近连接池，以便后续请求可以重复使用现有连接，从而避免产生额外开销。重复使用连接时，必须先满足一系列标准。由于代码中存在逻辑错误，应用程序发出的请求可能会错误地重复使用与同一服务器的现有连接，而该连接使用了不同的凭据通过身份验证。一个根本原因是，协商有时会认证 *连接*，而不是 *请求*，这与 HTTP 的工作设计方式相反。允许通过“user1：password1”对服务器进行协商认证（响应要求协商），然后对同样使用协商但使用“user2：password2”（当前一个连接仍处于活动状态时）的相同服务器执行另一操作的应用程序 - 第二个请求错误地重用了相同的连接，因此它随后发现已进行协商协商， 它通过该连接发送请求，认为其使用 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 在某些情况下会将该标记泄漏给第二个主机名。对于将第一个请求重定向到的主机名，如果其所使用的 .netrc 文件中含有 `machine` 或 `default` 关键字中的相关信息，curl 会将第一个主机的持有者标记集也传递给第二个主机。(CVE-2026-3783)

  - 即使新请求对 HTTP 代理使用不同的凭据，curl 也会错误地重复使用现有 HTTP 代理连接以对服务器进行 CONNECT。正确的行为是创建或使用单独的连接。（CVE-2026-3784）

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

检测

CentOS Linux 8.4 [TuxCare] 安全更新：curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal 多个漏洞（CENTOS8.4：CLSA-2026：1774259220）

medium Nessus 插件 ID 352768

未找到变更日志

检测

CentOS Linux 8.4 [TuxCare] 安全更新：curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal 多个漏洞 （CENTOS8.4：CLSA-2026：1774259220）

medium Nessus 插件 ID 352768

未找到变更日志

CentOS Linux 8.4 [TuxCare] 安全更新：curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal 多个漏洞（CENTOS8.4：CLSA-2026：1774259220）