TeamCity脆弱性が悪用中、侵害痕跡の確認手順

【更新 2026-08-09】本記事を見直し、修正しました。主な修正点：「手口の詳細は公開されていない」という記述を訂正し、脆弱性の技術的な根本原因の分析と実証コード（PoC）が2026年8月7日にRapid7から公開済みである事実を追記。あわせて同分析が示すサーバーログ上の痕跡（リクエスト先パス・送信元IP）を確認手順に追記しました。

JetBrainsのCI/CDサーバ「TeamCity On-Premises」の未認証リモートコード実行の脆弱性（CVE-2026-63077、CVSS 9.8）が、実際に悪用され始めました。JetBrainsは2026年8月7日に追加ガイダンスを公表し「未パッチのTeamCityサーバーを標的とした悪用および悪用の試みの報告を受けている」と認めています。米CISAは8月5日にこの脆弱性を悪用済み脆弱性カタログ（KEV）へ追加し、政府機関の対応期限を3日後の8月8日に設定しました。

自社でTeamCityを動かしているなら、やるべきことは2つです。修正版（2026.1.3 または 2025.11.7）の適用と、すでに侵害されていないかのログ確認。後者について、JetBrainsは具体的な確認方法を公開しました。そのまま現場で使える内容なので、本記事の中心に据えます。

この記事でわかること

• 7月27日の公表から悪用確認までに何が起きたか（時系列）
• JetBrains公式が示した「侵害されていないか」の確認手順（ログ文字列とエージェント名）
• パッチ適用済みのサーバーでも、なおログを見るべき理由
• 侵害が疑われた場合に棚卸し・ローテーションすべき資格情報の範囲
• CISAが期限を3日に設定した意味（KEVカタログの独自集計つき）

何が起きたのか

この脆弱性は公表から約10日で「悪用未確認」から「悪用中」へと状況が変わりました。時系列で整理します。

重要なのは、7月27日時点の「悪用は確認されていない」という記述を根拠に対応を先送りした組織が、いま最も危険な位置にいるという点です。公表から悪用開始までの猶予は、実質10日しかありませんでした。

誰がどう悪用しているのかは、まだ公開されていない

正直に書きます。攻撃者の正体、実際の攻撃でどう悪用されているか、被害の規模は、いずれも公開されていません。JetBrainsもCISAも「悪用がある」という事実を示しただけで、攻撃キャンペーンの分析は出ていません。つまり情シスの手元にあるのは後述する痕跡だけで、そこで見つからなくても安全の証明にはならないという前提で扱う必要があります。

ただし、脆弱性そのものの技術的詳細はすでに公開されています。Rapid7は8月7日に根本原因の分析を公表しました。TeamCityがXStreamの許可リストを設定する際、XStream側の既定の許可（Map や Throwable などの型階層）を消さないまま自社の型を追加していたことが原因で、修正版では許可リストの前に NoTypePermission.NONE を入れて既定の許可を打ち消しています。同社は実証コード（PoC）もGitHubで公開しました。攻撃者の正体が不明でも、悪用に必要な技術情報は誰でも手に入る状態だという前提で優先度を決めてください。

脆弱性の概要

ベクタが AV:N/AC:L/PR:N/UI:N、すなわち「ネットワーク経由・条件なし・権限不要・利用者の操作不要」で機密性・完全性・可用性すべてに高影響という、脆弱性としては最悪に近い組み合わせです。攻撃の前提条件は「HTTP(S)でサーバーに届くこと」の一点しかありません。

なお、本来「内部のビルドエージェントだけが話す想定」の通信経路が、公開ポート越しに誰からでも叩ける状態になっていた、という構造はApache Axis2の未認証RCEと同じ型です。デシリアライゼーション欠陥は、受け取ったバイト列をそのままオブジェクトに復元する過程で攻撃者の仕込みが動く、という繰り返し現れるパターンです。

自社は影響を受けるのか

対象はTeamCity On-Premises、つまり自社で構築・運用しているサーバーです。JetBrainsがホストするTeamCity Cloudの利用者は対応不要とされています。

問題は「自社にTeamCityがあるかどうかを情シスが把握できていない」ケースです。次の順で探すのが現実的です。

• 外部からの到達性を最優先で確認する：この脆弱性の前提条件はHTTP(S)で届くことだけです。インターネットに露出しているTeamCityが最も危険で、悪用の報告も未パッチサーバーに対するものです。
• ネットワークから探す：TeamCityサーバーの既定ポートは 8111 です。社内セグメントに対してこのポートを確認します。インストール時に変更されている場合もあるため、当たりを付ける用途と考えてください。
• コンテナで動いていないか確認する：公式Dockerイメージ jetbrains/teamcity-server で運用されていることがあります。コンテナで動いている場合、資産管理ツールの「インストール済みソフトウェア一覧」には出てきません。稼働中のコンテナ・イメージの一覧を直接見る必要があります。
• バージョンを確認する：管理画面（Administration）から確認できます。2025.11.7 または 2026.1.3 より前であれば対象です。

