Docker Desktop June 2026：CVE-2026-33990 SSRF 修補、Kubernetes 競態修復與 Qwen3.5 支援
Docker Release Notes · 2026-06-07
Docker Desktop 六月更新修復了 CVE-2026-33990——一個在 Docker Model Runner OCI Registry 客戶端的 SSRF（Server-Side Request Forgery）漏洞，同時修補 Kubernetes 啟動競態條件，並新增 Model Runner 對 Qwen3.5 的支援。Model Runner 需升級至 1.1.25 或更新版本才完整修補 CVE-2026-33990。
CVE-2026-33990：SSRF 漏洞機制
漏洞存在於 Docker Model Runner 的 OCI Registry token 交換流程：Model Runner 在處理 registry 的 WWW-Authenticate 標頭中的 realm URL 時，未驗證 URL 的 scheme、hostname 或 IP 範圍，直接跟隨重導向。攻擊者可藉由控制一個 OCI registry（或 man-in-the-middle），在 WWW-Authenticate 回應中植入指向內部服務的 realm URL，讓 Model Runner 對任意內部端點發送帶有認證 token 的請求，達成 SSRF。
修補版本 1.1.25 在 token 交換前驗證 realm URL 的 scheme 必須為 https 且 hostname 不在私有 IP 範圍（127.x.x.x、10.x.x.x、172.16.x.x–172.31.x.x、192.168.x.x）。此漏洞最初在 Docker Desktop 4.67.0（2026 年 3 月 30 日）中修補，六月更新確保 Model Runner standalone 元件也同步修補。
Kubernetes 競態條件修復
本次更新修復了 Kubernetes 在 Docker Desktop 中的啟動競態條件：當 Registry Access Management 政策在 Kubernetes 啟動過程中發生變更時，Kubernetes 可能啟動失敗。根因是 RAM 政策更新的監聽器與 Kubernetes 初始化序列之間缺少適當的同步，導致 kube-apiserver 在接收到 RAM 更新事件時意外中止初始化。修補後，Kubernetes 初始化序列在完成前會忽略 RAM 政策更新事件，由單獨的重啟流程處理後續政策同步。
Model Runner 更新
Qwen3.5 系列模型現在可透過 Docker Model Runner 直接拉取與執行，無需手動設定 GGUF 檔案路徑。新的 Logs (Beta) 視圖新增 Compose stack 篩選功能，讓多服務應用的容器日誌可以按 Compose 服務名稱過濾，不需要在大量容器日誌中手動搜尋。Enhanced Container Isolation（ECI）使用者可設定 Model Runner 的網路存取權限，限制僅允許必要外部 registry，作為 CVE-2026-33990 的額外縱深防禦。
Kubernetes v1.37 開發路線：Production Readiness Freeze 倒數計時
Kubernetes Contributors · 2026-06
Kubernetes v1.37 的發布時程進入關鍵階段：Production Readiness Freeze 定於 2026 年 6 月 10 日（UTC），Enhancements Freeze 為 6 月 17 日，KubeCon India 排在 6 月 18–19 日，最終發布預計 2026 年 8 月 26 日。這是 2026 年的第三個 Kubernetes 次要版本（1.35 於 2 月、1.36 於 5 月發布）。
關鍵里程碑
Kubernetes 1.37 開發週期的里程碑：
- 6 月 10 日：Production Readiness Review Freeze——所有 KEP 必須通過 PRR 審查，確認變更不影響叢集穩定性
- 6 月 17 日：Enhancements Freeze——確認納入本版本的 KEP 清單，後續不接受新功能提案
- 6 月 18–19 日：KubeCon India（北京時間）
- 8 月 26 日：預計最終發布
v1.36 近期功能回顧
為提供背景，v1.36 引入了工作負載感知排程（Workload-aware Scheduling）作為 Beta 功能——排程器在分配 Pod 時考量應用程式層面的服務等級目標（如延遲敏感型與批次工作負載的區分），而非純粹按資源可用性排程。此功能延伸了 1.35 的動態資源分配（DRA）能力，讓 GPU 密集工作負載可以請求特定硬體拓撲配置。
v1.37 的重點 KEP目前仍在審查中，已確認的方向包含：進一步穩定化 DRA API（Dynamic Resource Allocation）從 beta 到 stable、改善 Job API 的中斷處理語意，以及 InPlacePodVerticalScaling 的穩定化（允許不重啟 Pod 的資源請求調整）。
原始來源：Kubernetes Contributors Release Page、Kubernetes Releases