TeamCity CVE-2026-63077 修復：2026 企業緊急升級指南

官方已確認，CVE-2026-63077 影響 TeamCity On-Premises，未修復伺服器存在主動利用及嘗試利用。TeamCity Cloud 的修復由服務方處理，使用者不需要執行相同的伺服器升級。受影響範圍與緩解方式應以官方安全公告為準。

第一個決策不是立刻重啟，而是先縮小攻擊面，並保存之後可能需要的證據：

• 限制 TeamCity 管理端及相關服務的公網存取，只保留必要的管理來源。
• 暫停高權限帳戶變更、外掛安裝、Agent 授權及非必要的伺服器設定修改。
• 暫停生產簽名任務，尤其是會使用 Apple Developer 憑證、簽名 Keychain 或發布金鑰的工作。
• 保留伺服器日誌、稽核記錄、Agent 清單、建置記錄、佇列狀態及近期制品資訊。
• 將 TeamCity 伺服器、Mac Build Agent、工作區、簽名節點和下游制品分開標記，不要把它們視為同一個故障域。

這裡必須區分「修復漏洞」與「證明沒有入侵」。補丁能阻止後續利用，但不能替漏洞窗口內已發生的管理操作、憑證讀取或可疑建置背書。

提醒： 未知 Agent 或異常日誌是調查線索，不是單獨的入侵證據；但在簽名環境中，無法解釋的線索足以觸發隔離和暫停發布。

官方確認 2025.11.7 與 2026.1.3 已包含此漏洞修復；若現有版本無法立即升級，可採用官方安全補丁插件，同時維持網路隔離。這些版本與緩解方式應直接對照TeamCity 官方安全更新說明，不要以社群文章推測可用版本。

選擇路徑時，平台團隊應先回答四個問題：

1. 現行 TeamCity 版本是否能直接進入已修復的同分支版本？
2. 授權模式與維護政策是否允許目標版本或安全補丁插件？
3. 停機窗口是否足以完成資料庫、Data Directory、設定和回退驗證？
4. 目前使用的外掛、Java、資料庫驅動及 Agent 是否具備跨版本條件？

TeamCity 2026.2 已於 2026 年 9 月 1 日發布，但這不代表所有環境都應直接跨版本升級；應先核對2026.2 發布說明與現行 Upgrade Notes。若升級路徑涉及 Java 21，還要依 TeamCity 對 Java 21 的支援條件核對執行環境。

備份不應只寫成「已備份資料庫」。至少要確認下列項目各自的保存位置、時間點、還原方式和責任人：

• TeamCity 資料庫及可獨立還原的測試副本。
• Data Directory、伺服器設定、外掛清單與必要的建置記錄。
• 版本控制連線、制品庫連線和部署整合所需的設定，但不要把明文秘密複製到一般工作文件。
• 目前 Agent 名稱、授權狀態、serverUrl、能力標籤和生產路由。
• 漏洞窗口內的建置制品、雜湊或來源追蹤記錄，供後續重新核對。

普通資料庫備份不必然涵蓋 Data Directory、外部秘密管理系統或 Mac 主機上的簽名 Keychain，因此備份驗收必須以「能否重建及追溯」為標準，而不是只看備份工作是否顯示成功。

維護窗口內應按「停服、確認備份、安裝修復、啟動檢查、版本核驗」推進，而不是直接在生產伺服器上反覆嘗試升級。官方的伺服器與 Agent 升級文件應作為現場流程的基準。

完成啟動後，先驗證管理端與安全狀態，再逐步恢復建置：

• 確認顯示的伺服器版本或安全補丁狀態符合選定路徑。
• 驗證管理員登入、權限變更記錄和必要的 VCS 連線。
• 檢查建置佇列是否能正常停留、取消和重新排程。
• 確認外掛載入結果，特別是會接觸憑證、制品或遠端命令的外掛。
• 檢查隔離或離線環境是否會阻斷補丁驗證、更新下載或 Agent 升級。
• 不要因為管理端可登入，就直接恢復簽名發布。

若使用跨版本升級，Java、資料庫驅動、外掛與 Agent 相容性需要分開驗證。升級文件也應用來核對 Agent 自動升級條件；不可把伺服器已啟動誤判為所有 Agent 都已完成安全更新。

伺服器恢復後，Mac Agent 不應一次全部重新接回生產路由。先停用生產建置分派，再按節點身份逐台檢查：

• 核對 Agent 名稱、主機身份、授權狀態與 serverUrl。
• 對照既有資產清單，標記新出現、名稱相似或來源不明的 Agent。
• 確認自動升級結果及 Agent 回報的版本狀態。
• 在未授權簽名的測試工作中驗證 Xcode、依賴、工作區清理與輸出檔案。
• 確認 Agent 自動升級期間沒有被強制重啟；相關行為應依官方 Agent 升級文件安排。
• 未知或來源不明的節點保持隔離，不得因為顯示在線就重新授權。

