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

  - 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)

  - The OCI Distribution Spec project defines an API protocol to facilitate and standardize the distribution     of content. In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone     was used to determine the type of document during push and pull operations. Documents that contain both     manifests and layers fields could be interpreted as either a manifest or an index in the absence of an     accompanying Content-Type header. If a Content-Type header changed between two pulls of the same digest, a     client may interpret the resulting content differently. The OCI Distribution Specification has been     updated to require that a mediaType value present in a manifest or index match the Content-Type header     used during the push and pull operations. Clients pulling from a registry may distrust the Content-Type     header and reject an ambiguous document that contains both manifests and layers fields or manifests     and config fields if they are unable to update to version 1.0.1 of the spec. (CVE-2021-41190)

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

The version of containerd installed on the remote host is prior to 1.4.6-3. It is, therefore, affected by a vulnerability as referenced in the ALAS2DOCKER-2022-016 advisory.

    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)

Tenable has extracted the preceding description block directly from the tested product 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 NewStart CGSL host, running version MAIN 6.06, has neod packages installed that are affected by multiple vulnerabilities:

  - 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)

  - A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve     Cryptography (ECC) certificates.An attacker could exploit the vulnerability by using a spoofed code-     signing certificate to sign a malicious executable, making it appear the file was from a trusted,     legitimate source, aka 'Windows CryptoAPI Spoofing Vulnerability'. (CVE-2020-0601)

  - In containerd (an industry-standard container runtime) before versions 1.3.10 and 1.4.4, containers     launched through containerd's CRI implementation (through Kubernetes, crictl, or any other pod/container     client that uses the containerd CRI service) that share the same image may receive incorrect environment     variables, including values that are defined for other containers. If the affected containers have     different security contexts, this may allow sensitive information to be unintentionally shared. If you are     not using containerd's CRI implementation (through one of the mechanisms described above), you are not     vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same     image which have different environment variables, you are not vulnerable to this issue. If you are not     launching multiple containers or Kubernetes pods from the same image in rapid succession, you have reduced     likelihood of being vulnerable to this issue This vulnerability has been fixed in containerd 1.3.10 and     containerd 1.4.4. Users should update to these versions. (CVE-2021-21334)

  - containerd is a container runtime available as a daemon for Linux and Windows. A bug was found in     containerd prior to versions 1.6.1, 1.5.10, and 1.14.12 where containers launched through containerd's CRI     implementation on Linux with a specially-crafted image configuration could gain access to read-only copies     of arbitrary files and directories on the host. This may bypass any policy-based enforcement on container     setup (including a Kubernetes Pod Security Policy) and expose potentially sensitive information.
    Kubernetes and crictl can both be configured to use containerd's CRI implementation. This bug has been     fixed in containerd 1.6.1, 1.5.10, and 1.4.12. Users should update to these versions to resolve the issue.
    (CVE-2022-23648)

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

The remote NewStart CGSL host, running version MAIN 6.06 (SP), has neod packages installed that are affected by multiple vulnerabilities:

  - 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)

  - A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve     Cryptography (ECC) certificates.An attacker could exploit the vulnerability by using a spoofed code-     signing certificate to sign a malicious executable, making it appear the file was from a trusted,     legitimate source, aka 'Windows CryptoAPI Spoofing Vulnerability'. (CVE-2020-0601)

  - In containerd (an industry-standard container runtime) before versions 1.3.10 and 1.4.4, containers     launched through containerd's CRI implementation (through Kubernetes, crictl, or any other pod/container     client that uses the containerd CRI service) that share the same image may receive incorrect environment     variables, including values that are defined for other containers. If the affected containers have     different security contexts, this may allow sensitive information to be unintentionally shared. If you are     not using containerd's CRI implementation (through one of the mechanisms described above), you are not     vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same     image which have different environment variables, you are not vulnerable to this issue. If you are not     launching multiple containers or Kubernetes pods from the same image in rapid succession, you have reduced     likelihood of being vulnerable to this issue This vulnerability has been fixed in containerd 1.3.10 and     containerd 1.4.4. Users should update to these versions. (CVE-2021-21334)

  - containerd is a container runtime available as a daemon for Linux and Windows. A bug was found in     containerd prior to versions 1.6.1, 1.5.10, and 1.14.12 where containers launched through containerd's CRI     implementation on Linux with a specially-crafted image configuration could gain access to read-only copies     of arbitrary files and directories on the host. This may bypass any policy-based enforcement on container     setup (including a Kubernetes Pod Security Policy) and expose potentially sensitive information.
    Kubernetes and crictl can both be configured to use containerd's CRI implementation. This bug has been     fixed in containerd 1.6.1, 1.5.10, and 1.4.12. Users should update to these versions to resolve the issue.
    (CVE-2022-23648)

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

The version of containerd installed on the remote host is prior to 1.4.6-3.9. It is, therefore, affected by a vulnerability as referenced in the ALAS-2021-1540 advisory.

    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. (CVE-2021-41103)

