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

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

  - Moby 是 Docker 创建的开源项目，用于实现并加快软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby (Docker Engine) 行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，即在“ExecSync”API 调用期间，容器内的程序可导致 containerd 后台程序无限制地消耗内存。这可能导致 containerd 消耗计算机上的所有可用内存，从而拒绝为其他合法工作负载提供服务。Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现；运行探测或通过 exec 设施执行进程时，可使用“ExecSync”。此错误已在 containerd 1.6.6 和 1.5.13 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的图像和命令。(CVE-2022-31030)

  - Moby 是 Docker 创建的开源项目，用于实现软件容器化。在 Moby (Docker Engine) 中发现缺陷，未正确设置附属组。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 此错误已在 Moby (Docker Engine) 20.10.18 中修复。应停止正在运行的容器，然后重新启动以修复权限。对于无法升级的用户，无需使用 `USER $USERNAME` Dockerfile 指令即可解决此问题。改为调用 `ENTRYPOINT [su, -, user]` 即可正确设置附属组。(CVE-2022-36109)

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

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

  - containerd 是容器运行时。在 1.4.8 和 1.5.4 之前的 containerd 版本中发现一个错误，在这些版本中，提取特别构建的容器映像会更改主机文件系统中现有文件的 Unix 文件权限。文件权限变更可拒绝文件预期所有者的访问、扩大对其他文件的访问权限，或设置 setuid、setgid 和 sticky 等扩展位。此错误不会直接允许在没有其他合作进程的情况下读取、修改或执行文件。此错误已在 containerd 1.5.4 和 1.4.8 中修复。作为变通方案，确保用户只从受信任的来源提取图像。SELinux 和 AppArmor 等 Linux 安全模块 (LSM) 可通过防止 containerd 与特定文件交互的策略和配置文件，来限制可能受此错误影响的文件。(CVE-2021-32760)

  - containerd 是一个强调简易性、稳定性和可移植性的开源容器运行时。
    在 containerd 中发现一个错误，其中容器根目录和某些插件的限制权限不足，非特权 Linux 用户可利用此漏洞，遍历目录内容并执行程序。当容器包含的可执行程序具有扩展权限位（如 setuid）时，非特权 Linux 用户可发现并执行这些程序。当主机上的非特权 Linux 用户与容器内文件所有者或群组的 UID 冲突时，主机上的非特权 Linux 用户可发现、读取和修改这些文件。此漏洞已在 containerd 1.4.11 和 containerd 1.5.7 中修复。用户应在这些版本发布后进行相应更新，并可通过重新启动容器或更新目录权限来缓解此漏洞。无法更新的用户应限制受信任的用户访问主机的权限。更新绑定目录的容器的目录权限。(CVE-2021-41103)

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，即在“ExecSync”API 调用期间，容器内的程序可导致 containerd 后台程序无限制地消耗内存。这可能导致 containerd 消耗计算机上的所有可用内存，从而拒绝为其他合法工作负载提供服务。Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现；运行探测或通过 exec 设施执行进程时，可使用“ExecSync”。此错误已在 containerd 1.6.6 和 1.5.13 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的图像和命令。 (CVE-2022-31030)

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

因此，它受到 ALAS2022-2022-210 公告中提及的多个漏洞影响。

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

  - Moby 是 Docker 创建的开源项目，用于实现并加快软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby (Docker Engine) 行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，即在“ExecSync”API 调用期间，容器内的程序可导致 containerd 后台程序无限制地消耗内存。这可能导致 containerd 消耗计算机上的所有可用内存，从而拒绝为其他合法工作负载提供服务。Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现；运行探测或通过 exec 设施执行进程时，可使用“ExecSync”。此错误已在 containerd 1.6.6 和 1.5.13 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的图像和命令。(CVE-2022-31030)

  - Moby 是 Docker 创建的开源项目，用于实现软件容器化。在 Moby (Docker Engine) 中发现缺陷，未正确设置附属组。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 此错误已在 Moby (Docker Engine) 20.10.18 中修复。应停止正在运行的容器，然后重新启动以修复权限。对于无法升级的用户，无需使用 `USER $USERNAME` Dockerfile 指令即可解决此问题。改为调用 `ENTRYPOINT [su, -, user]` 即可正确设置附属组。(CVE-2022-36109)

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

