因此，该软件受到 ALAS2023-2026-2132 公告中提及的多个漏洞影响。

    当应用程序通过 CURLOPT_STREAM_DEPENDS 或 CURLOPT_STREAM_DEPENDS_E 配置 HTTP/2 流依赖树，随后调用 curl_easy_reset（），最后通过 curl_easy_cleanup（） 终止句柄时，libcurl 中存在释放后使用漏洞。在此最终清除阶段，libcurl 尝试访问并修改重置操作期间已释放的内部结构。（CVE-2026-10536）

    默认情况下，curl 自动响应 WebSocket PING 帧。由于 curl 缺少用于未确认帧的内存分配上限，恶意服务器可通过向 curl 发送快速、连续的 PING 消息来耗尽所有可用内存。（CVE-2026-11586）

    成功使用 libcurl 通过摘要式认证执行到特定 HTTP 源 （hostA） 的传输，然后将源更改为不同的源 （hostB） 进行第二次传输，重复使用相同的句柄，会使 libcurl 错误地将用于 hostA 的 Authorization： 标头字段传递到 hostB。（CVE-2026-11856）

    当用户使用无方案 URL 结合 --proto-default sftp（或 scp）调用 curl 时，工具层和 libcurl 之间会发生断开连接。工具层错误推断 URL 方案，从而错误地绕过关键 SSH 安全选项（如 CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 和 CURLOPT_SSH_KNOWNHOSTS）的初始化。相反，libcurl 运行时会成功遵从CURLOPT_DEFAULT_PROTOCOL，并按照指定方式通过 SFTP/SCP 建立连接。
    由于工具层跳过了安全配置，这些 SSH 主机验证选项将静默忽略，从而造成 curl 连接到未经验证的 SSH 远程主机而不抛出错误。
    (CVE-2026-12064)

    存在一个漏洞，表现为使用 STARTTLS 升级连接的新传输可能会重复使用现有的实时连接，即使 TLS 配置不匹配，因此不应如此。CVE-2026-8286

    在某些情况下，当要求进行经过协商认证的操作时，libcurl 可能会重用错误的连接，即使它们设置为使用不同的服务时亦是如此。

    libcurl 具有最近连接池，因此后续请求可以重复使用现有连接以避免开销。

    重复使用连接时，必须满足一系列条件。由于代码中的逻辑错误，应用程序发出的请求可能错误地重新使用与使用不同服务通过认证的相同服务器的现有连接。（CVE-2026-8458）

    curl 的 cookie 解析逻辑中的一个缺陷允许恶意 HTTP 服务器设置超级 cookie，以绕过公共后缀列表检查。这使得攻击者控制的源能够注入 Cookie，这些 Cookie 随后会卷起范围并传输到不相关的第三方域。（CVE-2026-8924）

    与 SASL 认证配合使用的 curl 逻辑最终可能会在不清除中间指针的情况下清理 GSASL 上下文两次，从而使其两次 free（） 相同的指针。（CVE-2026-8925）

    如果要求 curl 使用 .netrc 文件来查找凭据，同时指定含用户名（无密码 https://user@example.com/）的 URL（如 ，），如果存在特定用户的 .netrc 文件中设置的密码，则 curl 可能会错误地获取和使用在该主机的 .netrc 文件中设置的密码。（CVE-2026-8926）

    将 libcurl 句柄重复用于由环境变量代理配置驱动的顺序传输时，libcurl 无法清除请求之间的代理认证状态。具体而言，如果初始传输使用摘要认证针对 proxyA 进行身份验证，则通过 proxyB 路由的后续传输会错误泄露专门用于 proxyA 的 Proxy-Authorization： 标头。（CVE-2026-8927）

    libcurl 将重复使用之前创建的连接，即使已更改某些应禁止重复使用的 mTLS 配置相关选项。

    libcurl 将之前用过的连接保留在连接池中，以便在其中一个连接与设置匹配时进行后续传输以供重复使用。但是，配置匹配检查中遗漏了某些与客户端证书相关的 TLS 设置，因此它们太容易匹配。特别是与私钥相关的选项。（CVE-2026-8932）

    libcurl 有一个缺陷，当被指示清除代理认证凭据时，会使其无法执行此操作，从而留下旧凭据，用于不应知道也不应使用它们的后续传输。
    (CVE-2026-9079)

    在基于事件的 CURLMOPT_SOCKETFUNCTION 回调中调用 curl_easy_pause（） 会触发释放后使用漏洞，其中，libcurl 在指针的内存释放后立即尝试使用悬摆结构指针来存储标记。（CVE-2026-9080）

    在这种情况下，libcurl 首先将正确的 HTTP/3 服务器用于初始传输，当它向同一站点进行第二次传输时，它已经被攻击者的冒名顶替计算机替换 - 没有有效证书。

    libcurl 在缓存的 SSL 会话（未禁用 CURLOPT_SSL_SESSIONID_CACHE）和启用早期数据（CURLOPT_SSL_OPTIONS 中设置 CURLSSLOPT_EARLYDATA 位）第二次返回主机名时，libcurl 可能会在强制证书验证失败之前发送该新连接上的第二个请求的字节。可能泄露敏感信息。（CVE-2026-9545）

    基于 libcurl 的应用程序通过 SCP:// 或 SFTP:// 执行传输并利用 CURLOPT_SSH_KEYFUNCTION 回调时，可能会静默接受不受信任的服务器。当服务器提供的主机密钥类型与 known_hosts 文件中已针对该主机记录的特定密钥类型不匹配时，即会出现此漏洞。回调机制非但没有拒绝不匹配，反而无法正确执行限制，这使得连接能够在没有警告的情况下成功完成，并面临潜在的中间人攻击的风险。（CVE-2026-9547）

Tenable 已直接从测试产品的安全公告中提取上述描述块。

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

检测

Amazon Linux 2023: curl、curl-minimal、libcurl (ALAS2023-2026-2132)

critical Nessus 插件 ID 345801

版本 1.1