2026年9月6日時点で、JetBrainsは未修正のTeamCityサーバーについて、実際の悪用と悪用の試みを確認したと発表しています。公式セキュリティ更新に基づくと、未修正のTeamCity On-Premisesは直ちに外部公開を制限し、サポート対象の修正版または公式のセキュリティパッチを適用する必要があります。
判断ボックス：適している対応
隔離 → 修復 → 調査 → 再構築の順で進める対応が適しています。パッチのインストール完了だけでは環境が侵害されていない証拠にならないため、疑わしいログや未知のAgentがあれば、署名リリースを停止し、クリーンなMac環境で認証情報と本番パイプラインを検証してから復旧してください。
この手順を読む対象者
TeamCity管理者は、重要な配信を止める範囲を抑えながらサーバーを修復したい場合に利用できます。
iOS CI/CD責任者は、Mac Agent、署名用Keychain、既存のビルド成果物を信頼できる状態か判断する際に役立ちます。
セキュリティ担当者と技術管理者は、隔離、調査、復旧、再放流の判断をチーム間でそろえられます。
00初動の封じ込め
TeamCity Cloudは利用者側でこの修復作業を実施する対象ではありません。一方、TeamCity On-Premisesは、外部から到達できる経路、管理者権限を持つ利用者、接続済みのVCSや成果物保管先を自社で確認する必要があります。公式の脆弱性告知では、影響と緩和策が説明されています。
最初に実施する操作は、パッチの導入そのものではありません。次の順序で、攻撃者が追加操作を行える経路と、署名済みアプリが配信される経路を止めます。
- TeamCityサーバーの管理画面を外部公開しない経路へ切り替える
- ファイアウォール、ロードバランサー、VPNなどのアクセス制御を記録する
- 管理者権限の付与、プラグイン変更、ビルド設定変更を一時停止する
- 本番署名、アプリ配信、デプロイを一時停止する
- サーバーログ、監査ログ、プロキシログ、認証ログを上書きしない形で保全する
- 登録済みAgentの一覧と、現在稼働中のビルドを記録する
TeamCityサーバーが悪用された可能性をどのように判断するか
単一のエラーや見慣れないログだけで侵害を断定してはいけません。公式告知に記載された調査上の手掛かりと、自社の管理者操作、Agent登録、VCS接続、成果物生成の時刻を照合し、複数の記録が同じ時間帯と経路を示すかを確認します。
特に、身元を説明できないAgent、予定外の管理者変更、通常と異なるVCS接続、署名処理と一致しないビルド実行があれば、調査対象として隔離します。ログ異常はあくまで調査の起点であり、それだけで侵害の確定証拠にはなりません。
01修復経路の選択
修復先は、現在のTeamCityバージョン、利用中のライセンス、停止可能な保守時間、プラグインとデータベースの互換性を確認して決めます。確認できないまま最新版へ直接移行すると、脆弱性対応と互換性障害が同時に発生します。
| 判断項目 | 選択肢 | 確認する内容 |
|---|---|---|
| 既存バージョンが対応範囲内 | 同一系統の修正版へ更新 | 現行プラグイン、データベース、Javaの適合性 |
| すぐに計画アップグレードできない | 公式セキュリティパッチプラグイン | 適用条件、適用後の状態、正式更新までの期限 |
| 大きなバージョン移行を行う | 2026.2を含む更新経路 | Upgrade Notes、Java、データベースドライバー、プラグイン |
| 本番サーバーを信頼できない | 別の検証サーバーで再構築 | バックアップの完全性、設定の持ち込み範囲、証跡 |
修正を含むバージョンとして、公式更新では2025.11.7と2026.1.3が示されています。公式セキュリティ更新に従い、実際の採用先は既存環境のUpgrade Notesで確認してください。TeamCity 2026.2は2026年9月1日に公開されていますが、直接の跨ぎ更新を自動的に選ぶのではなく、2026.2のリリースノートで前提条件を確認します。
TeamCity CVE-2026-63077 修復では、どのバージョンへ更新すべきか
まず、現在のバージョンを特定し、公式に修正済みとされる同一系統の更新先を優先します。Java、データベース、プラグイン、Agentの組み合わせを検証できない場合は、修正版の適用または公式パッチで露出を抑え、計画されたアップグレードへ分ける方が安全です。
サーバー、データベース、Data Directory、構成ファイル、必要なビルド記録を保全します。通常のデータベースバックアップだけでは、Data Directory内の設定、プラグイン、秘密情報の参照関係、Agent側のワークスペースやKeychainまで保存されるとは限りません。
TeamCityのアップグレード手順では、サーバーとAgentの更新条件が分けて説明されています。公式アップグレード文書を使い、次の台帳を作成してから保守作業へ進みます。
- TeamCityサーバーの現在バージョンと修復先
- Javaランタイムとデータベースの種類
- インストール済みプラグインと利用中の機能
- Agent名、ホスト識別情報、OS、
serverUrl - VCS、成果物保管先、クラウドアカウントとの接続
- Apple開発者資格情報、署名証明書、秘密鍵の保管場所
02保守時間内の更新
作業は、停止、バックアップ確認、修復版の導入、起動確認、バージョン確認の順に進めます。インストールコマンドを先に実行するのではなく、復旧後にどの状態を確認すれば本番へ戻せるかを先に決めておくことが重要です。
サーバー側の確認
- TeamCityサービスを停止し、停止時刻と担当者を記録する
- データベース、Data Directory、設定、必要なログのバックアップ完了を確認する
- 修復版または公式セキュリティパッチを適用する
- サーバーを起動し、管理画面へ管理経路から接続する
- バージョン、プラグイン、データベース接続の状態を確認する
- 更新処理が外部ダウンロードを必要とする場合、プロキシや閉域環境の制限を確認する
TeamCity 2026.1以降などへ移行する場合は、Java 21の要件を必ず確認します。Java 21に関する公式説明に照らし、サーバーだけでなくAgent側の起動方式とサービス設定も確認します。
更新後の阻断確認
TeamCityのセキュリティパッチを適用した後に確認する内容
管理画面へ入れることだけでは不十分です。VCS接続、ビルドキュー、Agent認証、パッチ状態、監査ログをそれぞれ確認し、保守前に記録した状態と比較します。
また、パッチ適用後も、脆弱性の影響を受けた時間帯に作成された構成や成果物が自動的に信頼できる状態へ戻るわけではありません。修復は追加の悪用を止める措置であり、過去の操作や生成物を無害化する処理ではないためです。
03Mac Agentの隔離復旧
サーバー復旧後は、全Mac Agentを一括で本番キューへ戻さず、個別に隔離して確認します。Mac Build Agentはサーバーとは別の信頼境界を持ち、作業領域、Xcode、依存ライブラリ、署名用Keychainを保持しているためです。
Agent単位の検証
- 本番ルーティングと署名対象のビルドキューを無効にする
- Agent名、ホスト識別情報、認証状態、
serverUrlを照合する - 予定外のAgentや所有者を説明できないAgentを承認しない
- 自動アップグレードの結果とAgentログを確認する
- 自動アップグレード中に強制再起動しない
- 隔離したMacで署名を伴わないテストパイプラインを実行する
- Xcode、依存関係、作業領域の消去、成果物保存を確認する
Agentの認証と状態確認には、Agent APIの公式文書を参照します。macOS Agentの起動方式や登録条件は、macOS Agentの公式手順とも照合してください。
脆弱性修復後、Mac Build Agentを安全に戻す方法
最初は署名なしの検証ジョブだけを許可し、次にコード取得、ビルド、テスト、アーカイブ、最後に管理された署名へと段階を分けます。既存ノードで結果が一致しても、未知のAgentや不明な変更が残っている場合は、同じノードを本番署名へ戻してはいけません。
隔離用の予備Macが不足している場合は、短期のクリーンなMac環境を用意し、Agentを再構築して重要なiOS CI/CDを再実行できる状態にします。自社で物理機をすぐに確保できないチームは、NUKCLOUDのMac環境をPoC用の一時環境として比較対象にできます。ただし、長期的な高負荷運用や物理インターフェースが必要な処理では、自社保有ノードとの適合性を別途確認してください。
04初日調査と認証情報の交換
サーバーとAgentの状態が戻っても、脆弱性の影響を受けた期間に作成された認証情報をそのまま使い続けるべきではありません。交換範囲はCI/CD全体を一括で扱わず、接続先と権限の単位で分けます。
交換対象の整理
- VCSのアクセストークンとSSH鍵
- 成果物保管先の認証情報
- クラウドアカウントとデプロイ用鍵
- TeamCity内の接続設定とサービスアカウント
- Apple開発者アカウント、証明書、プロビジョニング関連資産
- Macの署名用Keychain、秘密鍵、解除に使う資格情報
TeamCity侵害後に交換すべきCI/CD認証情報
少なくとも、TeamCityサーバーから到達できるVCS、成果物保管先、デプロイ先、Appleの署名経路を担当者ごとに棚卸しします。交換後は、旧資格情報がまだ使える状態でないこと、最小権限になっていること、監査ログに新しい利用履歴が残ることを確認します。
調査表には、対象、所有者、交換時刻、失効確認、利用先、再検証結果を記録します。作業を急ぐ場合でも、全資格情報を同じ担当者が同時に交換すると、どの経路が残っているか追跡できなくなるため、VCS、成果物、クラウド、Apple署名を分けて管理します。
05クリーンな流水線での再放流
本番復旧の判断は、サーバーが起動したかではなく、信頼できるMac Agentで重要な経路を再現できたかで決めます。旧ノードはすぐに消去せず、取証が必要な場合に状態を維持し、クリーンなノードとの結果差分を記録します。
再放流前の可否判定
- [ ] TeamCityサーバーが修正版または公式パッチ適用済みである
- [ ] 外部公開経路と管理者権限変更を確認済みである
- [ ] データベース、Data Directory、設定、ログを保全済みである
- [ ] すべてのMac Agentを識別し、未知のAgentを隔離している
- [ ] VCS、成果物、クラウド、Apple署名の資格情報を交換済みである
- [ ] クリーンなMacでコード取得と依存関係の解決を確認済みである
- [ ] ビルド、テスト、アーカイブ、管理された署名を順番に検証済みである
- [ ] 脆弱性の影響を受けた期間の成果物を再確認している
- [ ] 失敗時に旧ノードを再利用せず、隔離・再取証・退役を選べる
- [ ] サーバー、認証情報、成果物、Agent、切り戻しの責任者が決まっている
成果物については、ハッシュや生成履歴だけで安全性を断定せず、どのサーバー、どのAgent、どの資格情報で作られたかを追跡します。由来を説明できないアプリは、再署名して配信するのではなく、クリーンな環境で再生成してから審査へ戻します。
TeamCityのMac基盤を短期的に分離して検証する場合、NUKCLOUDの日本向けMacレンタル案内も候補の一つになります。調達前には、Agent再接続、必要なXcode、署名資産の取り扱い、データ消去、アクセス経路をPoCの受入条件として明文化してください。
現在の共有Macや単一の自社ノードだけで復旧を続けると、取証用の状態と本番ビルドが同じ環境で混ざり、再調査の証拠を失いやすくなります。また、物理Macの追加購入では調達期間、初期設定、保守、故障時の代替機確保が別途必要です。短期の隔離検証や一時的な復旧容量だけが必要なら、NUKCLOUDのMacを一時利用し、クリーンなAgentの再構築と重要な流水線の再実行を分離する方が、既存ノードを急いで本番へ戻すより判断しやすくなります。
TeamCity CVE-2026-63077 修復の完了条件は、パッチの導入だけではありません。サーバーの修復、調査可能なログ、認証情報の交換、信頼できるMac Agent、追跡可能な成果物、失敗時の切り戻しをそろえて初めて、iOS CI/CDを段階的に本番へ戻せます。復旧前には、隔離用Macの受入条件と旧ノードの取証・退役方針を文書化してください。
最終更新：2026年9月6日。TeamCityの修正版、緩和策、Agent更新条件、2026.2の前提条件は、JetBrains公式資料を基に確認しています。