Docker Engine 於 2026 年 10 月 14 日發佈 29.9.1 版本，將內建的 containerd 更新至 2.4.2，修補三個可導致守護程序崩潰或耗盡主機磁碟的漏洞。這個由 Docker 建立並維護的上游專案，在 GitHub 累積 72,202 顆星標與 19,238 次複製，主要語言為 Go，採用 Apache-2.0 授權，是絕大多數容器工作流的底層執行引擎。
Docker Engine 29.9.1 是什麼？
Docker Engine 29.9.1 於 2026 年 10 月 14 日發布，將 containerd 升至 2.4.2，修補三個可致守護程序崩潰或磁碟耗盡的漏洞。
這是一個維護性質的修補版本，並非功能更新。依官方發佈說明，29.9.1 的主要工作是跟進 containerd 社群在三項安全通告中的修正，同時處理七項回報於 issue tracker 的缺陷，涵蓋容器建立、映像輸出、日誌驅動與插件查詢等路徑。前一版 29.9.0 於 10 月 8 日推出，相隔不到一週即發佈補丁，反映 containerd 上游的修正已進入必須同步的階段。
對於以 Docker Engine 作為執行環境的伺服器、建置機與 CI 節點，這個版本屬於建議直接套用的類別。官方同時提醒，靜態二進位封裝中的 containerd 已一併更新，因此使用發行版套件安裝的使用者需要等待套件維護者重新打包，而以官方二進位或 Docker Desktop 安裝的使用者則可透過既有更新路徑取得。
Docker Engine 29.9.1 修補了哪些 containerd 漏洞？
共三項，包括惡意摘要導致守護程序崩潰、偽造 Content-Length 標頭在並行抓取時觸發崩潰，以及未限制圖層資料大小而耗盡主機磁碟。
第一項於公告中標示為 CVE-2026-95839，問題出在 containerd 的傳輸服務。當映像的子描述元帶有 io.containerd.manifest.subject 註解，同時摘要格式異常時，拉取或匯入映像的動作可能直接使 containerd 崩潰。第二項為 GHSA-8647-2jxj-p2rc，描述不受信任的 registry 若回傳刻意構造的 Content-Length 標頭，在啟用並行圖層抓取緩衝的情況下同樣會令守護程序終止。
第三項 GHSA-hc94-p972-ch66 的影響層面與前兩者不同。containerd 在驗證之前未限制傳入圖層的資料量，因此拉取刻意製作的映像或從惡意 registry 拉取時，可寫入超出宣告大小的資料，進而佔滿主機磁碟。三項通告在 containerd 的公告頁面中皆標示為中等嚴重程度，性質偏向阻斷服務與資源耗盡，而非遠端程式碼執行。官方在 29.9.1 中一併更新 Go 標準庫與 golang.org/x/net，處理另一批與 HTTP/2 相關的問題。
這些漏洞在實際部署中的風險有多大？
風險取決於是否從不受信任的 registry 拉取映像。僅使用內部或已驗證來源的環境衝擊有限，但多租戶建置與公開映像拉取的情境應盡快升級。
三項漏洞的共同前提是攻擊者能夠控制映像或 registry 的回應內容。若團隊的映像全部來自內部私有 registry，且該 registry 不對外開放，被觸發的機會相對有限。相反地，CI 流程若允許依賴檔中的映像位址指向公開來源、或建置環境會拉取未經審核的第三方映像，就落在主要受影響的範圍內，因為磁碟耗盡與程序崩潰都會直接中斷建置與部署流程。
從維運角度觀察，這類通告的成本主要不在修補本身，而在盤點。守護程序崩潰會造成容器短暫中斷，而磁碟寫滿的後果更難收拾，可能連帶影響同一主機上的日誌與資料庫寫入。較務實的做法是先確認主機上的 Docker Engine 版本，再依照安裝方式選擇更新來源，並在建置節點完成相同檢查。
Moby 這個專案在容器生態中扮演什麼角色？
Moby 建立於 2013 年，是 Docker Engine 的上游開源專案，提供模組化容器元件，採 Apache-2.0 授權，Docker 產品以此組裝。
Moby 專案建立於 2013 年 1 月，定位是提供一組可組合的容器元件，包括容器建置工具、registry、編排工具與執行環境，供開發者與整合者自行組裝成客製化的容器系統。專案本身明確表示並非終端使用者產品，而是面向工程師與整合者的上游程式碼庫，商業支援則由 Docker Desktop 與 Mirantis Container Runtime 等產品承擔。
在模組邊界上，專案於 Docker 29 系列啟動了一項結構調整。原本的 Go 模組 github.com/docker/docker 已標示為棄用並停止更新，官方改以 github.com/moby/moby/client 與 github.com/moby/moby/api 兩個模組作為對外介面，根模組則專供建置容器引擎使用，不保證作為函式庫的介面穩定性。這項調整對一般以命令列或 API 操作容器的工作流沒有影響，但會牽動將 Docker 作為 Go 依賴納入專案的開發者。
29.9 系列在功能上還帶來了哪些改變？
29.9.0 為 containerd 映像儲存加入延遲拉取功能，並修正多項網路與加密疊加網路的問題，同時更新 BuildKit 與 RootlessKit。
功能層面的主要新增集中在 29.9.0。該版本為 containerd 映像儲存加入名為 lazy-pull 的守護程序特性，用來控制 docker pull 是否略過快照器已提供的圖層內容，已知的遠端快照器包括 nydus、overlaybd、soci 與 stargz 皆預設啟用。同一版本亦修正了圖層被略過後映像雖可執行但匯出與推送不完整的問題，這是延遲拉取機制在上線初期需要關注的相容性細節。
網路層的修正數量較多。官方在 29.9.0 中處理了 IPv6 鄰居探索在容器間通訊關閉時的封包交換、使用路由閘道模式時連接埠未顯示、以及節點重新加入叢集後疊加網路對等節點失聯等狀況。其中一項修正涉及加密疊加網路：在核心程式設計發生錯誤的特定情況下，部分流量曾以明文傳送，官方說明受影響範圍限於單向流量與未完成握手的連線，並在該版本中一併修正 IPsec 安全關聯未釋放的問題。
工具鏈亦同步前移。29.9.0 將 BuildKit 更新至 v0.34.0、Go 執行環境更新至 1.26.9，並開始使用 containerd 2.4.1；29.9.1 再把 containerd 推至 2.4.2，並將無 root 模式的 RootlessKit 更新至 v3.3.0，同時修正 --domainname 在使用者命名空間下的行為，此修正需要 runc 1.2.0 以上版本配合。
Docker Engine 的專案規模與維護節奏如何？
儲存庫累積 72,202 顆星標、19,238 次複製與 2,339 位貢獻者，提交數約 5.85 萬次，Apache-2.0 授權，29.9 系列以每週節奏推出補丁。
維護節奏呈現「小步快跑」的特徵。29.9.0 於 10 月 8 日發佈，29.9.1 於 10 月 14 日推出，相隔六日；再往前推，29.8.0 於 9 月 3 日、29.8.1 於 9 月 15 日、29.8.2 於 9 月 30 日發佈。這種密度意味著版本號中的修訂層級多半只包含安全與缺陷修正，而能在生產環境中累積的實際差異集中在少數幾個功能版本。
專案的活躍程度亦可從提交與標籤數量觀察。儲存庫目前約有 5.85 萬次提交與 614 個標籤，未結議題約 3,939 項。除了 docker- 前綴的引擎版本外，專案另以 client/ 與 api/ 前綴發佈對應的模組版本，兩者的版號與引擎版本相互獨立。
Docker Engine 與其他容器執行環境相比如何？
Docker Engine 以完整工具鏈與龐大生態見長，containerd 更貼近核心執行環境，Podman 主打無常駐守護程序，選擇取決於既有工具與維運習慣。
比較的起點在於層級不同。Docker Engine 提供命令列、守護程序、映像建置與網路管理的一整套介面，採用 Apache-2.0 授權，並以 Moby 作為上游，優點是文件與第三方整合最完整。containerd 本身即為 Docker Engine 內部使用的執行環境，介面精簡、可被 Kubernetes 透過 CRI 直接呼叫，適合由編排系統統一管理的場景。
Podman 走的是另一條路線，以無常駐守護程序的方式執行容器，並提供與 Docker 命令列相近的操作習慣。選擇時較關鍵的因素通常不是效能差異，而是既有自動化腳本、映像建置流程與團隊對守護程序模型的需求。對已採用 Docker Compose 或大量依賴 Docker 命令列的專案而言，留在同一條上游可降低遷移成本；對以 Kubernetes 為核心、只需執行環境的部署，直接使用 containerd 可減少一層管理元件。
出處連結有哪些？
本文資訊整理自 Moby 專案的 GitHub 儲存庫與官方發佈說明，包含 29.9.1 與 29.9.0 的完整修正清單及 containerd 安全通告。
- Moby 專案儲存庫：https://github.com/moby/moby
- 29.9.1 發佈說明：https://github.com/moby/moby/releases/tag/docker-v29.9.1
- 29.9.0 發佈說明：https://github.com/moby/moby/releases/tag/docker-v29.9.0
- containerd 2.4.2 版本：https://github.com/containerd/containerd/releases/tag/v2.4.2
- Moby 專案官網：https://mobyproject.org/
總結：Docker Engine 29.9.1 適合哪些團隊升級？
適合所有以 Docker Engine 執行生產或建置工作負載的團隊，尤其是會拉取公開映像的 CI 環境；此次為安全修正版本，升級風險低於承擔漏洞風險。
29.9.1 的內容以安全與缺陷修正為主，沒有引入新的行為變更。對已在 29.9.0 上的環境，升級屬於例行維護；對停留在較早版本的環境，則需要在升級後確認映像儲存後端與網路模式的既有行為未受影響，特別是使用延遲拉取相關快照器或加密疊加網路的部署。
綜合而言，這次版本的重要性不在功能，而在於它把三個可能中斷服務的缺陷收斂在單一補丁中。對維運團隊而言，將版本盤點與更新納入既有的維護窗口，會比等待下一次功能版本更為實際，因為崩潰與磁碟耗盡都可以在毫無預警的情況下影響同一主機上的其他服務。
