トップ/記事一覧/TeamCityの乗っ取りが実際の攻撃に CVE-2026-63077、即更新と点検を
teamcity-cve-cover-ja-update

TeamCityの乗っ取りが実際の攻撃に CVE-2026-63077、即更新と点検を

ソフトを組み立てて出荷するサーバー「TeamCity」に、IDもパスワードも要らずに乗っ取られる穴が見つかりました。米政府は8月5日、実際に攻撃されている脆弱性として登録し、修正の期限を3日後の8月8日に設定しています。自社サーバーに置いた版が対象で、修正版は7月27日から出ています。

ニュース2026年8月6日公開 本日更新
目次
この記事のポイント

ソフトを組み立てて出荷するサーバー「TeamCity」に、IDもパスワードも要らずに乗っ取られる穴が見つかりました。米政府は8月5日、実際に攻撃されている脆弱性として登録し、修正の期限を3日後の8月8日に設定しています。自社サーバーに置いた版が対象で、修正版は7月27日から出ています。

米政府のサイバーセキュリティ機関CISAが、2026年8月5日、ソフトウェア開発の現場で使われるJetBrains「TeamCity」の脆弱性 CVE-2026-63077 を、実際に攻撃に使われている脆弱性のリストに追加しました。修正の期限は8月8日。追加からわずか3日です。

このリストは KEV(Known Exploited Vulnerabilities、実際に悪用が確認された脆弱性のカタログ)と呼ばれるもので、米国の政府機関には期限内の対処が義務付けられています。これまでの期限は通常2〜3週間でした。3日という数字は、この制度が始まって以来ほとんど例がありません。

脆弱性そのものは7月27日にJetBrainsが公表済みで、修正版も出ています。IDでのログインもパスワードも一切必要なく、外部から直接サーバーに命令を実行できる穴です。深刻度は10点満点中9.8点

公開直後の時点では、CISAが「攻撃されている」と判断した根拠は明かされていませんでした。その空白は、その後の1週間で完全に埋まりました。JetBrains自身が「実際の悪用と、悪用の試みの報告を受けている」と認め、侵入の痕跡を探すための手がかりまで公開しています。さらにセキュリティ企業Rapid7が8月7日、この穴を実際に突く手順とプログラムを公開しました。

つまり状況は「疑わしい」から「攻撃は起きている。しかも誰でも再現できる」へ変わりました。自社サーバーでTeamCityを動かしている場合、更新は済ませたうえで、更新前に入られていなかったかを自分で確かめる必要があります。その手順は本記事の後半にまとめました。

TeamCityとは何をするソフトなのか

TeamCityは、プログラムを製品の形に組み立てて出荷するための自動化サーバーです。開発者が書いたコードを受け取り、自動でテストして、アプリやインストーラーの形にまとめ、配布先へ送り出すところまでを担当します。工場でいえば製造ラインと出荷場を兼ねた設備です。

こうした仕組みは業界では「CI/CD」と呼ばれます。TeamCityはその代表的な製品のひとつで、開発ツール「IntelliJ IDEA」で知られるチェコのJetBrainsが作っています。同社の製品では、社員アカウントを管理する「Hub」でも最悪評価10.0の脆弱性が今年公表されています

この種のサーバーが厄介なのは、置いてあるものの中身です。製品を組み立てるには、配布サーバーへの接続情報、アプリに署名するための鍵、クラウドの管理者権限、ソースコードそのものが必要になります。それらは全部このサーバーに預けられています。

つまり、ここを取られると、盗まれるのは1社分のデータではありません。その会社が出荷するソフトを使っている全員が下流に控えています。2020年のSolarWinds事件で、正規のアップデートに攻撃者のプログラムが混ぜられて世界中に配られたのは、この製造ラインが侵入されたためでした。ソフトウェアの部品供給網(サプライチェーン)を狙う攻撃の入口として、ビルドサーバーは長く狙われ続けています。

CVE-2026-63077の中身

項目内容
脆弱性IDCVE-2026-63077
対象TeamCity On-Premises
(自社サーバーに置く版)の全バージョン
対象外TeamCity Cloud
(JetBrainsが運用する版)
深刻度9.8 / 10(緊急)
ログインの要否不要
利用者の操作不要(クリック等を誘う必要なし)
できてしまうことサーバー上で任意の命令を実行
公表日2026年7月27日
KEV追加日2026年8月5日
米政府機関の期限2026年8月8日

穴があるのは「エージェントポーリングプロトコル」と呼ばれる部分です。TeamCityは、実際に作業をする子機(エージェント)を複数ぶら下げて動く構成が普通で、子機は親サーバーに向かって「何か仕事はありますか」と定期的に聞きに行きます。その問い合わせを受ける窓口に不備がありました。

技術的な分類はCWE-502(信頼できないデータの復元)です。外から送られてきたデータを、中身を検める前にプログラムの部品として組み立て直してしまう、という種類の欠陥を指します。組み立て直される部品の中に命令が仕込まれていれば、そのまま動いてしまいます。

結果として、TeamCityのウェブ画面に到達できる人なら誰でも、認証を素通りしてサーバーを操作できます。JetBrainsの告知によれば、報告したのはAntoni Tremblay氏で、7月10日に非公開で伝えられ、17日後に修正版と同時に公表されました。

なぜ穴が開いたのか ― 「許可リストが上書きされなかった」

8月7日に公開されたRapid7の分析で、原因がかなり細かいところまで分かりました。要点は、安全のための「許可リスト」が、本来消すべき初期設定を消さないまま追加されていたという一点です。

TeamCityは、子機から送られてきたデータを組み立て直す際、XStreamという部品を使っています。危険なものを組み立てないよう、XStreamには「この種類だけ許す」というリストを渡す仕組みがあります。TeamCity側はそこへ自分たちの通信用の種類を追加していましたが、XStreamがもともと持っていた広い許可を先に取り消していませんでした。結果、リストは「限定された許可リスト」ではなく「初期設定+追加」という緩いものになっていました。

この緩さが効いてくるのは、Javaの許可がその種類そのものだけでなく、そこから派生したものすべてに及ぶためです。「一覧表(Map)を許す」と書けば一覧表の仲間すべてが、「エラー(Throwable)を許す」と書けば各種のエラーがまとめて通ります。攻撃者はこの隙間に、部品を数珠つなぎにした細工を通しました。Rapid7の説明では、エラーの一種に見せかけてデータベース接続の設定を持ち込み、それを別の部品経由でこじ開け、最終的にウェブ公開フォルダへ命令の書かれたファイルを書き出させて、そこにアクセスするだけで実行させるという流れです。

修正版がやったことは単純で、許可リストを渡す前に「まず全部禁止」と宣言する一行を足しただけです。これで初期設定の広い許可が消え、TeamCityが明示した種類しか通らなくなりました。設定の順番が一箇所ずれていただけで、外から誰でもサーバーを取れる状態になっていた、というのが今回の正体です。

誰が狙い、何を持ち去るのか

TeamCityのサーバーを探して回るのは、身代金要求型ウイルスを使う犯罪グループと、他国の政府に雇われたハッカー集団です。これは想像ではなく、この製品では過去に2回、どちらも実際に起きています。

彼らがここで何をするかというと、暗号化してお金を要求する前に、まず出荷される製品そのものに細工を仕込みます。ビルドサーバーを握った攻撃者は、正規の手順で作られ、正規の署名がついた「本物のアップデート」の中に、自分のプログラムを紛れ込ませることができます。受け取る側から見ると、それはメーカーが配った正しいファイルにしか見えません。

被害はふたつの層に出ます。ソフトを使っている一般の利用者は、疑う理由のないアップデートを自分で適用して感染します。開発している企業の側は、保管していた署名鍵とクラウドの権限を失い、出荷済みの製品を全部疑わなければならなくなります。過去に日本国内で起きた大規模なランサムウェア被害と同じで、入口はたいてい、外に向いていた1台のサーバーです。

なぜ期限が3日なのか

この案件で最も目を引くのは、深刻度の数字よりも対応期限の短さです。

これまで、KEVに載った脆弱性の修正期限は原則として2週間でした。根拠になっていたのは2021年の指令「BOD 22-01」です。ところがCISAは2026年6月10日、これを廃止して新しい指令「BOD 26-04」に置き換えました。一律の日数をやめ、危険度に応じて期限を変える方式です。

期限を決める材料は4つあります。

判定材料意味今回の判定
インターネット公開その機器が外から
直接届くか
該当
悪用の確認KEVに載っているか該当(8月5日)
攻撃の自動化機械で大量に
流し込めるか
該当(可能)
被害の程度一部か、全部を
握られるか
該当(全部)

4つ全部に当てはまると、最短の3日枠に入ります。CVE-2026-63077はきれいに4つとも埋まりました。8月5日に登録され、期限が8月8日になっているのは、この計算どおりの結果です。

しかもBOD 26-04の3日枠は、パッチを当てるだけでは終わりません。実装ガイダンスには、同じ3日のうちにそのサーバーが既に侵入されていないかを調べる作業(フォレンジック・トリアージ)まで済ませることが書かれています。「直せば終わり」ではなく「直したうえで、手遅れでなかったかを確認しろ」という要求です。

CISAが期限短縮の理由として指令の中に書いているのは、攻撃側がAIを使い始めたことで、修正が公開されてから悪用が始まるまでの猶予が縮んでいる、という認識です。この新方式に切り替わってから、当サイトで扱った案件でもLangflowの脆弱性が8月4日に登録されて期限8月7日と、同じ3日枠が適用されています。異常事態というより、新しい基準が回り始めたと見るべきでしょう。

攻撃は実際に起きている ― 開発元が認めた

この記事を最初に出した8月6日の朝、はっきりしていたのはCISAがリストに載せたという事実だけでした。開発元の告知は「悪用は確認していない」と書かれたままで、攻撃コードも被害事例も出ていない。だから当時は「悪用の証拠を得たとCISAは言っているが、その中身は分からない」という書き方に留めました。

その保留は解けました。JetBrainsは続報の告知で、「修正していないTeamCityサーバーを狙った、実際の悪用および悪用の試みについて報告を受けている」と明言しました。同社が自ら悪用を認めたことで、CISAの判断の裏付けが取れた形です。あわせて米政府側の評価データ(Vulnrichment)も、7月28日時点の「悪用なし」から「悪用が進行中」へ書き換えられました。

さらに8月7日、セキュリティ企業Rapid7が原因の分析と、実際に動く攻撃プログラムを公開しました。同社の研究者Stephen Fewer氏によるもので、コードはGitHubで誰でも入手できます。これを追いかける形の再配布リポジトリも複数出ています。

攻撃側にとっての意味は単純です。これまでは自力で穴を見つけて武器に仕立てる腕が要りましたが、いまはコードを落として走らせるだけになりました。更新していないサーバーが外から見つかれば、そこで終わりです。

