根据其自我报告的版本，远程主机上运行的 Nessus Network Monitor 版本低于 6.2.2 版。因此，它受到 TNS-2023-23 公告中提及的多个漏洞影响。已发现多个第三方组件包含漏洞，供应商已提供更新版本。出于谨慎考虑且符合最佳实践，Tenable 选择升级这些组件，以解决这些问题的潜在影响。Nessus Network Monitor 6.2.2 更新了以下组件：

  - 将 c-ares 版本从 1.10.0 更新到 1.19.1。
  - 将 curl 版本从 7.79.1 更新到 8.1.2。
  - 将 libbzip2 版本从 1.0.6 更新到 1.0.8。
  - 将 libpcre 版本从 8.42 更新到 8.44。
  - 将 libxml2 版本从 2.7.7 更新到 2.11.1。
  - 将 libxslt 版本从 1.1.26 更新到 1.1.37。
  - 将 libxmlsec 版本从 1.2.18 更新到 1.2.37。
  - 将 sqlite 版本从 3.27.2 更新到 3.40.1。
  - 将 jQuery Cookie 版本从 1.3.1 更新到 1.4.1。
  - 将 jQuery UI 版本从 1.13.0 更新到 1.13.2。
  - 将 OpenSSL 版本从 3.0.8 更新到 3.0.9。

远程主机上安装的 curl 版本低于 7.61.1-12.101。因此，如公告 ALAS-2022-1646 所述，该主机受到多个漏洞的影响。

  - curl 7.33.0 至 7.82.0（含）版本中存在一个不当认证漏洞，从而可能允许在未正确确保已使用为传输设置的相同凭据来认证连接的情况下，重复使用经 OAUTH2 认证的连接。此漏洞会影响启用了 SASL 的协议：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S)（仅限 openldap）。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版（含）存在凭据保护不充分漏洞，允许攻击者在遵循身份验证中结合使用的 HTTP(S) 重定向时提取凭据，将凭据泄露给不同协议或端口号上的其他服务。
    (CVE-2022-27774)

  - curl 7.83.0 版中修复的凭据保护不充分漏洞可能会在 HTTP 重定向到相同主机不同端口号时泄漏身份验证或 Cookie 标头数据。(CVE-2022-27776)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

  - 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得过于容易。(CVE-2022-27782)

  - curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)

  - 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
    攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

  - 当 curl 用于检索和解析来自 HTTP(S) 服务器的 cookie 时，它使用控制代码接受 cookie，这些代码稍后被发送回 HTTP 服务器时可能会使服务器返回 400 响应。
    有效地令辅助站点拒绝向所有同级站点提供服务。(CVE-2022-35252)

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

远程 Debian 10 主机上安装的多个程序包受到 dla-3085 公告中提及的多个漏洞影响。

  - 当“-t”命令行选项（在 libcurl 中称为“CURLOPT_TELNETOPTIONS”）用于将 variable=content 对发送到 TELNET 服务器时，curl 7.7 直到 7.76.1 的版本受到信息泄露漏洞的影响。用于发送 NEW_ENV 变量的选项解析器中存在一个缺陷，因此 libcurl 可能会被用于将未初始化的数据从基于堆栈的缓冲区传递到服务器，从而可能导致使用明文网络协议将敏感的内部信息泄露给服务器。(CVE-2021-22898)

  - LibCurl 将先前使用的连接保留在连接池中，以供后续传输重新使用（如果其中一个连接与设置匹配）。由于逻辑错误，配置匹配函数没有考虑“发行者证书”，且比较了涉及路径中的*不区分大小写*，这可导致 LibCurl 重新使用错误的连接。文件路径在许多系统中会（或可能）区分大小写，但不是全部，并且甚至会因使用的文件系统而不同。比较中未包括“发行者证书”，传输可对其进行设置，以限制验证服务器的方式。 (CVE-2021-22924)

  - 用户可以在与 IMAP、POP3 或 FTP 服务器通信时，告知 7.20.0、7.78.0 及其之间的 curl 版本需要成功升级至 TLS（命令行的 `--ssl-reqd` 或`CURLOPT_USE_SSL` 设置为带有 libcurl 的 `CURLUSESSL_CONTROL` 或 `CURLUSESSL_ALL`）。如果服务器返回构建正确且完全合法的响应，则可绕过此要求。此缺陷将使 curl 默默地继续其操作
    **无 TLS** 违反说明和预期，可通过网络以明文形式暴露可能的敏感数据。(CVE-2021-22946)

  - 当 7.20.0、7.78.0 及其之间的 curl 版本连接到 IMAP 或 POP3 服务器以使用 STARTTLS 检索数据进而升级到 TLS 安全时，服务器可以响应并立即发回 curl 缓存的多个响应。
    然后，curl 会升级至 TLS，但不会刷新缓存响应的队列，而是继续使用和信任其在 TLS 握手*之前*获得的响应，就好像这些响应已经过身份验证一样。中间人攻击者可使用此缺陷，首先注入虚假响应，然后传递来自合法服务器的 TLS 流量，并诱使 curl 认为攻击者注入的数据来自受 TLS 保护的服务器，从而向用户发回数据。(CVE-2021-22947)

  - curl 7.33.0 至 7.82.0（含）版本中存在一个不当认证漏洞，从而可能允许在未正确确保已使用为传输设置的相同凭据来认证连接的情况下，重复使用经 OAUTH2 认证的连接。此漏洞会影响启用了 SASL 的协议：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S)（仅限 openldap）。(CVE-2022-22576)

  - curl 7.83.0 版中修复的凭据保护不充分漏洞可能会在 HTTP 重定向到相同主机不同端口号时泄漏身份验证或 Cookie 标头数据。(CVE-2022-27776)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

  - 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得过于容易。(CVE-2022-27782)

  - curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)

  - 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
    攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

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