远程 Ubuntu 20.04 LTS 主机上安装的程序包受到 USN-5311-2 公告中提及一个漏洞影响。

    USN-5311-1 发布了 containerd 的更新。遗憾的是，后续更新错误地恢复了此 CVE 的修补程序。此更新修正了这一问题。

    我们对不便之处表示抱歉。



Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

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

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

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

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

远程主机上安装的 containerd 版本低于 1.4.6-8.12。因此，该应用程序受到 ALAS-2022-1568 公告中提及的漏洞的影响。

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

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

远程主机上安装的 containerd 版本低于 1.4.13-3。远程主机上安装的 docker 版本低于 20.10.13-2。远程主机上安装的 ecs-init 版本低于 1.61.1-1。远程主机上安装的 runc 版本低于 1.0.3-3。因此，该软件受到 ALAS2ECS-2022-001 公告中提及的多个漏洞影响。

    在 containerd 中发现一个错误，其中通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。(CVE-2022-23648)

    Moby 是 Docker 创建的一个开源项目，用于实现和加速软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby (Docker Engine) 行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

    在 containerd 的 CRI 实现中发现一个缺陷，其中容器内的程序可导致 containerd 后台程序在调用 ExecSync API 期间无边界地消耗内存。这可能导致 containerd 消耗计算机上的所有可用内存，从而拒绝为其他合法工作负载提供服务。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现；运行探测或通过 exec 设施执行进程时，可使用 ExecSync。 (CVE-2022-31030)

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

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

远程主机会受到 GLSA-202401-31 中所述漏洞的影响（containerd：多个漏洞）

  - containerd 是容器运行时。在 1.4.8 和 1.5.4 之前的 containerd 版本中发现一个错误，在这些版本中，提取特别构建的容器映像会更改主机文件系统中现有文件的 Unix 文件权限。文件权限变更可拒绝文件预期所有者的访问、扩大对其他文件的访问权限，或设置 setuid、setgid 和 sticky 等扩展位。此错误不会直接允许在没有其他合作进程的情况下读取、修改或执行文件。此错误已在 containerd 1.5.4 和 1.4.8 中修复。作为变通方案，确保用户只从受信任的来源提取图像。SELinux 和 AppArmor 等 Linux 安全模块 (LSM) 可通过防止 containerd 与特定文件交互的策略和配置文件，来限制可能受此错误影响的文件。(CVE-2021-32760)

  - containerd 是一个强调简易性、稳定性和可移植性的开源容器运行时。
    在 containerd 中发现一个错误，其中容器根目录和某些插件的限制权限不足，非特权 Linux 用户可利用此漏洞，遍历目录内容并执行程序。当容器包含的可执行程序具有扩展权限位（如 setuid）时，非特权 Linux 用户可发现并执行这些程序。当主机上的非特权 Linux 用户与容器内文件所有者或群组的 UID 冲突时，主机上的非特权 Linux 用户可发现、读取和修改这些文件。此漏洞已在 containerd 1.4.11 和 containerd 1.5.7 中修复。用户应在这些版本发布后进行相应更新，并可通过重新启动容器或更新目录权限来缓解此漏洞。无法更新的用户应限制受信任的用户访问主机的权限。更新绑定目录的容器的目录权限。(CVE-2021-41103)

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，用户可在其中耗尽主机上的内存。在 CRI 流服务器中，如果请求 TTY，则会启动一个 go 例程来处理终端大小调整事件。如果用户的进程因错误命令等原因无法启动，则 go 例程将在没有接收器的情况下等待发送，从而导致内存泄漏。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现，流服务器尅用于处理容器 IO。此错误已在 containerd 1.6.12 和 1.5.16 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的映像和命令，并且只有受信任的用户才有权限在运行中的容器中执行命令。(CVE-2022-23471)

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

  - Moby 是 Docker 创建的开源项目，用于实现并加快软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby (Docker Engine) 行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，即在“ExecSync”API 调用期间，容器内的程序可导致 containerd 后台程序无限制地消耗内存。这可能导致 containerd 消耗计算机上的所有可用内存，从而拒绝为其他合法工作负载提供服务。Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现；运行探测或通过 exec 设施执行进程时，可使用“ExecSync”。此错误已在 containerd 1.6.6 和 1.5.13 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的图像和命令。 (CVE-2022-31030)

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

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

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

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