✓ 確認済みの事実(2026年8月12日時点)

  • JetBrainsが実際の悪用と悪用の試みの報告を受けていると公表した(続報の告知
  • 米政府側の評価データが「悪用なし」から「悪用が進行中」へ更新された(CVEの記録は8月6日改訂)
  • 動く攻撃プログラムが8月7日に公開され、誰でも入手できる(GitHub
  • 侵入されたかどうかを自分で調べるための手がかりを、JetBrainsが公開した(下記)

? まだ分かっていないこと

  • ?誰が攻撃しているのか ― 攻撃者の正体や所属は公表されていない
  • ?被害の規模 ― 侵害を公表した組織はまだない
  • ?身代金要求ウイルスとの関係 ― CISAの記録では「不明」のまま
  • ?日本国内の注意喚起 ― JPCERT/CC・IPA・JVNのいずれにも8月12日時点で掲載がない

入られていないかを自分で確かめる

攻撃が公表より前から動いていた以上、更新を当てる前にすでに入られていた可能性を潰しておく必要があります。JetBrainsは、サーバーのログから次の3つを探すよう案内しています。

ログに残る手がかり

  • 1ConversionException という記録 ― 攻撃を仕掛けられた形跡
  • 2更新後に出る ForbiddenClassException という記録 ― 攻撃が届いたが、修正版に弾かれた形跡
  • 3名前が「scan」で始まる、身に覚えのない子機(ビルドエージェント)が登録されていないか

3つ目が特に分かりやすい合図です。TeamCityは作業を分担する子機をぶら下げて動きますが、攻撃者が勝手に登録した子機は、そのまま社内で命令を実行できる足場になります。管理画面の子機一覧に覚えのない名前が並んでいないか、まず目視で確かめてください。

形跡が見つかった場合、あるいはログを残しておらず判断がつかない場合は、更新だけで済ませてはいけません。このサーバーに預けてあった鍵と接続情報は、すべて奪われた前提で入れ替えるのが原則です。配布サーバーの認証情報、アプリの署名鍵、クラウドの権限、外部サービスのトークン。TeamCityを直しても、持ち出された鍵は生きたままだからです。

すぐに更新できない事情がある場合の応急処置として、JetBrainsは2017.1以降で使えるセキュリティ修正プラグインの導入と、サーバーをインターネットから見えない位置へ移すことを挙げています。あわせて、サーバーを動かす権限を最小限に絞る、サーバーと子機を別のネットワークに分ける、といった構成の見直しも案内されています。

TeamCityは過去2回、実際に踏み台にされている

今回の脆弱性を軽く見るべきでない理由は、この製品の履歴にあります。

2023年10月、TeamCityの認証回避の脆弱性 CVE-2023-42793 が、北朝鮮政府と結びついた2つのハッカー集団に悪用されました。Microsoftの分析によると、侵入した端末に勝手に新しいアカウントを作って管理者グループに入れ、認証情報を抜き取る動きが確認されています。同じ年の12月には、CISA・FBI・NSAとポーランド当局が連名で、ロシア対外情報庁(SVR)が同じ穴を世界規模で使っていると発表しました。

日本語訳

ロシア対外情報庁(SVR)がJetBrains TeamCityの脆弱性CVE-2023-42793を悪用しているとして、米国・ポーランドの各機関が合同で勧告を発表しました。

2024年3月には、別の認証回避 CVE-2024-27198 が公開され、今度は身代金要求型ウイルスの出番になりました。トレンドマイクロの調査ではJasminというランサムウェアが、GuidePoint Securityの報告ではBianLianが、それぞれこの穴から入り込んでいます。無断で作られた管理者アカウント、仮想通貨の採掘プログラム、遠隔操作ツールの設置も確認されました。

このときの立ち上がりの速さは記録に残っています。脆弱性の詳細が公開された当日に、スキャンが始まっています。

日本語訳

2024年3月4日22時(UTC)ごろから、JetBrains TeamCityの認証回避脆弱性CVE-2024-27198を狙う悪用活動を観測しています。現時点で16のIPアドレスからのスキャンを確認しました。

2023年は国家機関、2024年は金銭目的の犯罪集団。標的として、この製品は既に十分知られています。今回の穴は過去2件よりさらに条件が緩く、ログインの必要が一切ありません。

自分の会社が対象かどうか

確認は2段階です。まず自社サーバーに置いた版(On-Premises)かどうか。JetBrainsが運用するTeamCity Cloudを使っているなら、今回は対象外です。JetBrainsは自社のクラウド環境について、この脆弱性による侵害の形跡がないことを検証済みだと告知しています。

自社に置いている場合、次はバージョンです。

今使っているもの影響やること
2026.1.2 以前対象2026.1.3 へ更新
2025.11.6 以前対象2025.11.7 へ更新
2017.1 〜 それ以降の
古いバージョン
対象修正プラグインを
適用(下記)
TeamCity Cloud対象外作業不要

すぐに本体を上げられない事情がある場合のために、JetBrainsはセキュリティパッチプラグインを用意しています。2017.1以降であれば適用でき、TeamCityの管理画面から自動でダウンロードするか、手動で入れることができます。本体の入れ替えより影響範囲が小さいので、検証時間が取れない環境ではこちらが現実的です。

あわせてやっておきたいのが、そもそもインターネットから直接見える必要があるのかの見直しです。この脆弱性は、TeamCityの画面に到達できる相手にしか使えません。社内やVPNの内側からしか届かない構成にしてあれば、外部から一斉に流し込まれる攻撃の対象からは外れます。JetBrains自身も、アクセス元を必要な範囲に絞ることを推奨しています。

そして、公開状態で運用していた期間がある場合は、更新して終わりにしないでください。BOD 26-04が3日以内のフォレンジック調査まで求めているのは、まさにこのためです。見覚えのない管理者アカウントが増えていないか、ビルド設定に覚えのない手順が追加されていないか、保管している認証情報が使われた形跡がないか。過去2回のTeamCity侵害では、いずれも不正なアカウント作成が最初の痕跡でした。

どれくらいの数が外に出ているのか

正確な台数は、残念ながら分かりません。

機器検索サービスのFOFAは、公表翌日の7月28日に「14万3千件以上が該当」と投稿しています。ただしこれは検索の一致件数であって、脆弱なサーバーの台数ではありません。過去の事例では、2023年時点でShodanが3,000台超、2024年時点で約2,200台という数字が使われていました。今回に対応する2026年の集計は公表されていません。

日本語訳

【警告】CVE-2026-63077(深刻度9.8): JetBrains TeamCity On-Premises で、エージェントポーリングプロトコル経由の認証不要な遠隔コード実行。自社設置版は全バージョンが対象、Cloudは影響なし。2025.11.7 / 2026.1.3 への更新か、セキュリティパッチプラグインの適用を。

日本国内に何台あるかを示すデータも見つかりませんでした。JPCERT/CCやIPAからの注意喚起は、8月12日時点でも出ていません。悪用が確定し攻撃プログラムまで出回っているのに、国内向けの一次情報は空白のままです。

脆弱性を最初に大きく報じたセキュリティ企業のRapid7は、公表2日後に危険性を指摘していました。同社はその9日後、原因の分析と動く攻撃プログラムまで公開することになります。

日本語訳

2026年7月27日、JetBrainsがCVE-2026-63077に関するセキュリティ勧告を公開しました。TeamCity On-Premises の全バージョンが影響を受ける重大な脆弱性です。悪用されると、保管された認証情報を読み取られ、開発パイプラインの完全性が損なわれる恐れがあります。

ここまでの経過

← スワイプで移動

3日という数字が示していること

CVE-2026-63077そのものは、対処のはっきりした脆弱性です。修正版は2週間近く前から出ており、古いバージョン向けのパッチも用意されています。自社サーバーに置いたTeamCityを使っているなら更新する、それだけの話です。

むしろ注目すべきなのは、米政府が期限を3日に切ったことのほうでしょう。パッチを当て、さらに侵入されていないかを確認するまでを3日で終えろというのは、多くの日本企業の変更管理の手続きでは物理的に無理な日数です。KEVに載った脆弱性の扱いは、事実上「予定に組み込むもの」から「予定を止めて割り込ませるもの」に変わりました。

加えて、この案件は「政府の判断が先に走り、根拠が後から追いついた」典型例になりました。8月5日の登録時点でCISAは根拠を出さず、開発元も「把握していない」と書いたままでした。それが翌6日に開発元自身の悪用確認、7日に動く攻撃プログラムの公開と、わずか2日で裏づけがそろっています。根拠がそろうのを待って動いていたら、その間に攻撃コードが世に出ていたという順序です。KEVに載った時点で手を動かす、という運用の正しさが結果で示された形になりました。

TeamCityは2023年に国家機関に、2024年に犯罪集団に使われました。そして2026年、3度目が始まっています。修正版は7月27日から出ており、更新するだけで穴自体は塞がります。残る仕事は、塞ぐ前に入られていなかったかを確かめることと、預けてあった鍵を疑うことです。ビルドサーバーの怖さは、盗まれるものが自社のデータではなく、自社が出荷する製品を使う全員の信頼だという点にあります。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go