远程 Ubuntu 18.04 LTS/20.04 LTS/21.10/22.04 LTS 主机上安装的多个程序包受到 USN-5412-1 公告中提及的多个漏洞影响。

  - 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得非常容易。(CVE-2022-27782)

  - 解码 URL 的主机名部分时，curl URL 解析器会错误接受诸如“/”的以百分号编码的 URL 分隔符，从而使其在以后检索时成为使用错误主机名的*不同* URL。例如，解析器会允许诸如“http://example.com%2F127.0.0.1/`”的 URL 并将其转置为 `http://example.com/127.0.0.1/`。攻击者可利用此缺陷避开筛选和检查等。
    (CVE-2022-27780)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

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

因此，它受到 ALAS2-2023-1924 公告中提及的多个漏洞影响。

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

  - curl <7.87.0 HSTS 检查中存在漏洞，攻击者可绕过检查以诱骗程序继续使用 HTTP。
    如使用 HSTS 支持，即使在 URL 中提供了 HTTP，仍可指示 curl 使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。但是，如果给定 URL 中的主机名首先使用在 IDN 转换过程中被替换为 ASCII 对应项的 IDN 字符，则可以绕过 HSTS 机制。就像使用 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 字符，而不是通用的 ASCII 句号 (U+002E)“.”。然后在后续请求中，程序不会检测 HSTS 状态并进行明文传输。这是因为它会存储经 IDN 编码的信息，但查找经 IDN 解码的信息。(CVE-2022-43551)

  - 在 curl 中发现一个漏洞。发生此问题是由于错误的函数所导致的。尝试检索该信息时，恶意服务器可使网络安全服务 (NSS) 内的 curl 陷入永无止境的忙碌循环。此缺陷会导致无限循环，从而影响系统可用性。
    (CVE-2022-27781) (CVE-2022-43552)

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