远程主机上安装的 containerd 版本低于 1.4.6-8。因此，该应用程序受到 ALAS2ECS-2023-024 公告中提及的漏洞的影响。

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

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

远程主机上安装的 containerd 版本低于 1.4.6-8。因此，该应用程序受到 ALAS2DOCKER-2022-015 公告中提及的漏洞的影响。

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

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

远程主机上安装的 containerd 版本低于 1.4.6-8。因此，该 containerd 受到 ALAS2NITRO-ENCLAVES-2022-015 公告中提及的一个漏洞的影响。

  - containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
    (CVE-2022-23648)

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

因此，它受到 ALAS2022-2022-032 公告中提及的一个漏洞影响。

    在 containerd 中发现一个错误，其中通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。(CVE-2022-23648)

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

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
173188	Amazon Linux 2023：containerd、containerd-stress (ALAS2023-2023-079)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2024/12/11	high
183540	Ubuntu 16.04 ESM：containerd 漏洞 (USN-5521-1)	Nessus	Ubuntu Local Security Checks	2023/10/20	2024/8/27	high
170600	Amazon Linux 2022：(ALAS2022-2022-210)	Nessus	Amazon Linux Local Security Checks	2023/1/25	2024/12/11	high
161245	Ubuntu 20.04 LTS：containerd 回归 (USN-5311-2)	Nessus	Ubuntu Local Security Checks	2022/5/17	2024/10/29	high
158574	Ubuntu 18.04 LTS / 20.04 LTS：containerd 漏洞 (USN-5311-1)	Nessus	Ubuntu Local Security Checks	2022/3/3	2024/8/27	high
158587	Amazon Linux AMI：containerd (ALAS-2022-1568)	Nessus	Amazon Linux Local Security Checks	2022/3/4	2024/12/11	high
178301	Amazon Linux 2：ecs-init、docker、containerd、runc (ALASECS-2022-001)	Nessus	Amazon Linux Local Security Checks	2023/7/14	2025/4/11	high
189846	GLSA-202401-31：containerd：多个漏洞	Nessus	Gentoo Local Security Checks	2024/1/31	2024/1/31	high
158677	Debian DSA-5091-1：containerd - 安全更新	Nessus	Debian Local Security Checks	2022/3/7	2022/4/26	high
185918	Amazon Linux 2：containerd (ALASECS-2023-024)	Nessus	Amazon Linux Local Security Checks	2023/11/16	2024/12/11	high
160407	Amazon Linux 2：containerd (ALASDOCKER-2022-015)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2024/12/11	high
160992	Amazon Linux 2：containerd (ALASNITRO-ENCLAVES-2022-015)	Nessus	Amazon Linux Local Security Checks	2022/5/11	2024/12/11	high
212469	Amazon Linux 2022：containerd、containerd-stress (ALAS2022-2022-032)	Nessus	Amazon Linux Local Security Checks	2024/12/11	2024/12/12	high

检测

插件搜索

high

high

high

high

high

high

high

high

high

high

high

high

high