TeamCity未認証RCE（CVE-2026-63077）：CISAがKEVに追加、公開サーバーは即時隔離と修正が必須です

今日の深掘りポイント

• KEV入りは「悪用が現実化している」サインです。脆弱性管理からインシデント対応モードへ舵を切るべき局面です。
• CI/CDはTier-0資産です。TeamCityが破られると、ビルド成果物・署名鍵・クラウド/レジストリ資格情報まで汚染が波及します。
• 攻撃は未認証RCEから一気にパイプライン改ざんへ進みます。検知は認証ログだけでは追えず、プロセス生成や外向き通信のふるまい監視が鍵になります。
• インターネット公開のTeamCityは原則撤去（VPN/ZTNA配下）です。公開前提の設計は、この種の前段RCEでは防ぎ切れないことを前提に再設計すべきです。
• 直ちに隔離→修正適用→横断的な監査（パイプライン改変・資格情報流出・署名鍵不正利用）→機密の棚卸と失効・再発行までをワンセットで計画すべきです。

はじめに

CISAがJetBrains TeamCityの重大脆弱性CVE-2026-63077を既知の悪用脆弱性（KEV）カタログに追加し、米連邦機関に対して2026年8月8日までの修正適用を求めています。報道によれば、本件はHTTP/HTTPSで公開されたTeamCityオンプレミスに対して、認証なしでリモートコード実行（RCE）が可能になる欠陥で、実際に悪用の証拠があるとされています。CI/CD基盤の侵害は単発のサーバー被害にとどまらず、ソフトウェア供給網全体の信頼を揺るがします。各組織は「露出しているTeamCityを即時に隔離する」ことから始めて、パイプライン全体の完全性を守るための緊急オペレーションに移行する必要があります。

参考：CISAの警告を報じる二次情報（原典への導線として活用ください）

• CISA Alerts on Actively Exploited TeamCity Vulnerability (GBHackers)

深掘り詳細

事実関係（確認できる範囲）

• CISAはTeamCityのCVE-2026-63077をKEVに追加し、悪用の事実を前提に修正期限を設定しています（米連邦機関の期限は2026年8月8日）と報じられています。
• 脆弱性はTeamCityオンプレミスのHTTP/HTTPS公開サーバーで、未認証のままRCEを許します。
• 問題の根は「エージェント・ポーリング・プロトコル」における信頼できないデータのデシリアライズに関連し、TeamCityサーバー権限で任意のOSコマンド実行を許す可能性があるとされています。
• CI/CDサーバーの侵害は、ソースコードやデプロイメントの秘密・署名鍵・アーティファクトの改ざんなど、供給網全体への波及リスクを高めます。

出典はいずれも上記の報道に基づくもので、現時点での公開一次情報（CISA KEVエントリやベンダー通告）は参照元の案内に従って確認いただくことをおすすめします。編集部としては、CISAのKEV入りという事実自体が「即応」を要求する十分条件だと捉えます。

編集部のインサイト（仮説と示唆）

• 未認証RCE×CI/CDという組み合わせは、通常のWebアプリ侵害と比較して「爆心地が開発・配布の信頼連鎖」に直結します。攻撃者が最初に狙うのは、ビルドステップやテンプレートの改変、VCSやクラウドへの接続資格情報、そして署名鍵の所在です。これは単なるサーバー乗っ取りではなく、組織の「出荷するソフトウェア」そのものを人質に取る構図です。
• エージェント・ポーリング経由の欠陥という点は、擬装エージェントによるサーバー側処理の悪用が想像されます（推測です）。この場合、攻撃の初動は認証をまたがないため、失敗試行やMFA失敗のような認証関連SIEMアラートが立たず、検知はプロセスふるまい・外部通信・設定差分の監視に依存しがちです。
• KEV入りの意味は「既に弾が飛んでいる」ことです。パッチ適用はもちろんですが、すでに侵害されている前提で「パイプラインの完全性確認」と「秘密の棚卸・失効・再発行」を含む復旧計画に同時着手すべきです。対応の優先度は、公開可否・権限範囲・署名鍵や本番接続に近いか（Tier-0/1相当）で決めるのが筋です。

脅威シナリオと影響

以下は編集部による仮説ベースのシナリオで、MITRE ATT&CKに紐づけて整理します。実態は環境依存ですので、あくまでハンティング計画と演習設計の叩き台としてご覧ください。

• シナリオA：高速な「窃取＋足場確保」

  • 初期侵入: Exploit Public-Facing Application（T1190）により未認証RCEを獲得
  • 実行: Command and Scripting Interpreter（T1059）でシェル起動、リバースシェル確立
  • 永続化: Create or Modify System Process（T1543）や新規管理者作成（Valid Accounts, T1078）
  • 資格情報: Unsecured Credentials（T1552）、Credential Dumping（T1003）でトークン・PAT・クラウド鍵を窃取
  • 防御回避: Indicator Removal on Host（T1070）
  • 影響: 機密リポジトリやクラウド環境への横移動（Remote Services, T1021）

