The version of runc installed on the remote host is prior to 1.3.6-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2NITRO-ENCLAVES-2026-119 advisory.

    (*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject     Alternative Name (SAN) entries. This caused strings.Split(host, .) to execute repeatedly on the same     input hostname. With a large DNS SAN list, verification costs scaled quadratically based on the number of     SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before     building the certificate chain, this overhead occurred even for untrusted certificates. (CVE-2026-27145)

    On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root     when the final path component of the a path is a symbolic link and the path ends in /. For example,     'root.Open(symlink/)' will open symlink even when symlink is a symbolic link pointing outside of the     root. (CVE-2026-39822)

    When setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a     filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called     ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary     pre-existing host directory. (from https://github.com/opencontainers/runc/security/advisories/GHSA-     xjvp-4fhw-gc47) (CVE-2026-41579)

    Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive     CPU. (CVE-2026-42504)

    Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a     disclosure of pre-shared key identities in the unencrypted client hello. (CVE-2026-42505)

    When returning errors, functions in the net/textproto package would include its input as part of the     error. This might allow an attacker to inject misleading content to errors that are printed or logged.
    (CVE-2026-42507)

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

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-2138 advisory.

    (*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject     Alternative Name (SAN) entries. This caused strings.Split(host, .) to execute repeatedly on the same     input hostname. With a large DNS SAN list, verification costs scaled quadratically based on the number of     SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before     building the certificate chain, this overhead occurred even for untrusted certificates. (CVE-2026-27145)

    On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root     when the final path component of the a path is a symbolic link and the path ends in /. For example,     'root.Open(symlink/)' will open symlink even when symlink is a symbolic link pointing outside of the     root. (CVE-2026-39822)

    When setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a     filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called     ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary     pre-existing host directory. (from https://github.com/opencontainers/runc/security/advisories/GHSA-     xjvp-4fhw-gc47) (CVE-2026-41579)

    Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive     CPU. (CVE-2026-42504)

    Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a     disclosure of pre-shared key identities in the unencrypted client hello. (CVE-2026-42505)

    When returning errors, functions in the net/textproto package would include its input as part of the     error. This might allow an attacker to inject misleading content to errors that are printed or logged.
    (CVE-2026-42507)

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

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-104944 advisory.

    runc is a CLI tool for spawning and running containers according to the OCI specification. In versions     prior to 1.3.6, 1.4.0-rc.1, 1.4.0-rc.12, 1.5.0-rc.1, and 1.5.0-rc.1, when setting up the container rootfs,     setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an     image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a     hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.
    This issue is not exploitable under Docker, because Docker creates a top-level read-only layer that masks     any malicious /devsymlink present in the container image  unlike some other Linux container tooling,     whose higher-level runtimes built on runc remain exposed to exploitation via a malicious image. This issue     has been fixed in versions 1.3.6, 1.4.3 and 1.5.0.

Tenable has extracted the preceding description block directly from the Unity 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 version of runc installed on the remote host is prior to 1.3.6-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2ECS-2026-138 advisory.

    On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root     when the final path component of the a path is a symbolic link and the path ends in /. For example,     'root.Open(symlink/)' will open symlink even when symlink is a symbolic link pointing outside of the     root. (CVE-2026-39822)

    When setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a     filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called     ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary     pre-existing host directory. (from https://github.com/opencontainers/runc/security/advisories/GHSA-     xjvp-4fhw-gc47) (CVE-2026-41579)

    Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a     disclosure of pre-shared key identities in the unencrypted client hello. (CVE-2026-42505)

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

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

The AlmaLinux 9.2 host has a package installed that is affected by a vulnerability as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1784034091 advisory.

  - runc is a CLI tool for spawning and running containers according to the OCI specification. In versions     prior to 1.3.6, 1.4.0-rc.1, 1.4.0-rc.12, 1.5.0-rc.1, and 1.5.0-rc.1, when setting up the container rootfs,     setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an     image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a     hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.
    This issue is not exploitable under Docker, because Docker creates a top-level read-only layer that masks     any malicious /dev symlink present in the container image  unlike some other Linux container tooling,     whose higher-level runtimes built on runc remain exposed to exploitation via a malicious image. This issue     has been fixed in versions 1.3.6, 1.4.3 and 1.5.0. (CVE-2026-41579)

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-runc package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

    ['This is a PUBLIC release of a low-severity vulnerability in runc which\nhas been fixed in runc 1.3.6,     runc 1.4.3, and runc 1.5.0-rc.3. There was\nNO EMBARGO WINDOW for this vulnerability, as our analysis was     that the\nthreat of this issue was not severe and we noticed that a similar issue\nwas publicly fixed in     crun[1].\n\nBased on our analysis, this vulnerability has a score of 3.3 (Low) with\na CVSSv3 vector of     CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N.\n\n[1]:', '/* Impact */\n\nWhen setting up the container     rootfs, setupPtmx and setupDevSymlinks\ncall os.Remove and os.Symlink with a filepath.Join string which     allow an\nimage with /dev as a symlink to trick runc into deleting files called\nptmx on the host or     creating a hardcoded set of symlinks with specific\nnames and targets in an arbitrary pre-existing host     directory.\n\nPlease note that this issue is not exploitable under Docker because it\ncreates a top-level     ro layer that masks any malicious /dev symlink\npresent in the container image (this is also done without     mounting the\nlower layers so there is no opportunity for the malicious /dev symlink\nto trick it into     resolving to some other path). Unfortunately, Podman\nand containerd do not do this and so users using     those higher-level\nruntimes with runc can be exploited via a malicious image.\n\nThis issue mirrors a     somewhat similar issue in crun, which was also\npublished recently (CVE-2026-47766).\n\n Actually, at     the time we analysed this issue, containerd had dead code\nthat implemented this feature but the     implementation contained several\nsecurity issues that would arguably have made it more exploitable     than\nin runc. Luckily, the code appears to have never been used (at least\nsince 2017) and the code has     since been removed[2].\n\n[2]:', '/** Mitigating Factors **/\n\nThere are a few mitigating factors about     this issue which reduce the\nimpact for most users quite significantly, and is the reason why we\ndecided     to release the fix publicly without an embargo.\n\nWhile the deletion of 'ptmx' seems like a significant     issue, in practice\nit is quite limited. Notably, devpts does not permit you to unlink\n/dev/pts/ptmx     regardless of privileges and so it is not a usable target\nfor this attack. Additionally, while /dev/ptmx     can be unlinked, trying\nto use an image with a symlink from /dev to /dev will cause runc will\nreturn     an error before it reaches the buggy code (it correctly detects a\nsymlink loop while setting up the mount     target and the code correctly\nscopes the lookup inside the container). Thus, the only files called\nptmx     that are guaranteed to exist on the system cannot actually be\nremoved by this bug and so only some user     file that happens to have that\nspecific name could be deleted, which seems fairly unlikely to happen     on\nreal systems.\n\nAs for the issue of symlinks, again the impact is likely quite limited.\nWhile the     creation of arbitrary symlinks could be used to create drop-in\nfiles for system services (and thus lead     to a container breakout), the\nhardcoded set of symlink names and targets that this bug allows you     to\ncreate on the host make it quite unlikely that you would be able to do\nmuch more than pollute the     host system with dummy symlinks. Here is the\ncomplete list of symlinks that can be created with this     attack:\n\n * core  /proc/kcore\n * fd  /proc/self/fd/\n * ptmx  pts/ptmx\n * stdin  /proc/self/fd/0\n *     stdout  /proc/self/fd/1\n * stderr  /proc/self/fd/2\n\nNote that none of these symlinks are likely to     point to user-controlled\ndata -- the /proc/self/fd/$n symlinks are all properties of the     process\naccessing them (so privileged processes will only see the state they\nwere spawned with) and the     pts/ptmx symlink is almost certainly in the\nsame privilege scope as the directory the symlink itself is     in. It seems\nthe only somewhat plausible impact would be that a service could return\nan error when     trying to parse one of these symlinks and thus treat it as\nan invalid configuration file. How arbitrary     processes deal with this\nsituation is a bit hard to analyse, but most daemons require\nconfiguration     files to have certain suffixes (such as .conf) so it\'s not\nreally clear how large the impact is in     practice and it seems there are\na few barriers to clear to use this to cause a DoS or other     problems.\n\n This would actually be quite problematic if it could occur because\nglibc seemingly only     attempts to use /dev/ptmx when creating new\nterminals and thus most terminal managers (including tmux)     and shell\ntools (including sudo -- but not su) would fail to start and thus bring\nthe system to a halt.
    setupPtmx does add a symlink to /dev/pts/ptmx\nafterwards but on some systems the mode of the host     /dev/pts/ptmx is set\nto 0o000 which would still cause the same DoS issue.\n\n/* Mitigations */\n\nUsing     user namespaces restricts this attack fairly significantly such\nthat the attacker can only create/delete     inodes in directories that the\nremapped root user/group has write access to. Unless the root user     is\nremapped to an actual user on the host (such as with rootless containers\nthat don\'t use     '/etc/sub[ug]id'), this in practice means that an\nattacker would only be able to create or delete inodes     in world-writable\ndirectories.\n\nLSMs can restrict the scope of where in the host filesystem runc can     be\ntricked into operating on, though how much this helps is questionable.\nThe default     'container_runtime_t' SELinux label rules (or custom\nAppArmor rules for the host 'runc' context) may     restrict the scope where\nthese filesystem operations can operate on, but we have not done an\nin-depth     analysis on the impact of those kinds of LSM protections.\n\n/* Patches */\n\nThis issue has been patched     in runc 1.3.6, runc 1.4.3, and runc\n1.5.0-rc.3. The patches which resolve this issue on main are:\n\n *     864db8042dbb ('rootfs: make /dev initialisation code fd-based')\n * 66acd48f9d42 ('rootfs: make cgroupv1     subsystem symlinks fd-based')\n\nUnfortunately, backporting them to apply cleanly on top of runc     1.3.5\nand runc 1.4.2 requires quite a few other backports that would bloat the\nset of patches included     here. It is almost certainly easier for users to\njust update to the latest patch release (which is our     general\nrecommendation for any security release anyway).\n\n/* Credits */\n\nThanks to 'Davias' for     initially finding and reporting this issue. The\nsame underlying issue (with varying levels of     completeness) was later\nreported by Arthur Chan (@arthurscchan from Ada Logics), Junyi Liu\n(@mosskappa),     and Derek Manzella (@Dmanzella).\n\n-- \nAleksa Sarai\nFounding Engineer at Amutable'](CVE-2026-41579)

Tenable has extracted the preceding description block directly from the EulerOS docker-runc 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-runc package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

    runc is a CLI tool for spawning and running containers according to the OCI specification. In versions     prior to 1.3.6, 1.4.0-rc.1, 1.4.0-rc.12, 1.5.0-rc.1, and 1.5.0-rc.1, when setting up the container rootfs,     setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an     image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a     hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.
    This issue is not exploitable under Docker, because Docker creates a top-level read-only layer that masks     any malicious /dev symlink present in the container image - unlike some other Linux container tooling,     whose higher-level runtimes built on runc remain exposed to exploitation via a malicious image. This issue     has been fixed in versions 1.3.6, 1.4.3 and 1.5.0.(CVE-2026-41579)

Tenable has extracted the preceding description block directly from the EulerOS docker-runc 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 openSUSE 16 host has a package installed that is affected by multiple vulnerabilities as referenced in the openSUSE-SU-2026:21431-1 advisory.

    Update to 1.3.6.

    - CVE-2026-41579: malicious image with a `/dev` symlink can trigger limited host filesystem integrity     violations       (bsc#1268275).

    Other updates and bugfixes:

    - Version 1.3.6:
      * Various integration test improvements.
      * When masking directories with `maskPaths`, runc will now re- use a single `tmpfs` instance (which is     not writeable)         to reduce the number `tmpfs` superblocks that need to be reaped when containers die (in particular,     Kubernetes         applies masks to per-CPU sysfs directories which get expensive quickly).
    - Version 1.3.5:
      * Recursive atime-related mount flags (rrelatime et al.) are now applied properly.
      * PR #4757 caused a regression that resulted in spurious cannot start a container that has stopped     errors when         running runc create and has thus been reverted.
      * Updated builds to Go 1.25, libseccomp v2.6.0.
      * Minor signing keyring updates.

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.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:3433-1 advisory.

    Update to 1.3.6.

    - CVE-2026-41579: malicious image with a `/dev` symlink can trigger limited host filesystem integrity     violations       (bsc#1268275).

    Other updates and bugfixes:

    - Version 1.3.6:
      * When masking directories with `maskPaths`, runc will now re- use a single `tmpfs` instance (which is     not writeable)         to reduce the number `tmpfs` superblocks that need to be reaped when containers die (in particular,     Kubernetes         applies masks to per-CPU sysfs directories which get expensive quickly).
    - Version 1.3.5:
      * Recursive atime-related mount flags (rrelatime et al.) are now applied properly.
      * PR #4757 caused a regression that resulted in spurious cannot start a container that has stopped     errors when         running runc create and has thus been reverted.
      * Updated builds to Go 1.25, libseccomp v2.6.0.
      * Minor signing keyring updates.

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	名称	产品	系列	发布时间	最近更新时间	严重程度
345787	Amazon Linux 2 : runc (ALASNITRO-ENCLAVES-2026-119)	Nessus	Amazon Linux Local Security Checks	2026/9/14	2026/9/14	medium
345796	Amazon Linux 2023 : runc (ALAS2023-2026-2138)	Nessus	Amazon Linux Local Security Checks	2026/9/14	2026/9/14	medium
341477	Unity Linux 20.1070e Security Update: runc (UTSA-2026-104944)	Nessus	Unity Linux Local Security Checks	2026/8/29	2026/8/29	medium
351055	Amazon Linux 2 : runc (ALASECS-2026-138)	Nessus	Amazon Linux Local Security Checks	2026/9/29	2026/9/29	medium
352887	AlmaLinux 9.2 [TuxCare] Security Update: runc (ALMALINUX9.2:CLSA-2026:1784034091)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/9/30	medium
343647	EulerOS 2.0 SP12 : docker-runc (EulerOS-SA-2026-3256)	Nessus	Huawei Local Security Checks	2026/9/8	2026/9/8	medium
343732	EulerOS 2.0 SP12 : docker-runc (EulerOS-SA-2026-3331)	Nessus	Huawei Local Security Checks	2026/9/8	2026/9/8	medium
364750	EulerOS 2.0 SP13 : docker-runc (EulerOS-SA-2026-4133)	Nessus	Huawei Local Security Checks	2026/10/12	2026/10/12	medium
364774	EulerOS 2.0 SP13 : docker-runc (EulerOS-SA-2026-4042)	Nessus	Huawei Local Security Checks	2026/10/12	2026/10/12	medium
364018	EulerOS 2.0 SP15 : docker-runc (EulerOS-SA-2026-3907)	Nessus	Huawei Local Security Checks	2026/10/8	2026/10/15	medium
329715	openSUSE 16 Security Update : runc (openSUSE-SU-2026:21431-1)	Nessus	SuSE Local Security Checks	2026/7/25	2026/7/25	high
331547	SUSE SLED15 / SLES15 Security Update : runc (SUSE-SU-2026:3433-1)	Nessus	SuSE Local Security Checks	2026/8/1	2026/8/1	high

检测

插件搜索

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

high