远程 Redhat Enterprise Linux 7/8 主机上安装的多个程序包受到 RHSA-2022: 8840 公告中提及的多个漏洞的影响。

  - c_rehash 脚本未正确审查 shell 元字符以防止命令注入。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。
    已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。已在 OpenSSL 1.1.1o 中修复（影响 1.1.1-1.1.1n）。
    已在 OpenSSL 1.0.2ze 中修复（影响 1.0.2-1.0.2zd）。(CVE-2022-1292)

  - 除了 CVE-2022-1292 中发现的 c_rehash shell 命令注入之外，代码审查还发现了 c_rehash 脚本未正确审查 shell 元字符以防止命令注入的其他情况。修复 CVE-2022-1292 后，未发现脚本中的其他位置可能会将被哈希的证书文件名传递给通过 shell 执行的命令。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。已在 OpenSSL 3.0.4 中修复（影响 3.0.0、3.0.1、3.0.2、3.0.3）。已在 OpenSSL 1.1.1p 中修复（影响 1.1.1-1.1.1o）。已在 OpenSSL 1.0.2zf 中修复（影响 1.0.2-1.0.2ze）。(CVE-2022-2068)

  - 如果在 32 位系统上将 LimitXMLRequestBody 设置为允许处理大于 350MB（默认为 1M）的请求正文，则将导致发生整数溢出，随后导致越界写入问题。此问题影响 Apache HTTP Server 2.4.52 及更早版本。(CVE-2022-22721)

  - Apache HTTP Server 的 mod_sed 中的越界写入漏洞允许攻击者使用可能由攻击者提供的数据覆盖堆内存。此问题影响 Apache HTTP Server 2.4 2.4.52 及之前版本。(CVE-2022-23943)

  - Apache HTTP Server 的 mod_proxy_ajp 中存在对 HTTP 请求解释不一致（“HTTP 请求走私”）漏洞，攻击者可借此将请求走私到其转发请求的 AJP 服务器。此问题影响 Apache HTTP Server 2.4、2.4.53 及之前版本。
    (CVE-2022-26377)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

  - 如果攻击者能够使用 ap_rwrite() 或 ap_rputs()（例如使用 mod_luas r:puts() 函数）让服务器反映超大型输入，则 Apache HTTP Server 2.4.53 及更早版本中的 ap_rwrite() 函数可能会读取非预期内存。对于使用“ap_rputs”函数并可能向其传递非常大（INT_MAX 或更大）字符串的从 Apache HTTP Server 单独编译和分发的模块，必须针对当前标头进行编译以解决该问题。 (CVE-2022-28614)

  - 在 Apache HTTP Server 2.4.53 及更早版本中，当应用程序处理超大型输入缓冲时，ap_strcmp_match() 中的越界读取漏洞可能会造成程序崩溃或信息泄露。虽然无法将随服务器分发的代码强制转换为此类调用，但使用 ap_strcmp_match() 的第三方模块或 lua 脚本可能会受到影响。(CVE-2022-28615)

  - 如果将 Apache HTTP Server 2.4.53 配置为在 mod_sed 的输入可能非常大的上下文中使用 mod_sed 执行转换，则 mod_sed 可能会进行超大内存分配并触发中止。
    (CVE-2022-30522)

  - Apache HTTP Server 2.4.53 及更早版本可能不会根据客户端的 Connection 标头逐跳机制将 X-Forwarded-* 标头发送到源服务器。攻击者可利用此问题绕过源服务器/应用程序上基于 IP 的认证。(CVE-2022-31813)

  - curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)

  - 低于 7.84.0 版的 curl 将 cookie、alt-svc 和 hsts 数据保存到本地文件时，会通过将临时名称重命名为最终目标文件名称来完成操作，从而使该操作成为原子型操作。在该重命名操作中，它可能会意外*放宽*对目标文件的权限，使更多用户可访问更新后的文件。(CVE-2022-32207)

  - 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
    攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

  - 在进行 HTTP(S) 传输时，如果之前使用相同的句柄发出 `PUT` 请求（使用读取回调 (`CURLOPT_READFUNCTION`)），即使设置了 `CURLOPT_POSTFIELDS` 选项，libcurl 可能会错误地使用该回调来请求发送数据。此缺陷可能会使应用程序发生意外并导致其行为不当，并在后续的 `POST` 请求中发送错误的数据或使用释放后的内存或类似内容。从 PUT 更改为 POST 时，重用句柄的逻辑中存在此问题。(CVE-2022-32221)

  - 当 curl 用于检索和解析来自 HTTP(S) 服务器的 cookie 时，它使用控制代码接受 cookie，这些代码稍后被发送回 HTTP 服务器时可能会使服务器返回 400 响应。
    有效地令辅助站点拒绝向所有同级站点提供服务。(CVE-2022-35252)

  - 在 7.86.0 版之前的 curl 中存在双重释放。如果指示 curl 使用 HTTP 代理进行具有非 HTTP URL 的传输，它会通过向代理发出 CONNECT 请求来与远程服务器建立连接，然后使协议的其余部分通过隧道。HTTP 代理可能拒绝此请求（HTTP 代理通常只允许传出连接至特定端口号，例如 HTTPS 的 443），而向客户端返回非 200 状态代码。由于错误/清理处理中的缺陷，如果在 URL 中使用以下方案之一进行传输，则这可能在 curl 中触发双重释放：dict、gopher、gophers、ldap、ldaps、rtmp、rtmps 或 telnet。低于 7.77.0 的版本均受影响。(CVE-2022-42915)

  - 在 7.86.0 版之前的 curl 中，可绕过 HSTS 检查以诱骗其继续使用 HTTP。使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用在 IDN 转换过程中被 ASCII 对应项替换的 IDN 字符，则可绕过此机制。例如使用字符 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 而不是通用 ASCII 句号 U+002E (.)。
    低于 7.77.0 2021-05-26 的版本均受影响。(CVE-2022-42916)

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

