The remote SUSE Linux SUSE15 host has packages installed that are affected by multiple vulnerabilities as referenced in the openSUSE-SU-2021:1404-1 advisory.

  - runc before 1.0.0-rc95 allows a Container Filesystem Breakout via Directory Traversal. To exploit the     vulnerability, an attacker must be able to create multiple containers with a fairly specific mount     configuration. The problem occurs via a symlink-exchange attack that relies on a race condition.
    (CVE-2021-30465)

  - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where     pulling and extracting a specially-crafted container image can result in Unix file permission changes for     existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner     of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does     not directly allow files to be read, modified, or executed without an additional cooperating process. This     bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from     trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially     affected by this bug through policies and profiles that prevent containerd from interacting with specific     files. (CVE-2021-32760)

  - Moby is an open-source project created by Docker to enable software containerization. A bug was found in     Moby (Docker Engine) where attempting to copy files using `docker cp` into a specially-crafted container     can result in Unix file permission changes for existing files in the host's filesystem, widening access to     others. This bug does not directly allow files to be read, modified, or executed without an additional     cooperating process. This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this     version as soon as possible. Running containers do not need to be restarted. (CVE-2021-41089)

  - Moby is an open-source project created by Docker to enable software containerization. A bug was found in     Moby (Docker Engine) where the data directory (typically `/var/lib/docker`) contained subdirectories with     insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory     contents and execute programs. When containers included executable programs with extended permission bits     (such as `setuid`), unprivileged Linux users could discover and execute those programs. When the UID of an     unprivileged Linux user on the host collided with the file owner or group inside a container, the     unprivileged Linux user on the host could discover, read, and modify those files. This bug has been fixed     in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running     containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade     limit access to the host to trusted users. Limit access to host volumes to trusted containers.
    (CVE-2021-41091)

  - Docker CLI is the command line interface for the docker container runtime. A bug was found in the Docker     CLI where running `docker login my-private-registry.example.com` with a misconfigured configuration file     (typically `~/.docker/config.json`) listing a `credsStore` or `credHelpers` that could not be executed     would result in any provided credentials being sent to `registry-1.docker.io` rather than the intended     private registry. This bug has been fixed in Docker CLI 20.10.9. Users should update to this version as     soon as possible. For users unable to update ensure that any configured credsStore or credHelpers entries     in the configuration file reference an installed credential helper that is executable and on the PATH.
    (CVE-2021-41092)

  - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.
    A bug was found in containerd where container root directories and some plugins had insufficiently     restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and     execute programs. When containers included executable programs with extended permission bits (such as     setuid), unprivileged Linux users could discover and execute those programs. When the UID of an     unprivileged Linux user on the host collided with the file owner or group inside a container, the     unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has     been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are     released and may restart containers or update directory permissions to mitigate the vulnerability. Users     unable to update should limit access to the host to trusted users. Update directory permission on     container bundles directories. (CVE-2021-41103)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Ubuntu 16.04 ESM host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-5521-1 advisory.

    It was discovered that containerd insufficiently restricted permissions on container root and plugin     directories. If a user or automated system were tricked into launching a specially crafted container     image, a remote attacker could traverse directory contents and modify files and execute programs on the     host file system, possibly leading to privilege escalation. (CVE-2021-41103)

    It was discovered that containerd incorrectly handled file permission changes. If a user or automated     system were tricked into launching a specially crafted container image, a remote attacker could change     permissions on files on the host file system and possibly escalate privileges. (CVE-2021-32760)

    It was discovered that containerd allows attackers to gain access to read- only copies of arbitrary files     and directories on the host via a specially- crafted image configuration. An attacker could possibly use     this issue to obtain sensitive information. (CVE-2022-23648)

    It was discovered that containerd incorrectly handled certain memory operations. A remote attacker could     use this to cause a denial of service. (CVE-2022-31030)

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking     vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format     includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the     default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or     later, the default containerd resolver will provide its authentication credentials if the server where the     URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker     publishes a public image with a manifest that directs one of the layers to be fetched from a web server     they control and they trick a user or system into pulling the image, they can obtain the credentials used     for pulling that image. In some cases, this may be the user's username and password for the registry. In     other cases, this may be the credentials attached to the cloud virtual instance which can grant access to     other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin     (which can be used by Kubernetes), the ctr development tool, and other client programs that have     explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and     later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using     cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.
    Other container runtimes built on top of containerd but not using the default resolver (such as Docker)     are not affected. (CVE-2020-15157)

  - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in     which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if     the root user in the remapped namespace has access to the host filesystem they can modify files under     '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and     19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)

  - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where     pulling and extracting a specially-crafted container image can result in Unix file permission changes for     existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner     of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does     not directly allow files to be read, modified, or executed without an additional cooperating process. This     bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from     trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially     affected by this bug through policies and profiles that prevent containerd from interacting with specific     files. (CVE-2021-32760)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote Oracle Linux 7 host has packages installed that are affected by a vulnerability as referenced in the ELSA-2021-9373 advisory.

    - Address CVE-2021-32760

    docker-cli
    - updated containerd minimum version to 1.4.8 to address CVE-2021-32760.

    docker-engine

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SUSE15 host has packages installed that are affected by a vulnerability as referenced in the openSUSE-SU-2021:2412-1 advisory.

  - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where     pulling and extracting a specially-crafted container image can result in Unix file permission changes for     existing files in the hosts filesystem. Changes to file permissions can deny access to the expected owner     of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does     not directly allow files to be read, modified, or executed without an additional cooperating process. This     bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from     trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially     affected by this bug through policies and profiles that prevent containerd from interacting with specific     files. (CVE-2021-32760)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2021:3506-1 advisory.

    Docker was updated to 20.10.9-ce. (bsc#1191355)

    See upstream changelog in the packaged       /usr/share/doc/packages/docker/CHANGELOG.md.

      CVE-2021-41092 CVE-2021-41089 CVE-2021-41091 CVE-2021-41103

    container was updated to v1.4.11, to fix CVE-2021-41103. bsc#1191355

    - CVE-2021-32760: Fixed that a archive package allows chmod of file outside of unpack target directory     (bsc#1188282)

    - Install systemd service file as well (bsc#1190826)

    Update to runc v1.0.2. Upstream changelog is available from

      https://github.com/opencontainers/runc/releases/tag/v1.0.2

    * Fixed a failure to set CPU quota period in some cases on cgroup v1.
    * Fixed the inability to start a container with the 'adding seccomp filter       rule for syscall ...' error, caused by redundant seccomp rules (i.e. those       that has action equal to the default one). Such redundant rules are now       skipped.
    * Made release builds reproducible from now on.
    * Fixed a rare debug log race in runc init, which can result in occasional       harmful 'failed to decode ...' errors from runc run or exec.
    * Fixed the check in cgroup v1 systemd manager if a container needs to be       frozen before Set, and add a setting to skip such freeze unconditionally.
      The previous fix for that issue, done in runc 1.0.1, was not working.

    Update to runc v1.0.1. Upstream changelog is available from

    https://github.com/opencontainers/runc/releases/tag/v1.0.1

    * Fixed occasional runc exec/run failure ('interrupted system call') on an       Azure volume.
    * Fixed 'unable to find groups ... token too long' error with /etc/group       containing lines longer than 64K characters.
    * cgroup/systemd/v1: fix leaving cgroup frozen after Set if a parent cgroup is       frozen. This is a regression in 1.0.0, not affecting runc itself but some       of libcontainer users (e.g Kubernetes).
    * cgroupv2: bpf: Ignore inaccessible existing programs in case of       permission error when handling replacement of existing bpf cgroup       programs. This fixes a regression in 1.0.0, where some SELinux       policies would block runc from being able to run entirely.
    * cgroup/systemd/v2: don't freeze cgroup on Set.
    * cgroup/systemd/v1: avoid unnecessary freeze on Set.
    - fix issues with runc under openSUSE MicroOS's SELinux policy. bsc#1187704

    Update to runc v1.0.0. Upstream changelog is available from

    https://github.com/opencontainers/runc/releases/tag/v1.0.0

    ! The usage of relative paths for mountpoints will now produce a warning       (such configurations are outside of the spec, and in future runc will       produce an error when given such configurations).
    * cgroupv2: devices: rework the filter generation to produce consistent       results with cgroupv1, and always clobber any existing eBPF       program(s) to fix runc update and avoid leaking eBPF programs       (resulting in errors when managing containers).
    * cgroupv2: correctly convert 'number of IOs' statistics in a       cgroupv1-compatible way.
    * cgroupv2: support larger than 32-bit IO statistics on 32-bit architectures.
    * cgroupv2: wait for freeze to finish before returning from the freezing       code, optimize the method for checking whether a cgroup is frozen.
    * cgroups/systemd: fixed 'retry on dbus disconnect' logic introduced in rc94
    * cgroups/systemd: fixed returning 'unit already exists' error from a systemd       cgroup manager (regression in rc94)     + cgroupv2: support SkipDevices with systemd driver     + cgroup/systemd: return, not ignore, stop unit error from Destroy     + Make 'runc --version' output sane even when built with go get or       otherwise outside of our build scripts.
    + cgroups: set SkipDevices during runc update (so we don't modify       cgroups at all during runc update).
    + cgroup1: blkio: support BFQ weights.
    + cgroupv2: set per-device io weights if BFQ IO scheduler is available.

    Update to runc v1.0.0~rc95. Upstream changelog is available from     https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc95

    This release of runc contains a fix for CVE-2021-30465, and users are     strongly recommended to update (especially if you are providing     semi-limited access to spawn containers to untrusted users). (bsc#1185405)

    Update to runc v1.0.0~rc94. Upstream changelog is available from     https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc94

    Breaking Changes:
    * cgroupv1: kernel memory limits are now always ignored, as kmemcg has       been effectively deprecated by the kernel. Users should make use of regular       memory cgroup controls.

    Regression Fixes:

    * seccomp: fix 32-bit compilation errors
    * runc init: fix a hang caused by deadlock in seccomp/ebpf loading code
    * runc start: fix 'chdir to cwd: permission denied' for some setups

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

An update of the telegraf package has been released.

The remote SUSE Linux SLES15 host has a package installed that is affected by a vulnerability as referenced in the SUSE- SU-2021:2412-1 advisory.

    - CVE-2021-32760: Fixed a bug which allows untrusted container images to change permissions in the host's     filesystem. (bsc#1188282)

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

An update of the docker package has been released.

According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking     vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format     includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the     default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or     later, the default containerd resolver will provide its authentication credentials if the server where the     URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker     publishes a public image with a manifest that directs one of the layers to be fetched from a web server     they control and they trick a user or system into pulling the image, they can obtain the credentials used     for pulling that image. In some cases, this may be the user's username and password for the registry. In     other cases, this may be the credentials attached to the cloud virtual instance which can grant access to     other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin     (which can be used by Kubernetes), the ctr development tool, and other client programs that have     explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and     later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using     cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.
    Other container runtimes built on top of containerd but not using the default resolver (such as Docker)     are not affected. (CVE-2020-15157)

  - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where     pulling and extracting a specially-crafted container image can result in Unix file permission changes for     existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner     of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does     not directly allow files to be read, modified, or executed without an additional cooperating process. This     bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from     trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially     affected by this bug through policies and profiles that prevent containerd from interacting with specific     files. (CVE-2021-32760)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote Ubuntu 18.04 LTS / 20.04 LTS host has packages installed that are affected by a vulnerability as referenced in the USN-5012-1 advisory.

    It was discovered that containerd incorrectly handled file permission changes. If a user or automated     system were tricked into launching a specially crafted container image, a remote attacker could change     permissions on files on the host filesystem and possibly escalate privileges.

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking     vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format     includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the     default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or     later, the default containerd resolver will provide its authentication credentials if the server where the     URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker     publishes a public image with a manifest that directs one of the layers to be fetched from a web server     they control and they trick a user or system into pulling the image, they can obtain the credentials used     for pulling that image. In some cases, this may be the user's username and password for the registry. In     other cases, this may be the credentials attached to the cloud virtual instance which can grant access to     other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin     (which can be used by Kubernetes), the ctr development tool, and other client programs that have     explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and     later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using     cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.
    Other container runtimes built on top of containerd but not using the default resolver (such as Docker)     are not affected. (CVE-2020-15157)

  - containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows.
    In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host     network containers. Access controls for the shim's API socket verified that the connecting process had an     effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would     allow malicious containers running in the same network namespace as the shim, with an effective UID of 0     but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This     vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon     as they are released. It should be noted that containers started with an old version of containerd-shim     should be stopped and restarted, as running containers will continue to be vulnerable even after an     upgrade. If you are not providing the ability for untrusted users to start containers in the same network     namespace as the shim (typically the 'host' network namespace, for example with docker run --net=host or     hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this     issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract     sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice     to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The     containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of     isolation mechanisms used for a container necessarily increases that container's privilege, regardless of     what container runtime is used for running that container. (CVE-2020-15257)

  - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where     pulling and extracting a specially-crafted container image can result in Unix file permission changes for     existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner     of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does     not directly allow files to be read, modified, or executed without an additional cooperating process. This     bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from     trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially     affected by this bug through policies and profiles that prevent containerd from interacting with specific     files. (CVE-2021-32760)

  - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.
    A bug was found in containerd where container root directories and some plugins had insufficiently     restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and     execute programs. When containers included executable programs with extended permission bits (such as     setuid), unprivileged Linux users could discover and execute those programs. When the UID of an     unprivileged Linux user on the host collided with the file owner or group inside a container, the     unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has     been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are     released and may restart containers or update directory permissions to mitigate the vulnerability. Users     unable to update should limit access to the host to trusted users. Update directory permission on     container bundles directories. (CVE-2021-41103)

  - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug     was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with     non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling     programs with inheritable file capabilities to elevate those capabilities to the permitted set during     `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise     unprivileged users and processes can execute those programs and gain the specified file capabilities up to     the bounding set. Due to this bug, containers which included executable programs with inheritable file     capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable     file capabilities up to the container's bounding set. Containers which use Linux users and groups to     perform privilege separation inside the container are most directly impacted. This bug did not affect the     container security sandbox as the inheritable set never contained more capabilities than were included in     the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers     should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes     Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a     workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop     inheritable capabilities prior to the primary process starting. (CVE-2022-24769)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
154769	openSUSE 15 Security Update : containerd, docker, runc (openSUSE-SU-2021:1404-1)	Nessus	SuSE Local Security Checks	2021/11/1	2023/11/27	high
183540	Ubuntu 16.04 ESM : containerd vulnerabilities (USN-5521-1)	Nessus	Ubuntu Local Security Checks	2023/10/20	2024/8/27	high
159808	EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1445)	Nessus	Huawei Local Security Checks	2022/4/18	2022/5/6	medium
152049	Oracle Linux 7 : containerd (ELSA-2021-9373)	Nessus	Oracle Linux Local Security Checks	2021/7/23	2024/10/22	medium
151860	openSUSE 15 Security Update : containerd (openSUSE-SU-2021:2412-1)	Nessus	SuSE Local Security Checks	2021/7/21	2022/1/20	medium
154638	SUSE SLES15: containerd / docker / docker-bash-completion / etc (SUSE-SU-2021:3506-1)	Nessus	SuSE Local Security Checks	2021/10/28	2026/6/26	high
333780	Photon OS 5.0: Telegraf PHSA-2023-5.0-91-0041	Nessus	PhotonOS Local Security Checks	2026/8/10	2026/8/12	high
151885	SUSE SLES15 Security Update : containerd (SUSE-SU-2021:2412-1)	Nessus	SuSE Local Security Checks	2021/7/21	2026/6/25	medium
151952	Photon OS 1.0: Docker PHSA-2021-1.0-0414	Nessus	PhotonOS Local Security Checks	2021/7/22	2021/7/30	medium
160004	EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1501)	Nessus	Huawei Local Security Checks	2022/4/20	2022/4/20	medium
160042	EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1482)	Nessus	Huawei Local Security Checks	2022/4/21	2025/2/26	medium
151830	Ubuntu 18.04 LTS / 20.04 LTS : containerd vulnerabilities (USN-5012-1)	Nessus	Ubuntu Local Security Checks	2021/7/20	2024/8/27	medium
162362	EulerOS 2.0 SP5 : docker-engine (EulerOS-SA-2022-1886)	Nessus	Huawei Local Security Checks	2022/6/17	2023/10/20	high

检测

插件搜索

high

high

medium

medium

medium

high

high

medium

medium

medium

medium

medium

high