在容器化技術（Containerization）持續演進的今天，Docker Engine 的每一次小版號更新往往藏著關鍵的資安細節。Docker 官方於近期釋出了 v29.1.2 版本，雖然表面上看似例行維護，但從資安角度與 DevOps 實務面來看，這次更新修補了底層 Go 語言運行時（Go Runtime）的嚴重漏洞，並解決了 Rootless 模式下長期困擾使用者的網路問題。
對於正運行關鍵任務（Mission-critical）的企業環境，這次的更新建議列為「優先評估」等級。
資安緊急修補（Go Runtime 升級）
本次更新最核心的驅動力在於底層的安全性。Docker 29.1.2 將內建的 Go 語言運行時升級至 1.25.5 版本。這並非單純的效能提升，而是為了修補上游 Go 語言庫中被發現的兩個高風險 CVE 漏洞。
CyberQ 建議關注一下這兩個被修補的弱點：
CVE-2025-61729（DoS 阻斷服務風險）： 這是一個針對資源消耗的漏洞。當系統在格式化主機名稱（Hostname）驗證錯誤時，舊版的 Go 運行時可能會消耗過多的資源。攻擊者可能利用特製的輸入，誘發系統耗盡 CPU 或記憶體，導致 Docker Daemon 失去回應。這對於提供公開 API 或處理不受信任輸入的容器平台來說，是一個不容忽視的風險。
CVE-2025-61727（憑證驗證繞過風險）： 此漏洞涉及 SSL/TLS 憑證的安全性。在舊版本中，針對萬用字元（Wildcard SANs）的子網域排除限制（Excluded Subdomain Constraints）執行不正確。簡單來說，這可能允許攻擊者利用一張本應被限制的憑證，成功騙過系統的信任機制。對於依賴 mTLS 或嚴格憑證驗證的微服務架構，這是一個潛在的信任鏈破口。
CyberQ 觀察，「軟體供應鏈安全」是在維運中很重要的，Docker 本身邏輯 ok，但若底層依賴的語言環境（Go）出問題，上層應用同樣遭殃。升級至 29.1.2 是防堵這些底層漏洞的最快路徑。
CyberQ 機器已經更新為 29.1.2 的實例
Rootless 模式與網路修復
在社群（GitHub 與 Reddit）中，關於 Docker Rootless（非 root 權限執行）模式的討論熱度一直很高。雖然 Rootless 提供了更好的隔離性與安全性，但在網路配置上常讓開發者「踩雷」。
v29.1.2 針對此領域做出了關鍵修正：
修復 Rootless 模式下的 Port Mappings： 先前版本在使用 slirp4netns（一種使用者空間網路堆疊）時，特定情境下會導致 Port Mapping 失效，導致容器服務無法對外連線。這次更新解決了此 Bug，讓 Rootless 模式的網路穩定性大幅提升。 相關 Issue：moby/moby#51616
API 請求崩潰修復： 修復了一個相當尷尬的 Bug：當使用者透過 API 請求使用 HostConfig.PublishAllPorts（即 -P 參數）但卻沒有設定任何連接埠綁定（Port Bindings）時，會導致 Daemon 崩潰。這類穩定性修復對於自動化 CI/CD 流程至關重要。
其他重要更新與建議
Containerd Image Store 修正： 解決了 docker image inspect 在某些分散式 blob 未完全下載到本地時，無法回傳可用映像檔數據的問題。這對於正在從傳統 Docker 儲存驅動遷移到 containerd store 的使用者來說，是一個重要的穩定性補強。
Runc 升級： 內建的 runc（負責生成和運行容器的 CLI 工具）更新至 v1.3.4，進一步提升了容器生成的穩定性。
社群觀點與升級建議
綜合 GitHub Issue 追蹤與社群論壇的反饋，目前社群對於 v29 系列的改動仍持「謹慎觀望」態度。v29 引入的部分 API 變動曾讓部分舊有工具出現相容性問題，但 v29.1.2 這類「Patch Release」通常被視為救火隊，受到廣泛歡迎。
給開發者與維運團隊的建議：
資安優先者： 由於涉及 Go Runtime 的 CVE 修補，若你的 Docker 主機直接暴露於網際網路或處理外部不受信任的憑證，建議立即安排升級。
Rootless 使用者： 如果你曾在 Rootless 模式下遇到網路通訊不明原因中斷，此版本有機會能解決你的問題。
一般使用者： 此次更新主要集中在 Bug Fix 與資安更新，未引入破壞性的功能變動（Breaking Changes），升級風險相對較低。
CyberQ 觀察，Docker 29.1.2 是一個典型的「防禦性更新」，在資安威脅日益自動化的今天，保持基礎設施的最新狀態，永遠是成本最低的防禦策略。