侵害されていないかを確認する（本題）

8月7日の追加ガイダンスで、JetBrainsは悪用の痕跡を探す方法を具体的に示しました。これが今回の最大の収穫です。

いずれもXStream（JavaのXMLシリアライズライブラリ）の例外クラス名です。デシリアライズ処理で想定外のクラスを復元しようとしたときに出るもので、この脆弱性の攻撃そのものの副産物にあたります。ログ検索の文字列としてそのまま使えます。

あわせて、前述のRapid7の分析には悪用時に残るログの実例が載っています。ConversionException のスタックトレースには、リクエスト先のパス（POST '/app/agents/v1/commands/error'）・送信元IPアドレス・User-Agent・認証状態（no auth）が併記されます。上の文字列で当たりを付けたあと、この行まで見れば「どこから叩かれたか」を追えます。

パッチ適用済みでもログを見る意味がある

ここが見落とされやすいところです。2つ目の ForbiddenClassException は「パッチが攻撃を防いだ」記録です。防げているのだから問題ない、と読みたくなりますが、実務上の意味は逆です。これが出ているサーバーは、現に攻撃対象として認識され、狙われているということを示します。

つまり確認すべきは次の2点です。

• パッチ適用前のログに ConversionException が無いか ― あれば侵害の可能性を疑い、対応に進む
• パッチ適用後に ForbiddenClassException が出ていないか ― 出ていれば、そのサーバーは攻撃者の標的リストに載っている。ネットワーク側の露出制限を急ぐ根拠になる

ログのローテーション期間にも注意が必要です。7月27日の公表以降のログが残っていなければ、そもそも探せません。「ログが残っていなかった」という結果も、記録として残しておく価値があります。

侵害が疑われたら：資格情報の棚卸し

CI/CDサーバの侵害が厄介なのは、パッチを当ててもすでに漏れた資格情報は戻らない点です。TeamCityサーバープロセスの権限で任意コマンドが実行できたということは、そのサーバーが保持・参照できるものはすべて持ち出されうる、という前提で考える必要があります。

TeamCityに集積しがちなものを挙げます。自社の構成に照らして棚卸ししてください。

• ソースコードリポジトリへのアクセストークン・デプロイキー（GitHub / GitLab / 社内Git）
• クラウドの認証情報（AWS / Azure / GCP のアクセスキー、サービスプリンシパル）
• コンテナレジストリ・パッケージレジストリの認証情報
• コード署名用の証明書・鍵
• 本番環境へのデプロイ用の認証情報・SSH鍵
• ビルドパラメータやビルド構成に平文で埋め込まれた各種パスワード

加えて、ビルド成果物そのものの完全性も検討事項になります。サーバーの状態やビルド構成が改ざんされていれば、そこから出荷されたバイナリに手が入っている可能性が理屈のうえでは残ります。自社製品を顧客に配布している組織にとっては、これは自社だけの問題では済みません。Goモジュールが削除後もプロキシに残る問題と同様、ソフトウェア供給の下流にどう影響するかまで含めて考える必要があります。

ローテーションは影響が大きく、稼働中のパイプラインを止めかねません。だからこそ「侵害が疑われてから対象を洗い出す」のでは遅く、平時に一覧を持っておくことが効いてきます。

なぜ対応期限が3日なのか

CISAはKEV追加（8月5日）から3日後の8月8日を対応期限としました。KEVエントリの必須アクションには、CISAの指令「BOD 26-04」への準拠が明記されています。

この「3日」をどう読むべきか。CISAが公開しているKEVカタログのJSONを取得し、追加日から期限までの日数を集計してみました。2026年に追加された178件（カタログ版 2026.08.07 時点）の期限は、3日以内が73件・14日が60件・21日が44件と大きく3つに分かれています。月別に見ると3日以内の比率は1月の11.8%から6月73.9%、7月84.6%へと急上昇しており、8月に追加された6件はすべて3日でした（筆者による集計。CISA公表の統計ではありません）。

つまり直近では3日が事実上の標準であり、「3日だから今回だけ特別」とまでは言えません。それでも最短区分に置かれた事実は、公開・悪用中・自動化可能・完全な制御の奪取という条件が揃っていると当局が判断したことを意味します。KEV追加の位置づけについてはSharePoint・Check Point脆弱性のKEV追加の回も参考になります。

TeamCityがKEVに載るのは、これで4回目

