AI 安全
OpenMAIC 1.0.2 修補 DNS 重綁與雲端中繼資料 SSRF，並封鎖課堂覆寫
OpenMAIC 的媒體代理曾在驗證網域後重新解析 DNS，使外部名稱可在連線時轉向內網；另一條路徑則會放行阿里雲中繼資料位址。1.0.2 改以固定解析結果連線並由伺服器產生課堂 ID，但也會影響透過 Tailscale 等 CGNAT 網段存取本地模型的部署。
開源多代理教學平台 OpenMAIC 於 9 月 14 日發布 1.0.2，修補三個可由網路請求觸發的問題。最關鍵的兩項都位於 `/api/proxy-media` 及共用外連 URL 防線：其一是拒絕清單套用順序錯誤，讓阿里雲執行個體中繼資料位址 `100.100.100.200` 以 IP literal 通過；其二是典型的 DNS 重綁——程式先解析並驗證主機名稱，真正執行 `fetch()` 時卻再次解析，攻擊者可在兩次查詢間把答案由公網 IP 改成內網位址。[官方變更紀錄](https://github.com/THU-MAIC/OpenMAIC/blob/main/CHANGELOG.md)顯示，新版會先檢查中繼資料、映射及轉換編碼，再透過共用 pinned dispatcher，只連向防線實際驗證過的位址；重新導向的每一跳也採同樣規則。
第三個漏洞出現在 `POST /api/classroom`。呼叫者原本可指定課堂 ID，暫存檔重新命名時可能覆蓋既有課堂內容。1.0.2 改由伺服器產生 ID、以排他方式建立檔案，碰撞時有限次重試後回傳 HTTP 409。這不只是一般網頁漏洞：OpenMAIC 會代表使用者呼叫模型、搜尋與媒體服務，自架實例通常持有供應商金鑰；若 SSRF 抵達雲端中繼資料服務，可能進一步取得工作負載憑證。
升級也帶來相容性變更。客戶端提供的 `stage.id` 將被忽略；`100.64.0.0/10` CGNAT 預設封鎖，經 Tailscale 等覆疊網路連向本地模型或媒體主機者，可能必須明確設定 `ALLOW_LOCAL_NETWORKS=true`。部分 IANA 保留、文件、廣播與多播網段則無條件拒絕。維運者應升級後重新測試內部模型端點、重新導向鏈與 API 客戶端，並確認開放本地網路不會重新擴大代理的 SSRF 攻擊面。