远程 Debian 11 主机上安装的多个程序包受到 dsa-5197 公告中提及的多个漏洞影响。

  - 当“-t”命令行选项（在 libcurl 中称为“CURLOPT_TELNETOPTIONS”）用于将 variable=content 对发送到 TELNET 服务器时，curl 7.7 到 7.76.1 受到信息泄露漏洞的影响。用于发送 NEW_ENV 变量的选项解析器中存在一个缺陷，因此 libcurl 可能会被用于将未初始化的数据从基于堆栈的缓冲区传递到服务器，从而可能导致使用明文网络协议将敏感的内部信息泄露给服务器。(CVE-2021-22898)

  - LibCurl 将先前使用的连接保留在连接池中，以供后续传输重新使用（如果其中一个连接与设置匹配）。由于逻辑错误，配置匹配函数没有考虑“发行者证书”，且比较了涉及路径中的*不区分大小写*，这可导致 LibCurl 重新使用错误的连接。文件路径在许多系统中会（或可能）区分大小写，但不是全部，并且甚至会因使用的文件系统而不同。比较中未包括“发行者证书”，传输可对其进行设置，以限制验证服务器的方式。 (CVE-2021-22924)

  - 向 MQTT 服务器发送数据时，libcurl <= 7.73.0 和 7.78.0 版在某些情况下可能会错误地保留指向已释放内存区域的指针，并在后续调用中再次使用该指针来发送数据，并*再次* 释放。(CVE-2021-22945)

  - 用户可以在与 IMAP、POP3 或 FTP 服务器通信时，告知 7.20.0、7.78.0 及其之间的 curl 版本需要成功升级至 TLS（命令行的 `--ssl-reqd` 或`CURLOPT_USE_SSL` 设置为带有 libcurl 的 `CURLUSESSL_CONTROL` 或 `CURLUSESSL_ALL`）。如果服务器返回构建正确且完全合法的响应，则可绕过此要求。此缺陷将使 curl 默默地继续其操作
    **无 TLS** 违反说明和预期，可通过网络以明文形式暴露可能的敏感数据。(CVE-2021-22946)

  - 当 7.20.0、7.78.0 及其之间的 curl 版本连接到 IMAP 或 POP3 服务器以使用 STARTTLS 检索数据进而升级到 TLS 安全时，服务器可以响应并立即发回 curl 缓存的多个响应。
    然后，curl 会升级至 TLS，但不会刷新缓存响应的队列，而是继续使用和信任其在 TLS 握手*之前*获得的响应，就好像这些响应已经过身份验证一样。中间人攻击者可使用此缺陷，首先注入虚假响应，然后传递来自合法服务器的 TLS 流量，并诱使 curl 认为攻击者注入的数据来自受 TLS 保护的服务器，从而向用户发回数据。(CVE-2021-22947)

  - curl 7.33.0 至 7.82.0（含）版本中存在一个不当认证漏洞，从而可能允许在未正确确保已使用为传输设置的相同凭据来认证连接的情况下，重复使用经 OAUTH2 认证的连接。此漏洞会影响启用了 SASL 的协议：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S)（仅限 openldap）。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版（含）存在凭据保护不充分漏洞，允许攻击者在遵循身份验证中结合使用的 HTTP(S) 重定向时提取凭据，将凭据泄露给不同协议或端口号上的其他服务。
    (CVE-2022-27774)

  - curl 7.65.0 至 7.82.0 中存在信息泄露漏洞，在使用连接池中具有不同区域 ID 的 IPv6 地址时，它可能会重复使用连接。(CVE-2022-27775)

  - curl 7.83.0 版中修复的凭据保护不充分漏洞可能会在 HTTP 重定向到相同主机不同端口号时泄漏身份认证或 Cookie 标头数据。(CVE-2022-27776)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

  - 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得非常容易。(CVE-2022-27782)

  - 恶意服务器可在 HTTP 响应中提供过量的 `Set-Cookie:`  标头，而低于 7.84.0 版的 curl 会存储所有这些标头。数量够多（大）的 cookie 会向此服务器或这些 cookie 相匹配的其他服务器发出后续 HTTP 请求，从而使创建的请求超过 curl 为避免发送过大请求（1048576 字节）而在内部使用的阈值，而没有返回错误。只要保留和匹配这些 cookie 并且它们未过期，此拒绝状态就可能持续存在。由于 cookie 匹配规则，“foo.example.com”上的服务器可以设置匹配“bar.example.com”的 cookie，从而使同级服务器可以有效造成相同二级域上使用此方法的同级网站拒绝服务。(CVE-2022-32205)

  - curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)

  - 低于 7.84.0 版的 curl 将 cookie、alt-svc 和 hsts 数据保存到本地文件时，会通过将临时名称重命名为最终目标文件名称来完成操作，从而使该操作成为原子型操作。在该重命名操作中，它可能会意外*放宽*对目标文件的权限，使更多用户可访问更新后的文件。(CVE-2022-32207)

  - 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
    攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

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