Tenable has extracted the preceding description block directly from the tested product 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 containerd 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 :

  - 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 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 host is affected by the vulnerability described in GLSA-202401-31 (containerd: Multiple Vulnerabilities)

  - 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)

  - containerd is an open source container runtime. A bug was found in containerd's CRI implementation where a     user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal     resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty     command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak.
    Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server     is used for handling container IO. This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should     update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted     images and commands are used and that only trusted users have permissions to execute commands in running     containers. (CVE-2022-23471)

  - containerd is a container runtime available as a daemon for Linux and Windows. A bug was found in     containerd prior to versions 1.6.1, 1.5.10, and 1.14.12 where containers launched through containerd's CRI     implementation on Linux with a specially-crafted image configuration could gain access to read-only copies     of arbitrary files and directories on the host. This may bypass any policy-based enforcement on container     setup (including a Kubernetes Pod Security Policy) and expose potentially sensitive information.
    Kubernetes and crictl can both be configured to use containerd's CRI implementation. This bug has been     fixed in containerd 1.6.1, 1.5.10, and 1.4.12. Users should update to these versions to resolve the issue.
    (CVE-2022-23648)

  - 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)

  - containerd is an open source container runtime. A bug was found in the containerd's CRI implementation     where programs inside a container can cause the containerd daemon to consume memory without bound during     invocation of the `ExecSync` API. This can cause containerd to consume all available memory on the     computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to     use containerd's CRI implementation; `ExecSync` may be used when running probes or when executing     processes via an exec facility. This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should     update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted     images and commands are used. (CVE-2022-31030)

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)

  - 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.

An update of the telegraf package has been released.

The remote SUSE Linux SLES12 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:03540-1 advisory.

    - Include historical changelog data from before the docker-stable fork. The       initial changelog entry did technically provide all the necessary       information, but our CVE tracking tools do not understand how the package is       forked and so it seems that this package does not include fixes for ~12 years       of updates. So, include a copy of the original package's changelog up until       the fork point. (bsc#1250596)

    - Remove git-core recommends on SLE. Most SLE systems have       installRecommends=yes by default and thus end up installing git with Docker.
      bsc#1250508

      This feature is mostly intended for developers ('docker build git://') so       most users already have the dependency installed, and the error when git is       missing is fairly straightforward (so they can easily figure out what they       need to install).

    - Backport <https://github.com/moby/moby/pull/48517>. bsc#1247362

    - Update to docker-buildx v0.25.0. Upstream changelog:
      <https://github.com/docker/buildx/releases/tag/v0.25.0>

    - Do not try to inject SUSEConnect secrets when in Rootless Docker mode, as       Docker does not have permission to access the host zypper credentials in this       mode (and unprivileged users cannot disable the feature using       /etc/docker/suse-secrets-enable.) bsc#1240150

    - Initial docker-stable fork, forked from Docker 24.0.7-ce release       (packaged on 2024-02-14). The original changelog is included below for       historical reference.

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.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
157388	SUSE SLES15 Security Update : containerd, docker (SUSE-SU-2022:0334-1)	Nessus	SuSE Local Security Checks	2022/2/5	2023/7/13	high
160406	Amazon Linux 2 : containerd (ALASDOCKER-2022-016)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2024/12/11	high
266278	NewStart CGSL MAIN 6.06 : neod Multiple Vulnerabilities (NS-SA-2025-0234)	Nessus	NewStart CGSL Local Security Checks	2025/9/30	2025/12/17	high
301228	NewStart CGSL MAIN 6.06 (SP) : neod Multiple Vulnerabilities (NS-SA-2026-0029)	Nessus	NewStart CGSL Local Security Checks	2026/3/6	2026/3/9	high
153864	Amazon Linux AMI : containerd (ALAS-2021-1540)	Nessus	Amazon Linux Local Security Checks	2021/10/4	2024/12/11	high
153945	Photon OS 3.0: Containerd PHSA-2021-3.0-0311	Nessus	PhotonOS Local Security Checks	2021/10/8	2025/8/24	high
153980	Photon OS 2.0: Containerd PHSA-2021-2.0-0402	Nessus	PhotonOS Local Security Checks	2021/10/11	2024/7/23	high
158404	EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1251)	Nessus	Huawei Local Security Checks	2022/2/25	2022/2/25	high
158427	EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1239)	Nessus	Huawei Local Security Checks	2022/2/25	2025/2/26	high
189846	GLSA-202401-31 : containerd: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	2024/1/31	2024/1/31	high
162441	EulerOS 2.0 SP8 : docker-engine (EulerOS-SA-2022-1926)	Nessus	Huawei Local Security Checks	2022/6/22	2022/6/22	high
204388	Photon OS 5.0: Telegraf PHSA-2023-5.0-0041	Nessus	PhotonOS Local Security Checks	2024/7/24	2025/8/21	high
270099	SUSE SLES12 Security Update : docker-stable (SUSE-SU-2025:03540-1)	Nessus	SuSE Local Security Checks	2025/10/11	2025/10/11	critical

检测

插件搜索

high

high

high

high

high

high

high

high

high

high

high

high

critical