Agent 狀態與授權判斷可對照官方 Agent REST 文件。對於 Mac 節點的啟動與連線方式，則應以macOS Agent 文件核對，不要只依靠歷史腳本判斷節點已完成恢復。

憑證與調查範圍

修復後首日的調查，應建立一張能對應時間線的表格，而不是只搜尋一個錯誤字串。需要把以下事件放在漏洞窗口、補丁安裝和重新啟動時間旁邊比對：

• 管理員登入、權限變更、Token 建立與撤銷。
• Agent 授權、離線、重新連線和能力變更。
• 外掛安裝、設定修改、VCS 連線異常及制品下載。
• 建置工作區中不符合預期的腳本、輸出或依賴變更。
• 未知 Agent 與現有 Mac 節點在名稱、主機身份及連線來源上的差異。

憑證輪換應按責任域執行：VCS、制品庫、雲端帳戶、部署金鑰、Apple Developer 憑證和簽名 Keychain 不應由同一張「重設密碼」工單代替。漏洞窗口內產生的制品也要重新確認來源、建置記錄與完整性；若無法建立可信鏈路，應標記為不可發布並重新建置。

TeamCity CVE-2026-63077 應該升級到哪個版本？

官方確認 2025.11.7 與 2026.1.3 已包含修復；若考慮升至 2026.2，仍須依現有版本、Java、資料庫與外掛條件核對升級說明。無法立即升級時，先採用官方安全補丁及網路隔離措施。

安裝 TeamCity 安全補丁後還要檢查什麼？

補丁只代表已套用修復，不代表環境沒有被利用。管理者仍要保全伺服器與建置記錄、檢查異常日誌和未知 Agent、確認高權限變更，並在恢復簽名工作前完成相關 CI/CD 憑證輪換。

如何判斷 TeamCity 伺服器是否已經被利用？

單一異常日誌或未知 Agent 只能作為調查線索，不能獨立證明入侵。應把管理操作、Agent 授權、外掛、VCS、制品與建置記錄放在同一時間線比對，再由安全團隊判定是否需要重建伺服器與節點。

漏洞修復後 Mac Build Agent 如何安全恢復？

先停用生產路由，逐台核對 Agent 名稱、主機身份、授權狀態、serverUrl 與自動升級結果；未知或來源不明的節點不得重新授權。通過無簽名測試流水線後，再於乾淨節點驗證完整建置流程。

TeamCity 被攻擊後需要輪換哪些 CI/CD 憑證？

至少按 VCS、制品庫、雲端帳戶、部署金鑰、Apple Developer 憑證及簽名 Keychain 分工盤點。漏洞窗口內產生的制品也要重新核對來源與完整性，避免只換密碼卻把可疑建置結果送回發布鏈路。

恢復生產前，應先準備一個隔離的乾淨 Mac 節點，重建最小可用的 iOS CI/CD 環境。測試不應只執行「Agent 上線」這一項，而要依序完成：

• 拉取指定版本的程式碼。
• 還原已鎖定的依賴。
• 執行建置與測試。
• 產生歸檔檔案並核對輸出。
• 在受控條件下執行簽名。
• 將建置結果、日誌和來源提交至可追溯位置。

舊節點與乾淨節點的差異，會決定舊環境應重裝、繼續取證還是直接退役。若團隊缺少備用節點，可先閱讀NUKCLOUD 的遠端 Mac 使用說明，把短期隔離環境的連線、權限和重置條件納入 PoC 驗收，而不是在正式節點上直接做破壞性測試。

時間線決策表

憑證輪換責任表

生產放量門檻表

如果目前方案是把多個 Mac Agent 長期放在同一個未隔離的 TeamCity 環境中，主要缺點通常是節點身份難以追溯、備用容量不足，以及一旦簽名憑證與工作區同時受到懷疑，恢復會被單一主機綁住。對缺少備用實機的團隊，短期租用 NUKCLOUD 的遠端 Mac，可把乾淨 Agent 重建、關鍵流水線重跑和舊節點取證分開進行；這不取代長期穩定負載所需的自有基礎設施，但在應急隔離與 PoC 驗收階段，通常比直接改動唯一的生產 Mac 更容易保留回退路徑。

需要準備隔離環境時，可先從NUKCLOUD 的遠端 Mac 方案入口確認可用方式，再依團隊的網路、權限和簽名政策安排測試。最後的恢復決策應以五項結論為準：伺服器已修復、憑證已輪換、制品可追溯、Agent 可恢復，以及故障可回退。

最後更新於 2026 年 9 月 6 日；版本、主動利用狀態與修復條件核實自 TeamCity 官方安全公告、升級文件及 2026.2 發布說明。