• シナリオB：静かな「供給網汚染」

  • 初期侵入: 同上（T1190）
  • 発見・準備: Discovery（各種T1082/T1016/T1046）でパイプラインと署名フローを把握
  • 改ざん: Build/Releaseパイプラインのステップ・テンプレート改変（Defense Evasion/Impactの複合、Data Manipulation T1565）
  • 信頼の突破: Subvert Trust Controls（T1553）に相当する署名や検証工程の悪用・迂回
  • 影響: マルウェア混入アーティファクトの出荷、サプライチェーン被害の多段化

• シナリオC：恐喝・破壊の二段構え

  • 初期侵入～資格情報窃取まではAと同様
  • 影響: ソースコード・秘密の持ち出しによる恐喝、パイプライン停止や破壊（Service Stop/DoS相当）
  • 後続被害: リリース遅延、顧客向けアーティファクトの信頼失墜、規制・契約上の報告義務発生

ビジネス影響は、開発リードタイム、出荷停止、インシデント対応コストだけでなく、「署名鍵やCI/CD資格情報の再発行・再信頼構築」のコストと時間が重くのしかかります。供給網を含む外部ステークホルダーとの連携（影響評価・鍵更新・アーティファクト失効）まで含めた計画が不可欠です。

セキュリティ担当者のアクション

インシデント対応モードを前提に、以下を「同時並行」で進めることをおすすめします。

• 露出の即時是正

  • インターネット公開のTeamCityオンプレミスを即時に隔離（IP制限、WAF越しでも原則遮断）し、VPN/ZTNA配下に移行します。
  • 外向き通信は最小化し、VCS・レジストリ・必要なクラウドエンドポイントのみに限定します（DNS/443の汎用外連を閉じる方針で検討します）。

• 修正適用とバージョン統制

  • ベンダーの最新セキュリティリリースを適用します。適用前後で整合性チェック（ファイルハッシュ、設定差分）を取り、チェンジ管理台帳を残します。
  • パッチ未適用期間に公開されていたインスタンスは、侵害前提で後述のサーベイを必ず実施します。

• 侵害有無のサーベイ（ハンティング観点）

  • TeamCityサービス（一般にJavaプロセス配下など）からの不審な子プロセス生成、スクリプト実行、外向きC2様通信の有無をEDRで横断検索します。
  • TeamCityの管理者・ロール・権限設定、ビルドステップ／テンプレート／エージェント設定の改変履歴を点検します（少なくとも直近数週間～告知以降）。
  • VCS連携・アーティファクト署名・クラウド接続に用いる資格情報のアクセス履歴と異常（国・ASN・時間帯・装置指紋）を確認します。
  • サーバーログ／監査ログの欠落・改ざん痕跡（ローテーション異常、タイムスタンプ飛び、エラー急増）を確認します。

• 秘密情報の棚卸と鍵・トークンの失効／再発行

  • TeamCityが参照する全ての資格情報（VCS PAT/SSH鍵、コンテナレジストリ、クラウドAPI鍵、サードパーティ連携トークン、署名鍵のアンロック用秘密など）をリスト化し、優先度順に失効・再発行します。
  • コード署名やアーティファクト検証の信頼連鎖を点検し、必要に応じて過去に出荷した成果物のリコール／再署名ポリシーを準備します。

• パイプラインの完全性回復

  • ビルド定義のベースライン（コード化された設定を推奨）を用意し、改変検出を自動化します（二人承認／PR運用の徹底）。
  • 本番接続・デプロイ承認は、ビルド完了と別ドメインのコントロールプレーンで管理し、単一侵害で両方が破られない分離を徹底します。

• アーキテクチャと運用の再設計

  • CI/CDをTier-0資産としてネットワーク分離、特権アカウントの境界、監査・保全プロセス（FIM、バックアップのリストア演習）を再設計します。
  • 攻撃面の縮小（不要プラグイン無効化、最小権限、短寿命トークン、エージェントのエフェメラル化）を進めます。
  • KEV対応SLA、公開系CI/CDの存在禁止（やむを得ない場合はZTNA＋境界制御＋速やかなAuto-Update）をセキュリティ標準に明記します。

• 経営・対外コミュニケーション

  • 出荷判定ゲートに「CI/CD完全性チェック合格」を追加し、暫定的に出荷を抑制する判断基準（リスク受容閾値）を定義します。
  • 顧客・パートナー向けの説明責任（影響調査の範囲、鍵再発行、検証手順）をあらかじめ用意します。

最後に強調したいのは、今回の指標が示すのは「緊急性」と「実行可能性」の高さです。技術的な修正だけでなく、サプライチェーン全体の信頼回復までを見据えた対応が必要です。チームを横断して、隔離・修正・監査・再発行・再設計を一気通貫で回し切る体制づくりが、明日の平常運転を取り戻す最短距離になります。