containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1, a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start), causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue.

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

    containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1,     a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start),     causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36,     2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue.

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.

An update of the containerd package has been released.

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

    - CVE-2026-39882: go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp: Memory exhaustion via     uncapped HTTP       response body reading (bsc#1274214).
    - CVE-2026-47262: Denial of Service (DoS) condition via a maliciously crafted image (bsc#1268441).
    - CVE-2026-53493: a crafted OCI index graph can force very high CPU/memory usage during PullImage (before     container       start), causing long ContainerCreating stalls and, at larger sizes, node/runtime instability     (bsc#1282669).
    - CVE-2026-53495: CRI ExecSync Goroutine Leak Leads to Node-Level Denial of Service (bsc#1280007).
    - CVE-2026-95838: github.com/containerd/containerd: processing of certain image layers causes superlinear     time       complexity in unpack handler and can lead to DoS (bsc#1285124).

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.

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

    containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1,     a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start),     causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36,     2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue. (CVE-2026-53493)

    Previously, after a channel has been established, a malicious peer could send crafted messages that would     deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled     explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of     buffering and blocking. (CVE-2026-56855)

    The `github.com/moby/sys/user` package provides Go utilities for parsing and looking up entries in Unix-     style user and group database files. Versions before 0.4.1 do not sufficiently limit entries when parsing     `/etc/passwd`- or `/etc/group`-style files, allowing an attacker who can supply a specially crafted file     to cause excessive memory consumption and potentially terminate the affected process due to an out-of-     memory condition. This issue is patched in version 0.4.1. As a workaround, avoid parsing attacker-     controlled user or group database files, or validate and limit untrusted input before parsing it.
    (CVE-2026-61801)

    When Trailer headers are sent by a client, the HTTP server internally uses the header values to populate     the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs     memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a Trailer header     that declares a large number of fields causing the server to allocate a disproportionate amount of memory     while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits.This exploit is not applicable     for HTTP/1 servers, which do not support  multiplexing a large number of requests over one TCP connection,     and whose Server.MaxHeaderBytes are calculated differently.Server.MaxHeaderValueCount and     Server.MaxHeaderBytes limits are now applied towards the trailer fields declared in Trailer headers.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81857NOTE: Fixed by:
    https://github.com/golang/go/commit/cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78659)

    Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious     peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an     atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every     packet other than the open confirmation/failure, without blocking and without tearing down the connection.
    (CVE-2026-78662)

    The HTTP/2 server could refund connection-level flow control twice for the same data: Once when a client     resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request     handler reads the buffered data.A malicious client could exploit this to bypass the configured connection-     level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the     concurrent stream limit and stream-level flow control.The HTTP/2 server now waits to refund connection-     level flow control for reset streams until after the request handler is complete.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81743NOTE: Fixed by:
    https://github.com/golang/go/commit/31dc9e2449e394439498142451627af52626d7c4 (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78663)

    OpenTelemetry-Go is the Go implementation of OpenTelemetry. From version 1.5.0 to 1.44.0,     sdk/trace.NewTracerProvider emits a TracerProvider created internal Info-level diagnostic event whose     MarshalLog implementations recursively include span processor, exporter, and client configuration.
    Applications that call otel.SetLogger to enable OpenTelemetry internal Info logging can therefore record     OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. A     person or system with access to those logs can learn internal collector topology and can recover     credentials or tokens embedded in Zipkin URL user information or query strings. The default OpenTelemetry     logger does not emit the event, and this path does not log OTLP authentication headers, TLS key material,     or span payloads. This issue is fixed in version 1.45.0. (CVE-2026-81870)

    containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI     CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from     checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a     container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and     seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters     while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are     not affected. This issue is fixed in versions 2.2.7 and 2.3.4. (CVE-2026-95837)

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 version of containerd installed on the remote host is prior to 2.3.7-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2ECS-2026-145 advisory.

    containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1,     a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start),     causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36,     2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue. (CVE-2026-53493)

    Previously, after a channel has been established, a malicious peer could send crafted messages that would     deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled     explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of     buffering and blocking. (CVE-2026-56855)

    The `github.com/moby/sys/user` package provides Go utilities for parsing and looking up entries in Unix-     style user and group database files. Versions before 0.4.1 do not sufficiently limit entries when parsing     `/etc/passwd`- or `/etc/group`-style files, allowing an attacker who can supply a specially crafted file     to cause excessive memory consumption and potentially terminate the affected process due to an out-of-     memory condition. This issue is patched in version 0.4.1. As a workaround, avoid parsing attacker-     controlled user or group database files, or validate and limit untrusted input before parsing it.
    (CVE-2026-61801)

    Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious     peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an     atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every     packet other than the open confirmation/failure, without blocking and without tearing down the connection.
    (CVE-2026-78662)

    The HTTP/2 server could refund connection-level flow control twice for the same data: Once when a client     resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request     handler reads the buffered data.A malicious client could exploit this to bypass the configured connection-     level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the     concurrent stream limit and stream-level flow control.The HTTP/2 server now waits to refund connection-     level flow control for reset streams until after the request handler is complete.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81743NOTE: Fixed by:
    https://github.com/golang/go/commit/31dc9e2449e394439498142451627af52626d7c4 (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78663)

    OpenTelemetry-Go is the Go implementation of OpenTelemetry. From version 1.5.0 to 1.44.0,     sdk/trace.NewTracerProvider emits a TracerProvider created internal Info-level diagnostic event whose     MarshalLog implementations recursively include span processor, exporter, and client configuration.
    Applications that call otel.SetLogger to enable OpenTelemetry internal Info logging can therefore record     OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. A     person or system with access to those logs can learn internal collector topology and can recover     credentials or tokens embedded in Zipkin URL user information or query strings. The default OpenTelemetry     logger does not emit the event, and this path does not log OTLP authentication headers, TLS key material,     or span payloads. This issue is fixed in version 1.45.0. (CVE-2026-81870)

    containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI     CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from     checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a     container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and     seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters     while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are     not affected. This issue is fixed in versions 2.2.7 and 2.3.4. (CVE-2026-95837)

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 version of containerd installed on the remote host is prior to 2.3.7-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2NITRO-ENCLAVES-2026-125 advisory.

    containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1,     a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start),     causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36,     2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue. (CVE-2026-53493)

    Previously, after a channel has been established, a malicious peer could send crafted messages that would     deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled     explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of     buffering and blocking. (CVE-2026-56855)

    The `github.com/moby/sys/user` package provides Go utilities for parsing and looking up entries in Unix-     style user and group database files. Versions before 0.4.1 do not sufficiently limit entries when parsing     `/etc/passwd`- or `/etc/group`-style files, allowing an attacker who can supply a specially crafted file     to cause excessive memory consumption and potentially terminate the affected process due to an out-of-     memory condition. This issue is patched in version 0.4.1. As a workaround, avoid parsing attacker-     controlled user or group database files, or validate and limit untrusted input before parsing it.
    (CVE-2026-61801)

    When Trailer headers are sent by a client, the HTTP server internally uses the header values to populate     the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs     memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a Trailer header     that declares a large number of fields causing the server to allocate a disproportionate amount of memory     while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits.This exploit is not applicable     for HTTP/1 servers, which do not support  multiplexing a large number of requests over one TCP connection,     and whose Server.MaxHeaderBytes are calculated differently.Server.MaxHeaderValueCount and     Server.MaxHeaderBytes limits are now applied towards the trailer fields declared in Trailer headers.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81857NOTE: Fixed by:
    https://github.com/golang/go/commit/cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78659)

    Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious     peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an     atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every     packet other than the open confirmation/failure, without blocking and without tearing down the connection.
    (CVE-2026-78662)

    The HTTP/2 server could refund connection-level flow control twice for the same data: Once when a client     resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request     handler reads the buffered data.A malicious client could exploit this to bypass the configured connection-     level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the     concurrent stream limit and stream-level flow control.The HTTP/2 server now waits to refund connection-     level flow control for reset streams until after the request handler is complete.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81743NOTE: Fixed by:
    https://github.com/golang/go/commit/31dc9e2449e394439498142451627af52626d7c4 (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78663)

    OpenTelemetry-Go is the Go implementation of OpenTelemetry. From version 1.5.0 to 1.44.0,     sdk/trace.NewTracerProvider emits a TracerProvider created internal Info-level diagnostic event whose     MarshalLog implementations recursively include span processor, exporter, and client configuration.
    Applications that call otel.SetLogger to enable OpenTelemetry internal Info logging can therefore record     OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. A     person or system with access to those logs can learn internal collector topology and can recover     credentials or tokens embedded in Zipkin URL user information or query strings. The default OpenTelemetry     logger does not emit the event, and this path does not log OTLP authentication headers, TLS key material,     or span payloads. This issue is fixed in version 1.45.0. (CVE-2026-81870)

    containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI     CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from     checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a     container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and     seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters     while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are     not affected. This issue is fixed in versions 2.2.7 and 2.3.4. (CVE-2026-95837)

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 version of containerd installed on the remote host is prior to 2.3.7-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2DOCKER-2026-153 advisory.

    containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1,     a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start),     causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36,     2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue. (CVE-2026-53493)

    Previously, after a channel has been established, a malicious peer could send crafted messages that would     deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled     explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of     buffering and blocking. (CVE-2026-56855)

    The `github.com/moby/sys/user` package provides Go utilities for parsing and looking up entries in Unix-     style user and group database files. Versions before 0.4.1 do not sufficiently limit entries when parsing     `/etc/passwd`- or `/etc/group`-style files, allowing an attacker who can supply a specially crafted file     to cause excessive memory consumption and potentially terminate the affected process due to an out-of-     memory condition. This issue is patched in version 0.4.1. As a workaround, avoid parsing attacker-     controlled user or group database files, or validate and limit untrusted input before parsing it.
    (CVE-2026-61801)

    When Trailer headers are sent by a client, the HTTP server internally uses the header values to populate     the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs     memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a Trailer header     that declares a large number of fields causing the server to allocate a disproportionate amount of memory     while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits.This exploit is not applicable     for HTTP/1 servers, which do not support  multiplexing a large number of requests over one TCP connection,     and whose Server.MaxHeaderBytes are calculated differently.Server.MaxHeaderValueCount and     Server.MaxHeaderBytes limits are now applied towards the trailer fields declared in Trailer headers.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81857NOTE: Fixed by:
    https://github.com/golang/go/commit/cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78659)

    Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious     peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an     atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every     packet other than the open confirmation/failure, without blocking and without tearing down the connection.
    (CVE-2026-78662)

    The HTTP/2 server could refund connection-level flow control twice for the same data: Once when a client     resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request     handler reads the buffered data.A malicious client could exploit this to bypass the configured connection-     level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the     concurrent stream limit and stream-level flow control.The HTTP/2 server now waits to refund connection-     level flow control for reset streams until after the request handler is complete.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81743NOTE: Fixed by:
    https://github.com/golang/go/commit/31dc9e2449e394439498142451627af52626d7c4 (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78663)

    OpenTelemetry-Go is the Go implementation of OpenTelemetry. From version 1.5.0 to 1.44.0,     sdk/trace.NewTracerProvider emits a TracerProvider created internal Info-level diagnostic event whose     MarshalLog implementations recursively include span processor, exporter, and client configuration.
    Applications that call otel.SetLogger to enable OpenTelemetry internal Info logging can therefore record     OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. A     person or system with access to those logs can learn internal collector topology and can recover     credentials or tokens embedded in Zipkin URL user information or query strings. The default OpenTelemetry     logger does not emit the event, and this path does not log OTLP authentication headers, TLS key material,     or span payloads. This issue is fixed in version 1.45.0. (CVE-2026-81870)

    containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI     CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from     checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a     container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and     seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters     while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are     not affected. This issue is fixed in versions 2.2.7 and 2.3.4. (CVE-2026-95837)

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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1,
    a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start),
    causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36,
    2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue. (CVE-2026-53493)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1,     a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start),     causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36,     2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue. (CVE-2026-53493)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