見落とせないのは、TeamCityがKEVの常連製品であることです。

過去3件はいずれもランサムウェア攻撃での悪用が確認済みです。さらにCVE-2023-42793については、2023年12月にCISA・FBI・NSAと英ポーランドの当局が共同アドバイザリを発出し、ロシア対外情報庁（SVR）系の攻撃グループが2023年9月から世界規模でTeamCityサーバーを標的にしていたと公表しています。Microsoftは同じ脆弱性を北朝鮮系の攻撃グループも悪用していたと報告しました。

今回のCVE-2026-63077は現時点でランサムウェア利用「不明」ですが、この製品が国家支援型の攻撃グループとランサムウェア攻撃者の双方から一貫して狙われてきたという事実は、優先度判断の材料になります。攻撃者から見れば、CI/CDサーバは「一度取れば下流すべてに手が届く」資産だからです。

現場目線の課題：CI/CDサーバは情シスの視界に入りにくい

CI/CDサーバは、多くの組織で開発部門が自分たちの都合で立てたものです。情シスが調達・構築に関与していないため資産台帳に載っておらず、前述のとおりコンテナで動いていればソフトウェア一覧にも現れません。「うちにTeamCityは無いはずだ」という感触は、根拠としてはかなり弱いのが実情です。

加えてCI/CDサーバは止めにくい。ビルドが動いている以上、業務時間中の再起動は開発チームとの調整が要ります。緊急パッチを「今すぐ」と言い切るのが難しい典型的な資産です。だからこそパッチ適用の調整と並行して、まずネットワーク側で外部からの到達性を切る（VPN経由に限定する、社内セグメントに閉じる）という一手が現実的な緩和策になります。JetBrains自身も推奨事項として挙げています。

そして最初の一手は技術ではなく、開発チームへの一本の連絡です。「TeamCityを使っていますか」「バージョンは」「外から見えますか」。これを聞ける関係が平時にあるかどうかが、こういう日に差として出ます。GitLabの脆弱性対応のときも同じ構図でした。

情シスはどうすべきか

対応の骨格は、修正版の適用・外部露出の遮断・侵害痕跡の確認・資格情報のローテーション判断の4つです。これらを自社の手順に落とし込むにあたっては、自前でチェックリストを作り込むより、公的機関が整備した指針を土台にしたほうが確実です。

• IPA「ランサムウェア対策特設ページ」 ― 侵入後の被害拡大を防ぐ観点が整理されています。CI/CDサーバの侵害は「侵入されたあと何を守るか」の問題に直結します。
• IPA「セキュリティインシデント対応 机上演習教材」 ― 「資格情報が漏れた前提で何をどの順で止めるか」は、当日に考えて動けるものではありません。演習で一度通しておく価値があります。
• IPA「中小企業の情報セキュリティ対策ガイドライン」 ― 資産の把握と管理責任の所在という、今回まさに問われている部分の考え方が示されています。

あわせて、開発部門に対する啓発も欠かせません。「開発用のサーバーだから社内向け」という思い込みが、外部公開されたCI/CDサーバを生みます。地道な対話の積み重ねが、結局は一番効きます。

まとめ

• CVE-2026-63077は悪用段階に入りました。JetBrainsが8月7日に悪用の報告を認め、CISAは8月5日にKEV追加・期限8月8日と設定しています。TeamCity On-Premisesの全バージョンが対象で、修正版は2025.11.7 / 2026.1.3、すぐに上げられない場合は2017.1以降向けのパッチプラグインがあります。
• パッチ適用だけでは終わりません。サーバーログの ConversionException と ForbiddenClassException、そして scan で始まる未承認ビルドエージェントの有無を確認してください。後者2つはパッチ適用済みのサーバーでも、狙われている事実を教えてくれます。
• 侵害が疑われたら資格情報の棚卸しへ。ソースコードのトークン、クラウドのアクセスキー、署名鍵、デプロイ用認証情報はパッチでは戻りません。TeamCityは過去3回KEVに載り、いずれもランサムウェアでの悪用が確認された製品です。優先度は高く見積もるべきです。

出典

• JetBrains「CVE-2026-63077: Additional Guidance Following Reports of Active Exploitation」（2026年8月）
• JetBrains「Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)」（2026年7月27日）
• CISA「Known Exploited Vulnerabilities Catalog」（カタログ版 2026.08.07）
• Rapid7「Rapid7 Analysis: Unauthenticated Remote Code Execution in JetBrains TeamCity (CVE-2026-63077)」（2026年8月7日）
• NVD – CVE-2026-63077
• CISA他「Russian Foreign Intelligence Service (SVR) Exploiting JetBrains TeamCity CVE Globally」（AA23-347A、2023年12月）