開発現場のCI/CD（継続的インテグレーション／継続的デリバリー。ソフトウェアのビルドやテスト、デプロイを自動化する仕組み）を支えるJetBrains製「TeamCity」のオンプレミス版に、認証を回避して任意のOSコマンドを実行できる脆弱性（CVE-2026-63077）が見つかり、すでに悪用が確認されている。JPCERT/CCは2026年8月13日付のCyberNewsFlashで、影響を受けるバージョンが国内でも稼働していることを確認したとして、修正版の適用に加えて侵害調査の実施までを検討するよう呼びかけた。ビルドサーバーは開発ライフサイクルの中心にあり、認証情報の宝庫でもある。単なる「パッチ当て」で終わらせにくい種類の脆弱性である。
認証チェックの手前で成立してしまう欠陥
JetBrainsがこの脆弱性の情報を公表したのは2026年7月27日（日本時間、以下同）。TeamCityがビルドエージェントとの通信に使うエージェント・ポーリング・プロトコルの処理に問題があり、信頼できないデータのデシリアライズ（受け取ったデータをプログラム内部のオブジェクトに復元する処理）が成立してしまう。結果として、サーバーにHTTP(S)でアクセスできる第三者が、認証チェックを回避したままTeamCityサーバープロセスの権限で任意のOSコマンドを実行できる。共通脆弱性評価システム（CVSS）の基本値は9.8で、最も深刻な部類に位置づけられている。
厄介なのは、実行権限が「TeamCityそのもの」の権限だという点だ。JetBrainsは、悪用された場合にTeamCityのデータや設定、保存された認証情報が漏えいする可能性、サーバーの状態が変更される可能性、さらにビルド成果物や後続のCI/CDパイプラインの整合性が損なわれる可能性を挙げている。ビルドサーバーには本番環境へのデプロイ鍵、クラウドの認証情報、署名用の秘密情報などが集まりやすい。侵入されれば、被害は「TeamCityが止まる」ことではなく「そこから先の環境すべてが疑わしくなる」ことになる。
なお、クラウド版のTeamCityについては、ユーザー側での対処は不要とされている。
公表からわずか10日で「実際に攻撃されている」段階へ
この脆弱性が普通のパッチ案件と違うのは、悪用の確認までが速かったことだ。
米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は8月5日（米国時間）、CVE-2026-63077を、実際に悪用が確認された脆弱性をまとめた「Known Exploited Vulnerabilities（KEV）カタログ」に追加した。米連邦政府の行政機関に対しては、8月8日までにパッチ適用または緩和策の実施を求めている。JetBrains自身も8月7日、本脆弱性の悪用に関する報告を受けているとの情報を公表した。
さらに8月8日には、セキュリティ企業Rapid7が本脆弱性を悪用して任意のコマンドを実行可能とするエクスプロイトコード（脆弱性を突く検証用の攻撃プログラム）を公開している。同社の分析によれば、脆弱なTeamCityでは、認証されていないエージェント要求を処理する際にデシリアライズを許可するJavaクラスの一覧（許可リスト）へTeamCity独自のクラスを追加する一方で、ライブラリ側の既定の許可設定を外していなかった。修正版では既定の許可をいったん打ち消したうえで許可リストを適用する形に変わっている。
公表から検証コードの公開まで2週間足らず。この間に更新できていなかった組織は、攻撃に使える情報が公になった状態にさらされ続けていた可能性がある。
対象バージョンと打てる手
JPCERT/CCが整理した対象は、TeamCity 2026.1.3より前のバージョン、および2025.11.7より前のバージョン。裏を返せば、修正が入っているのは2026.1.3と2025.11.7で、まずはここへの更新が基本線となる。
すぐにバージョンアップできない場合の受け皿として、JetBrainsは2017.1以降のTeamCityに向けて、CVE-2026-63077のみを修正するセキュリティパッチプラグインを提供している。ただし2017.1から2018.1までのバージョンに適用する場合はサーバーの再起動が必要になる点に注意したい。
そして、この事案でより重要なのが侵害調査だ。JetBrainsは悪用された場合に確認すべきサーバーログの項目を、Rapid7は悪用に使われるエンドポイントやログに残る痕跡を、それぞれ公開している。JPCERT/CCも、すでに攻撃が発生していることを踏まえ、バージョン確認とあわせて侵害調査の実施を検討するよう促している。
パッチ適用で「終わり」にできない事案
脆弱性対応は、修正版を当てた時点で完了と見なされがちだ。しかし、公表から悪用確認までが10日ほどしかなかった今回のような事案では、「更新した」ことと「侵害されていない」ことはまったく別の話になる。更新が数日遅れただけで、その間に足場を作られていた可能性が残るからだ。
しかもTeamCityは、インターネットに露出させたまま運用されることが珍しくない。社外の開発メンバーやクラウド上のビルドエージェントと通信させる都合上、境界の内側に閉じ込めにくいためだ。加えて、保存された認証情報が抜かれていた場合、TeamCity自体を修正しても、その認証情報が有効なままである限りリスクは残り続ける。侵害の疑いがあるなら、資格情報のローテーションまで含めて考える必要がある。
CI/CDは近年、ソフトウェアサプライチェーン攻撃の主要な標的になっている。ビルドの流れに手を入れられれば、正規の署名がついた成果物として不正なコードを配布できてしまうからだ。開発基盤は「社内向けの道具」ではなく、本番環境と同等の重要インフラとして扱う。今回の脆弱性は、その前提を改めて突きつけている。
同じ手口に、自社は備えられていますか？