因此，它受到公告 ALAS2023-2023-083 中提及的多个漏洞影响。

  - curl 7.33.0 至 7.82.0（含）版本中存在一个不当认证漏洞，从而可能允许在未正确确保已使用为传输设置的相同凭据来认证连接的情况下，重复使用经 OAUTH2 认证的连接。此漏洞会影响启用了 SASL 的协议：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S)（仅限 openldap）。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版（含）存在凭据保护不充分漏洞，允许攻击者在遵循身份验证中结合使用的 HTTP(S) 重定向时提取凭据，将凭据泄露给不同协议或端口号上的其他服务。
    (CVE-2022-27774)

  - curl 7.65.0 至 7.82.0 中存在信息泄露漏洞，在使用连接池中具有不同区域 ID 的 IPv6 地址时，它可能会重复使用连接。(CVE-2022-27775)

  - curl 7.83.0 版中修复的凭据保护不充分漏洞可能会在 HTTP 重定向到相同主机不同端口号时泄漏身份验证或 Cookie 标头数据。(CVE-2022-27776)

  - 如果主机名以一个点结尾，libcurl 会错误允许为顶级域 (TLD) 设置 cookie。可指示 curl 接收和发送 cookie。在构建 curl 的 cookie 引擎时，可以使用 [公共后缀列表]，也可以不使用 (https://publicsuffix.org/)awareness。如果不提供 PSL 支持，则需要初步检查，以至少防止在 TLD 上设置 cookie。如果 URL 中的主机名以一个点结尾，此检查会被中断。这可允许任意站点设置 cookie，然后将其发送至不同且不相关的站点或域。(CVE-2022-27779)

  - 解码 URL 的主机名部分时，curl URL 解析器会错误接受诸如“/”的以百分号编码的 URL 分隔符，从而使其在以后检索时成为使用错误主机名的*不同* URL。例如，解析器会允许诸如 `http://example.com%2F127.0.0.1/` 的 URL 并将其转置为 `http://example.com/127.0.0.1/`。攻击者可利用此缺陷避开筛选和检查等。
    (CVE-2022-27780)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

  - 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得过于容易。(CVE-2022-27782)

  - 使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用了结尾点而未使用构建 HSTS 缓存时的结尾点，则可绕过此机制。或者反过来
    - 在 HSTS 缓存中使用结尾点，而*不在* URL 中使用结尾点。
    (CVE-2022-30115)

  - 恶意服务器可在 HTTP 响应中提供过量的 `Set-Cookie:`  ` 标头，导致 curl 和 curl < 7.84.0 存储所有这些标头。数量够多（大）的 cookie 会向此服务器或这些 cookie 相匹配的其他服务器发出后续 HTTP 请求，从而使创建的请求超过 curl 为避免发送过大请求（1048576 字节）而在内部使用的阈值，而没有返回错误。只要保留和匹配这些 cookie 并且它们未过期，此拒绝状态就可能持续存在。由于 cookie 匹配规则，“foo.example.com”上的服务器可以设置匹配“bar.example.com”的 cookie，从而使同级服务器可以有效造成相同二级域上使用此方法的同级网站拒绝服务。(CVE-2022-32205)

  - curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)

  - 低于 7.84.0 版的 curl 将 cookie、alt-svc 和 hsts 数据保存到本地文件时，会通过将临时名称重命名为最终目标文件名称来完成操作，从而使该操作成为原子型操作。在该重命名操作中，它可能会意外*放宽*对目标文件的权限，使更多用户可访问更新后的文件。(CVE-2022-32207)

  - 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
    攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

  - 在进行 HTTP(S) 传输时，如果之前使用相同的句柄发出 `PUT` 请求（使用读取回调 (`CURLOPT_READFUNCTION`)），即使设置了 `CURLOPT_POSTFIELDS` 选项，libcurl 可能会错误地使用该回调来请求发送数据。此缺陷可能会使应用程序发生意外并导致其行为不当，并在后续的 `POST` 请求中发送错误的数据或使用释放后的内存或类似内容。从 PUT 更改为 POST 时，重用句柄的逻辑中存在此问题。(CVE-2022-32221)

  - 当 curl 用于检索和解析来自 HTTP(S) 服务器的 cookie 时，它使用控制代码接受 cookie，这些代码稍后被发送回 HTTP 服务器时可能会使服务器返回 400 响应。
    有效地令辅助站点拒绝向所有同级站点提供服务。(CVE-2022-35252)

  - 可指示 curl 解析 `.netrc` 文件以获取凭据。如果该文件以具有 4095 个连续非空白字符且无换行符的行结尾，则 curl 将首先读取超过基于堆栈的缓冲区的末尾，如果是 readworks，则写入一个超出其边界的零字节。在大多数情况下此问题会造成段错误或类似问题，但不同的环境也可能造成不同的结果。如果恶意用户可以向应用程序提供自定义 netrc 文件，或以其他方式影响其内容，则此缺陷可被用作拒绝服务。(CVE-2022-35260)

  - 在 7.86.0 版之前的 curl 中存在双重释放。如果指示 curl 使用 HTTP 代理进行具有非 HTTP URL 的传输，它会通过向代理发出 CONNECT 请求来与远程服务器建立连接，然后使协议的其余部分通过隧道。HTTP 代理可能拒绝此请求（HTTP 代理通常只允许传出连接至特定端口号，例如 HTTPS 的 443），而向客户端返回非 200 状态代码。由于错误/清理处理中的缺陷，如果在 URL 中使用以下方案之一进行传输，则这可能在 curl 中触发双重释放：dict、gopher、gophers、ldap、ldaps、rtmp、rtmps 或 telnet。低于 7.77.0 的版本均受影响。(CVE-2022-42915)

  - 在 7.86.0 版之前的 curl 中，可绕过 HSTS 检查以诱骗其继续使用 HTTP。使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用在 IDN 转换过程中被 ASCII 对应项替换的 IDN 字符，则可绕过此机制。例如使用字符 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 而不是通用 ASCII 句号 U+002E (.)。
    低于 7.77.0 2021-05-26 的版本均受影响。(CVE-2022-42916)

  - curl <7.87.0 HSTS 检查中存在漏洞，攻击者可绕过检查以诱骗程序继续使用 HTTP。
    如使用 HSTS 支持，即使在 URL 中提供了 HTTP，仍可指示 curl 使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。但是，如果给定 URL 中的主机名首先使用在 IDN 转换过程中被替换为 ASCII 对应项的 IDN 字符，则可以绕过 HSTS 机制。就像使用 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 字符，而不是通用的 ASCII 句号 (U+002E)“.”。然后在后续请求中，程序不会检测 HSTS 状态并进行明文传输。这是因为它会存储经 IDN 编码的信息，但查找经 IDN 解码的信息。(CVE-2022-43551)

  - curl <7.87.0 中存在释放后使用漏洞。可要求 Curl 通过 HTTP 代理*传输*其支持的几乎所有协议。HTTP 代理可以（而且经常会）拒绝此类传输操作。
     如果传输特定协议 SMB 或 TELNET 被拒，Curl 会在其传输关闭代码路径中使用已释放的堆分配结构。(CVE-2022-43552)

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

远程 Ubuntu 16.04 ESM 主机上安装的多个程序包受到 USN-5499-1 公告中提及的多个漏洞影响。

  - 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
    攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

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

远程主机上安装的 curl 版本低于 7.83.1。因此，该应用程序受到 SSA:2022-131-01 公告中提及的多个漏洞的影响。

  - 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得非常容易。(CVE-2022-27782)

  - 当“--no-clobber”与“--remove-on-error”一起使用时，7.83.1 版中已修复的使用错误解析的名称漏洞可能会删除错误的文件。(CVE-2022-27778)

  - 如果主机名以一个点结尾，libcurl 会错误允许为顶级域 (TLD) 设置 cookie。可指示 curl 接收和发送 cookie。在构建 curl 的 cookie 引擎时，可以使用 [公共后缀列表]，也可以不使用 (https://publicsuffix.org/)awareness。如果不提供 PSL 支持，则需要初步检查，以至少防止在 TLD 上设置 cookie。如果 URL 中的主机名以一个点结尾，此检查会被中断。这可允许任意站点设置 cookie，然后将其发送至不同且不相关的站点或域。(CVE-2022-27779)

  - 解码 URL 的主机名部分时，curl URL 解析器会错误接受诸如“/”的以百分号编码的 URL 分隔符，从而使其在以后检索时成为使用错误主机名的*不同* URL。例如，解析器会允许诸如 `http://example.com%2F127.0.0.1/` 的 URL 并将其转置为 `http://example.com/127.0.0.1/`。攻击者可利用此缺陷避开筛选和检查等。
    (CVE-2022-27780)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时陷入忙碌等待的死循环中。
    (CVE-2022-27781)

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

远程主机受到 GLSA-202212-01 中所述漏洞的影响（curl：多个漏洞）

  - 当 curl 收到使用 metalink 功能下载内容的指示时，将根据 metalink XML 文件中提供的哈希验证内容。metalink XML 文件向客户端指出如何从一组不同的 URL 获取相同的内容（可能由不同的服务器托管），随后客户端便可从一个或多个 URL 下载该文件。以串行或并行方式。如果托管内容的某个服务器遭到破坏，且该服务器上特定文件的内容被修改后的负载替换，则在下载完成后，curl 会在文件的哈希值不匹配时检测到这一点。
    客户端应该删除这些内容，并尝试从另一个 URL 获取内容。此操作未完成，而是仅在文本中提及此类哈希不匹配，并且可能的恶意内容将被保留在磁盘上的文件中。(CVE-2021-22922)

  - 当 curl 收到使用 metalink 功能获取内容的指示时，并使用用户名和密码下载 metalink XML 文件时，这些相同凭据随后会被传递到 curl 将从其下载或尝试下载内容的每个服务器。通常违背用户的预期和意图，并且未将发生的情况告知用户。(CVE-2021-22923)

  - curl 支持“-t”命令行选项，在 libcurl 中称为“CURLOPT_TELNETOPTIONS”。这个极少使用的选项用于将 variable=content 对发送到 TELNET 服务器。由于用于发送“NEW_ENV”变量的选项解析器中存在一个缺陷，可以让 libcurl 将未初始化的数据从基于堆栈的缓冲区传递到服务器。因此，可能会使用明文网络协议向服务器显示敏感的内部信息。发生这种情况的原因是 curl 在解析应用程序提供的字符串时未正确调用和使用 sscanf()。(CVE-2021-22925)

  - libcurl-using 应用程序可要求在传输中使用特定的客户端证书。这一要求可通过 `CURLOPT_SSLCERT` 选项（命令行工具的 `--cert`）完成。当 libcurl 被构建为使用 macOS 本机 TLS 库安全传输时，应用程序可通过相同的选项，按名称或文件名请求客户端证书。如果名称以文件形式存在，则将使用文件而非名称。如果应用程序在可由其他用户写入的当前工作目录（如“/tmp”）下运行，恶意用户可使用与应用程序要使用的名称相同的名称，从而诱骗应用程序使用基于文件的证书，而不是名称引用的证书，从而使 libcurl 在 TLS 连接握手中发送错误的客户端证书。(CVE-2021-22926)

  - 向 MQTT 服务器发送数据时，libcurl <= 7.73.0 和 7.78.0 版在某些情况下可能会错误地保留指向已释放内存区域的指针，并在后续调用中再次使用该指针来发送数据，并*再次* 释放。(CVE-2021-22945)

  - 用户可以在与 IMAP、POP3 或 FTP 服务器通信时，告知 7.20.0、7.78.0 及其之间的 curl 版本需要成功升级至 TLS（命令行的 `--ssl-reqd` 或`CURLOPT_USE_SSL` 设置为带有 libcurl 的 `CURLUSESSL_CONTROL` 或 `CURLUSESSL_ALL`）。如果服务器返回构建正确且完全合法的响应，则可绕过此要求。此缺陷将使 curl 默默地继续其操作
    **无 TLS** 违反说明和预期，可通过网络以明文形式暴露可能的敏感数据。(CVE-2021-22946)

  - 当 7.20.0、7.78.0 及其之间的 curl 版本连接到 IMAP 或 POP3 服务器以使用 STARTTLS 检索数据进而升级到 TLS 安全时，服务器可以响应并立即发回 curl 缓存的多个响应。
    然后，curl 会升级至 TLS，但不会刷新缓存响应的队列，而是继续使用和信任其在 TLS 握手*之前*获得的响应，就好像这些响应已经过身份验证一样。中间人攻击者可使用此缺陷，首先注入虚假响应，然后传递来自合法服务器的 TLS 流量，并诱使 curl 认为攻击者注入的数据来自受 TLS 保护的服务器，从而向用户发回数据。(CVE-2021-22947)

  - curl 7.33.0 至 7.82.0（含）版本中存在一个不当认证漏洞，从而可能允许在未正确确保已使用为传输设置的相同凭据来认证连接的情况下，重复使用经 OAUTH2 认证的连接。此漏洞会影响启用了 SASL 的协议：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S)（仅限 openldap）。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版（含）存在凭据保护不充分漏洞，允许攻击者在遵循身份验证中结合使用的 HTTP(S) 重定向时提取凭据，将凭据泄露给不同协议或端口号上的其他服务。
    (CVE-2022-27774)

  - curl 7.65.0 至 7.82.0 中存在信息泄露漏洞，在使用连接池中具有不同区域 ID 的 IPv6 地址时，它可能会重复使用连接。(CVE-2022-27775)

  - curl 7.83.0 版中修复的凭据保护不充分漏洞可能会在 HTTP 重定向到相同主机不同端口号时泄漏身份验证或 Cookie 标头数据。(CVE-2022-27776)

  - 如果主机名以一个点结尾，libcurl 会错误允许为顶级域 (TLD) 设置 cookie。可指示 curl 接收和发送 cookie。在构建 curl 的 cookie 引擎时，可以使用 [公共后缀列表]，也可以不使用 (https://publicsuffix.org/)awareness。如果不提供 PSL 支持，则需要初步检查，以至少防止在 TLD 上设置 cookie。如果 URL 中的主机名以一个点结尾，此检查会被中断。这可允许任意站点设置 cookie，然后将其发送至不同且不相关的站点或域。(CVE-2022-27779)

  - 解码 URL 的主机名部分时，curl URL 解析器会错误接受诸如“/”的以百分号编码的 URL 分隔符，从而使其在以后检索时成为使用错误主机名的*不同* URL。例如，解析器会允许诸如 `http://example.com%2F127.0.0.1/` 的 URL 并将其转置为 `http://example.com/127.0.0.1/`。攻击者可利用此缺陷避开筛选和检查等。
    (CVE-2022-27780)

  - libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
    (CVE-2022-27781)

  - 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得过于容易。(CVE-2022-27782)

  - 使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用了结尾点而未使用构建 HSTS 缓存时的结尾点，则可绕过此机制。或者反过来
    - 在 HSTS 缓存中使用结尾点，而*不在* URL 中使用结尾点。
    (CVE-2022-30115)

  - 恶意服务器可在 HTTP 响应中提供过量的 `Set-Cookie:`  标头，而低于 7.84.0 版的 curl 会存储所有这些标头。数量够多（大）的 cookie 会向此服务器或这些 cookie 相匹配的其他服务器发出后续 HTTP 请求，从而使创建的请求超过 curl 为避免发送过大请求（1048576 字节）而在内部使用的阈值，而没有返回错误。只要保留和匹配这些 cookie 并且它们未过期，此拒绝状态就可能持续存在。由于 cookie 匹配规则，“foo.example.com”上的服务器可以设置匹配“bar.example.com”的 cookie，从而使同级服务器可以有效造成相同二级域上使用此方法的同级网站拒绝服务。(CVE-2022-32205)

  - curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)

  - 低于 7.84.0 版的 curl 将 cookie、alt-svc 和 hsts 数据保存到本地文件时，会通过将临时名称重命名为最终目标文件名称来完成操作，从而使该操作成为原子型操作。在该重命名操作中，它可能会意外*放宽*对目标文件的权限，使更多用户可访问更新后的文件。(CVE-2022-32207)

  - 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
    攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

  - 在进行 HTTP(S) 传输时，如果之前使用相同的句柄发出 `PUT` 请求（使用读取回调 (`CURLOPT_READFUNCTION`)），即使设置了 `CURLOPT_POSTFIELDS` 选项，libcurl 可能会错误地使用该回调来请求发送数据。此缺陷可能会使应用程序发生意外并导致其行为不当，并在后续的 `POST` 请求中发送错误的数据或使用释放后的内存或类似内容。从 PUT 更改为 POST 时，重用句柄的逻辑中存在此问题。(CVE-2022-32221)

  - 当 curl 用于检索和解析来自 HTTP(S) 服务器的 cookie 时，它使用控制代码接受 cookie，这些代码稍后被发送回 HTTP 服务器时可能会使服务器返回 400 响应。
    有效地令辅助站点拒绝向所有同级站点提供服务。(CVE-2022-35252)

  - 可指示 curl 解析 `.netrc` 文件以获取凭据。如果该文件以具有 4095 个连续非空白字符且无换行符的行结尾，则 curl 将首先读取超过基于堆栈的缓冲区的末尾，如果是 readworks，则写入一个超出其边界的零字节。在大多数情况下此问题会造成段错误或类似问题，但不同的环境也可能造成不同的结果。如果恶意用户可以向应用程序提供自定义 netrc 文件，或以其他方式影响其内容，则此缺陷可被用作拒绝服务。(CVE-2022-35260)

  - 在 7.86.0 版之前的 curl 中存在双重释放。如果指示 curl 使用 HTTP 代理进行具有非 HTTP URL 的传输，它会通过向代理发出 CONNECT 请求来与远程服务器建立连接，然后使协议的其余部分通过隧道。HTTP 代理可能拒绝此请求（HTTP 代理通常只允许传出连接至特定端口号，例如 HTTPS 的 443），而向客户端返回非 200 状态代码。由于错误/清理处理中的缺陷，如果在 URL 中使用以下方案之一进行传输，则这可能在 curl 中触发双重释放：dict、gopher、gophers、ldap、ldaps、rtmp、rtmps 或 telnet。低于 7.77.0 的版本均受影响。(CVE-2022-42915)

  - 在 7.86.0 版之前的 curl 中，可绕过 HSTS 检查以诱骗其继续使用 HTTP。使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用在 IDN 转换过程中被 ASCII 对应项替换的 IDN 字符，则可绕过此机制。例如使用字符 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 而不是通用 ASCII 句号 U+002E (.)。
    低于 7.77.0 2021-05-26 的版本均受影响。(CVE-2022-42916)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