376553	Unity Linux 20.1060e Security Update: containerd (UTSA-2026-150510)	Nessus	Unity Linux Local Security Checks	Local	medium
375635	Photon OS 5.0: Containerd PHSA-2026-5.0-92-1025	Nessus	PhotonOS Local Security Checks	Local	medium
373595	SUSE SLES12 Security Update : containerd (SUSE-SU-2026:4923-1)	Nessus	SuSE Local Security Checks	Local	medium
371911	Amazon Linux 2023 : containerd, containerd-stress (ALAS2023-2026-3273)	Nessus	Amazon Linux Local Security Checks	Local	medium
371879	Amazon Linux 2 : containerd (ALASECS-2026-145)	Nessus	Amazon Linux Local Security Checks	Local	medium
371811	Amazon Linux 2 : containerd (ALASNITRO-ENCLAVES-2026-125)	Nessus	Amazon Linux Local Security Checks	Local	medium
371807	Amazon Linux 2 : containerd (ALASDOCKER-2026-153)	Nessus	Amazon Linux Local Security Checks	Local	medium
457836	Echo: multiple github.com/containerd/containerd packages: security update to 1.7.36	Tenable Cloud Security	Echo Local Security Checks	Local	medium
457836	Echo: multiple github.com/containerd/containerd packages: security update to 1.7.36	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	medium
350554	Linux Distros Unpatched Vulnerability : CVE-2026-53493	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-53493

medium

Tenable Plugins

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium