遠端主機上安裝的 containerd 版本為早於 2.3.7-1 的版本。因此，會受到 ALAS2DOCKER-2026-153 公告中所提及的多個弱點影響。

    containerd 是一種開放原始碼的容器執行階段。在 、 2.0.13、 2.2.92.3.62.4.1和 版本之前，1.7.36特製的 OCI 索引圖形可能會在 PullImage 期間 （在容器啟動之前） 強制使用非常高的 CPU/記憶體，導致長時間的 ContainerCreating 停止，並在較大的大小下導致節點/執行階段不穩定。版本 1.7.36、 2.0.13、 2.2.92.3.6，並2.4.1修正問題。（CVE-2026-53493）

    以前，建立通道之後，惡意對等可能會傳送特製的訊息，使整個連線鎖死。現在，我們處理所有 RFC 4254 通道訊息;全域要求會明確處理。然後，將所有其他訊息視為通訊協定錯誤，並中斷連線，而不是緩衝和封鎖。（CVE-2026-56855）

    「github.com/moby/sys/user」套件提供了 Go 實用程式，用於剖析和查詢 Unix 風格的使用者和群組資料庫檔案中的條目。之前 0.4.1 的版本在剖析「/etc/passwd」或「/etc/group」樣式檔案時沒有充分限制項目，因此能夠提供特製檔案的攻擊者可以造成過多的記憶體消耗，並可能因記憶體不足而終止受影響的處理程序。此問題已在 0.4.1 版中修補。因應措施是避免剖析攻擊者控制的使用者或群組資料庫檔案，或在剖析之前驗證並限制不受信任的輸入。
    (CVE-2026-61801)

    當用戶端傳送 Trailer 標頭時，HTTP 伺服器會在內部使用標頭值來填入傳遞至伺服器處理常式的 Request.Trailer 對應。因為 Request.Trailer 是對應，所以每個專案都會產生記憶體額外負荷。針對 HTTP/2 伺服器，惡意用戶端可以藉由傳送宣告大量欄位的 Trailer 標頭來利用此弱點，導致伺服器配置不成比例的記憶體量，同時繞過 Server.MaxHeaderValueCount 和 Server.MaxHeaderBytes 限制。此漏洞不適用於 HTTP/1 伺服器，這些伺服器不支援透過一個 TCP 連線多工處理大量要求，並且其 Server.MaxHeaderBytes 的計算方式不同。Server.MaxHeaderValueCount 和 Server.MaxHeaderBytes 限制現在會套用至預告片標頭中宣告的預告片欄位。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81857NOTE: 已修正：
    https://github.com/golang/go/commit/cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b （go1.27.2）注意：修正者：
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 （go1.26.9） （CVE-2026-78659）

    以前，在多路復用器的 chanList 中註冊的通道在建立之前無法使用。惡意對等體能夠淹沒通道的 incomingRequests，使整個連線鎖死。現在，我們新增一個原子建立狀態，當通道可用時設定。在此之前，handlePacket 會捨棄開啟確認/失敗以外的每個封包，而不會封鎖且不會中斷連線。
    (CVE-2026-78662)

    HTTP/2 伺服器可以針對相同的資料退還連線層級流量控制兩次：一次是在用戶端重設資料流時 （為資料流的任何已傳送但未讀取部分退還資料），另一次是在要求處理常式讀取緩衝資料時。惡意用戶端可能會利用此弱點來繞過設定的連線層級流量控制限制 （MaxReceiveBufferPerConnection） 。緩衝資料總數仍受到並行資料流程限制和資料流程層級流量控制的限制。HTTP/2 伺服器現在會等待退還重設資料流的連線層級流量控制，直到要求處理常式完成為止。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81743NOTE: 已修正：
    https://github.com/golang/go/commit/31dc9e2449e394439498142451627af52626d7c4 （go1.27.2）注意：修正者：
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 （go1.26.9） （CVE-2026-78663）

    OpenTelemetry-Go 是 OpenTelemetry 的 Go 實作。從版本 1.5.0 到 1.44.0， sdk/trace。NewTracerProvider 會發出 TracerProvider 建立的內部資訊層級診斷事件，其 MarshalLog 實作會以遞迴方式包含範圍處理器、匯出程式和用戶端設定。
    呼叫 otel 的應用程式。因此，啟用 OpenTelemetry 內部資訊記錄的 SetLogger 可以記錄 OTLP gRPC 和 HTTP 收集器端點、OTLP HTTP 不安全旗標，以及完整的 Zipkin 收集器 URL。有權存取這些記錄的人員或系統可以瞭解內部收集器拓撲，並可以復原內嵌在 Zipkin URL 使用者資訊或查詢字串中的認證或權杖。預設的 OpenTelemetry 記錄器不會發出事件，而且此路徑不會記錄 OTLP 驗證標頭、TLS 金鑰資料或跨度承載。1.45.0 版已修正此問題。(CVE-2026-81870)

    containerd 是一種開放原始碼的容器執行階段。從 2.1.0 until 2.2.7 和 2.3.4，containerd 的 CRI CreateContainer 檢查點還原容易受到攻擊，因為 CRIU 會從檢查點資料還原處理程序安全性狀態，而不是強制執行目的地 ContainerConfig。能夠從特製檢查點建立容器的攻擊者可以提供還原的憑證、功能、no_new_privs和 seccomp 狀態。還原的處理程序可以以具有完整功能且沒有強制 seccomp 篩選器的 root 身分執行，而 CRI 狀態會報告要求的組態。不使用 CRI 檢查點還原的系統不會受到影響。此問題已在 2.2.7 和 2.3.4 版中修正。(CVE-2026-95837)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

Amazon Linux 2 : containerd (ALASDOCKER-2026-153)

medium Nessus Plugin ID 371807

版本 1.1