177842	Nessus Network Monitor < 6.2.2 多个漏洞 (TNS-2023-23)	Nessus	Misc.	2023/6/30	2023/7/6	critical
168600	Amazon Linux AMI：curl (ALAS-2022-1646)	Nessus	Amazon Linux Local Security Checks	2022/12/10	2023/9/15	high
164482	Debian DLA-3085-1：curl - LTS 安全更新	Nessus	Debian Local Security Checks	2022/8/29	2023/10/13	high
194927	Universal Forwarders < 8.1.14、8.2.0 < 8.2.11、9.0.0 < 9.0.5 (SVD-2023-0614)	Nessus	CGI abuses	2024/5/2	2024/5/30	critical
161058	Ubuntu 18.04 LTS / 20.04 LTS / 22.04 LTS：curl 漏洞 (USN-5412-1)	Nessus	Ubuntu Local Security Checks	2022/5/11	2023/10/16	high
171046	Amazon Linux 2：(ALAS-2023-1924)	Nessus	Amazon Linux Local Security Checks	2023/2/6	2023/9/5	high
168498	RHEL 7 / 8：Red Hat JBoss Core Services Apache HTTP Server 2.4.51 SP1 (RHSA-2022: 8840)	Nessus	Red Hat Local Security Checks	2022/12/8	2024/4/28	critical
163681	Debian DSA-5197-1：curl - 安全更新	Nessus	Debian Local Security Checks	2022/8/2	2023/10/17	critical
173171	Amazon Linux 2023：curl、curl-minimal、libcurl (ALAS2023-2023-083)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2024/2/20	critical
194928	Splunk Enterprise 8.2.0 < 8.2.12、9.0.0 < 9.0.6、9.1.0 < 9.1.1 (SVD-2023-0808)	Nessus	CGI abuses	2024/5/2	2024/5/30	critical
162691	Ubuntu 16.04 ESM：curl 漏洞 (USN-5499-1)	Nessus	Ubuntu Local Security Checks	2022/7/1	2023/7/10	medium
161057	Slackware Linux 14.0/14.1/14.2/15.0/最新版 curl 多个漏洞 (SSA:2022-131-01)	Nessus	Slackware Local Security Checks	2022/5/11	2023/10/27	high
168911	GLSA-202212-01 : curl：多个漏洞	Nessus	Gentoo Local Security Checks	2022/12/18	2023/9/12	critical
194919	Splunk Enterprise <8.1.14、8.2.0 < 8.2.11、9.0.0 < 9.0.5 (SVD-2023-0613)	Nessus	CGI abuses	2024/5/2	2024/5/30	critical
194926	Universal Forwarders 8.2.0 < 8.2.12、9.0.0 < 9.0.6、9.1.0 < 9.1.1 (SVD-2023-0809)	Nessus	CGI abuses	2024/5/2	2024/5/30	critical

检测

插件搜索

critical

high

high

critical

high

high

critical

critical

critical

critical

medium

high

critical

critical

critical