【ITニュース解説】Detecting and Hunting CVE-2026-106218 Exploitation in TeamCity Environments

この解説文では、TeamCityというソフトウェアに発見されたセキュリティ上の問題、通称「CVE-2026-106218」について、システムエンジニアを目指す初心者の皆さんにも分かりやすく説明する。

まず、TeamCityとは、ソフトウェア開発の現場でよく使われるツールの一つで、コードのビルド（プログラムを動かせる形にすること）、テスト、デプロイ（完成したプログラムを実際に使えるように配置すること）といった一連の作業を自動化してくれる。これにより、開発者は効率よくソフトウェアを開発できる。

今回問題となっている「CVE-2026-106218」は、TeamCityの設定を記述するための「Kotlin DSL」という機能に存在する「サンドボックスエスケープ」と呼ばれる脆弱性である。サンドボックスとは、プログラムを安全に隔離された環境で実行するための仕組みだが、この脆弱性があると、攻撃者はその安全な壁を乗り越えて、TeamCityが動作しているサーバー（ビルドホスト）上で、本来許されていない任意のプログラムを実行できるようになってしまう。これは非常に危険な状況であり、サーバーが完全に攻撃者の支配下に置かれる可能性もある。この脆弱性の危険度は8.8と評価されており、深刻な問題とされている。

幸いなことに、現時点ではこの脆弱性が実際に悪用されたという確かな報告はなく、どのように悪用するかを具体的に示す「Proof-of-Concept (PoC)」と呼ばれる手法も公開されていない。このため、セキュリティ担当者は、攻撃が発生する前に、システム内の潜在的な脅威を発見する「ハンティング」を行うことができる良い機会だと考えられている。

この脆弱性の検出が難しい理由の一つは、TeamCity自体が普段から多くのプログラムを実行し、様々な活動を行うため、悪意のある活動と正常な活動を見分けるのが非常に難しい点にある。

攻撃者は、TeamCityの設定内容を変更することでこの脆弱性を悪用しようとする。TeamCityのビルド設定は、通常、Gitなどのバージョン管理システムに保存されている。そのため、まずTeamCityの設定を供給しているリポジトリを特定し、脆弱性が存在した期間中の変更履歴を詳しく調査することが重要だ。特に、次のような変更には注意が必要となる。

• 普段ビルド設定ファイルをほとんど触らないユーザーアカウントが、突然これらのファイルを変更するコミットを行った場合。
• サーバー上で直接コマンドを実行する「シェル呼び出し」、外部のネットワークと通信する「ネットワークフェッチ」、ファイルの内容を書き換える「ファイル書き込み」といった処理を追加するような変更。
• 通常のレビュープロセスを経ずに、不正にマージ（変更が本流に取り込まれること）された変更。
• バージョン管理システムを使わず、TeamCityのウェブインターフェースから直接行われた設定変更。

もし攻撃が成功し、任意のコードがビルドホスト上で実行された場合、サーバーの「ホストレベル」でも不審な兆候が見られることがある。ビルドサーバーは通常、多くのプロセスを起動するため、何が正常な状態であるかを知る「ベースライン」を設定しておくことが不可欠だ。具体的には、以下の点に注目して調査を行う。

• TeamCityのサーバープロセスが、本来ビルドエージェントのワーカープロセスが生成するはずのない、不審な子プロセスを直接起動していないか。
• サーバーが、通常は通信しない外部のアドレス（IPアドレスやドメイン）へネットワーク接続を試みていないか。
• ビルドホストに、新しい定期実行タスク、サービス、または起動時に自動的に実行されるプログラムが追加されていないか。
• サーバー上に保存されている、認証情報（パスワードなど）を含む設定ファイルが、不正に読み取られていないか。

さらに、攻撃者がビルドプロセスを改ざんした場合、最終的に生成される「成果物」にも痕跡が残る可能性がある。脆弱性が存在した期間中に作成された成果物の「ハッシュ値」（ファイルの同一性を証明する固有の値）を、安全な状態のソースコードから再ビルドした成果物のハッシュ値と比較する。もしハッシュ値が一致しない場合は、たとえビルドが成功したと報告されていても、不正な改ざんがあった可能性を調査する必要がある。

この脆弱性は、TeamCityのバージョン2026.1.3と2025.11.7で修正されている。関連する他の脆弱性も同時に報告されており、Exposedライブラリのバージョン1.5.1より前のもの、およびサブモジュールのURL処理に関する問題がバージョン2026.2.1で修正されている。これらの修正が含まれる最新バージョンへアップデートすることが強く推奨される。

現在のインターネット上には、約1,868件のTeamCityアプリケーションが公開されていることが確認されている。しかし、これらのシステムのうち、どれだけがすでに脆弱性に対応するパッチを適用しているかは不明だ。

このような脆弱性への対応として、最も重要なのは、まず第一に「パッチを適用する」ことである。パッチを適用すれば、それ以降の攻撃を防ぐことができる。ただし、パッチを適用しても、過去の攻撃の痕跡はシステム内に残るため、パッチ適用後に調査を行うことが可能となる。

実践的な調査の順序としては、まずビルド設定の変更履歴を調べ、次にサーバー上のプロセス活動（プロセスの親子関係など）を確認し、その後に成果物の完全性を検証する。そして最後に、もしビルドホストがアクセスできる可能性のある他のシステムがある場合は、それらのシステムの認証情報（パスワードなど）をすべて変更する「ローテーション」を行うことが推奨される。これらの調査で不審な証拠が見つからなかったとしても、それは「攻撃がなかった」と断定するのではなく、「攻撃の証拠が見つからなかった」と正直に結論づけるべきである。見つからないだけで、過去に攻撃があった可能性は排除できないため、引き続き警戒と監視が必要だ。