TeamCity CVE-2026-63077 とは｜JetBrains Cadence 侵害で確認された事実と、まだ分かっていないこと

JetBrains のクラウド実行サービス Cadence が、同社自身の CI/CD 製品 TeamCity の脆弱性 CVE-2026-63077 を悪用されて侵害された。重要なのは、これが第三者による告発ではなく JetBrains 自身が公表し、自らの過失も認めているという点だ。本記事は 2026-09-06 時点で一次ソースから確認できた事実と、まだ確認できていないことを明確に分けて整理し、あなたの環境で何を確認すべきかを示す。

この事案は、認証情報の流出が下流のパッケージ配布まで波及しうる点で供給網の問題でもある。攻撃手口と防御の全体像は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめている。

CVE-2026-63077 とは——TeamCity の脆弱性の中身

CVE-2026-63077 は TeamCity On-Premises の未認証リモートコード実行（RCE）脆弱性である。以下はすべて NVD と JetBrains 公式アドバイザリで確認した値だ。

影響を受けるバージョンと、修正済みバージョンの境界は間違えやすい。 NVD の機械可読な定義（versionEndExcluding）では次のとおりで、2025.11.7 と 2026.1.3 は「修正済み」側である。

JetBrains 自身は「TeamCity On-Premises の全バージョンが影響を受ける」と表現している。すぐに更新できない環境向けに、2017.1 以降で使えるセキュリティパッチプラグインも提供されている（このプラグインは CVE-2026-63077 のみを塞ぐもので、他の修正は含まない）。

なお本記事は攻撃の再現手順や実証コードは一切扱わない。以下で扱うのは検知と対処のみである。

何が起きたのか——JetBrains 自身が公表した経緯

Cadence とは何かを先に押さえておく。Cadence は JetBrains がホストするクラウド計算サービスで、PyCharm にオプションのプラグインとして統合され、IDE から直接クラウド上の計算資源で機械学習などの重い処理を実行できる。そしてこの Cadence は、ワークロードのオーケストレーションに JetBrains 自社の TeamCity を使っていた。これが侵入経路になった。

JetBrains が公式ブログで confirmed（確認済み） と明記しているのは以下である。

・個人データのアクセスと抽出——ユーザー名・実名・メールアドレス・最終ログイン日時・最終アクセス IP アドレス
・2024年時点の Cadence サーバー完全バックアップの侵害——認証情報・設定・成果物・ログを含む
・複数の AWS IAM ユーザーと認証情報の侵害——上記2024年バックアップ内に存在したもので、JetBrains 従業員の IAM ユーザーを含む
・JetBrains の AWS アカウント内 S3 バケット上のファイルへのアクセス

一方、PyCharm から同期されたプロジェクトのソースコードについては「アクセスした可能性がある（may have accessed）」という表現にとどまり、断定されていない。ここを「ソースコードが流出した」と書くのは一次ソースを超えている。

そして JetBrains は、自社の対応の失敗を明示的に認めている。

時系列と、この事案で最も重い事実

注目すべきは日付の一致である。CISA が KEV に登録した際の連邦機関向けパッチ期限は 2026-08-08 であり、JetBrains 自身のサーバーへの侵入が始まった日も 2026-08-08 だった。 つまり脆弱性を公表した当のベンダーが、修正版公開から12日後・KEV 登録から3日後の時点で、自社の本番サーバーをまだ塞げていなかったことになる。

CISA KEV の登録内容も実データで確認した（dateAdded 2026-08-05 / dueDate 2026-08-08 / forensicTriage: Yes）。ランサムウェアでの利用は Unknown である。参考までに、KEV に収録されている TeamCity の脆弱性は本件を含め4件あり、過去3件（CVE-2023-42793 / CVE-2024-27198 / CVE-2024-27199）はいずれもランサムウェア利用が Known になっている。

確認できたこと／確認できていないこと

この事案は情報の温度差が大きい。事実・報道・推測を分けて読む必要がある。

一次ソースで確認できたこと

JetBrains 公式の声明は存在する。本記事執筆時点で確認できており、PyCharm 公式ブログに掲載され、最終更新は 2026-09-03 19:00 CEST、その時点で「調査は完了した（Our investigation has now concluded）」と明記されている。投稿者は JetBrains の Daniel Gallo で、TeamCity の CVE アドバイザリと同一の著者である。

つまり本件は「被害企業自身が認定している」ケースであり、第三者セキュリティベンダーの主張が独り歩きしている類の事案ではない。

確認できていないこと（2026-09-06 時点）

報道されている内容の扱い

本件を報じた The Hacker News（2026-09-05 公開） の記事は、一次ソースと突き合わせた限りおおむね正確だった。ただし次の2点は一次ソースと差がある。そのまま転記していれば誤りが混入していた部分なので、報道経由で読む場合の注意点として挙げておく。

・The Hacker News は「20224 年のバックアップ」と表記しているが、JetBrains 公式の記載は 2024 年である（単純な誤記と思われる）
・同記事は調査が継続中であるかのような書き方をしているが、JetBrains は 2026-09-03 に調査完了を宣言している
・また同記事は攻撃経路がエージェントポーリングプロトコルである点に触れていない。NVD と JetBrains 公式は明記している

なお攻撃者の帰属について The Hacker News も「誰が背後にいるかは明らかでない」と書いており、報道と一次ソースのどちらも帰属を特定していない。

日本語での報道状況も確認した。2026-09-06 時点で、Security NEXT に該当記事は見当たらず、JVN にもエントリは無い。日本語の一次情報はまだ乏しい状況にある。

あなたは影響を受けるのか——製品別の判定

最も多い誤解は「JetBrains 製品を使っているから危ない」という読み方だ。そうではない。分岐するのは TeamCity の運用形態と Cadence の利用有無である。

YouTrack や Rider など TeamCity 以外の JetBrains 製品について、本 CVE の影響を示す記載は一次ソースに無い。「JetBrains 全製品が危険」という書き方は事実に基づかない。

自分の環境を確認する——実行して検証したコマンド

ここで示すコマンドは、すべて実際に実行し、陽性対照（検出されるべきケース）と陰性対照（検出されないケース）の両方で挙動を確認している。

とくに注意すべきなのは「何も出力されない＝安全」と読み違える事故だ。対象ディレクトリが存在しないだけでも、素朴なコマンドは無言で終了して「問題なし」に見えてしまう。以下のコマンドは「該当なし」と「判定不能」を区別して出力するようにしてある。

1. Cadence プラグインを使っていたかを確認する

PyCharm の Cadence プラグインの痕跡を探す。macOS / Linux 両対応。

#!/usr/bin/env bash
# JetBrains Cadence プラグインの痕跡を探す
BASES=(
  "$HOME/Library/Application Support/JetBrains"   # macOS
  "$HOME/.local/share/JetBrains"                  # Linux
  "$HOME/.config/JetBrains"                       # Linux(旧)
)
found_base=0; hits=0
for b in "${BASES[@]}"; do
  [ -d "$b" ] || continue
  found_base=1
  echo "検査中: $b"
  while IFS= read -r p; do
    if ls -1 "$p" 2>/dev/null | grep -qi cadence; then
      echo "  [要確認] $p に cadence を含むプラグインあり"; hits=$((hits+1))
    fi
  done < <(find "$b" -maxdepth 2 -type d -name plugins 2>/dev/null)
done
if [ "$found_base" -eq 0 ]; then
  echo "判定不能: JetBrains の設定ディレクトリが見つかりません（未インストール、または別パス）"; exit 2
fi
[ "$hits" -eq 0 ] && echo "該当なし: Cadence プラグインの痕跡は見つかりませんでした"
exit 0

検証結果は以下のとおり。3つの状態がすべて区別できることを確認した。

「判定不能」が終了コード 2 で返るため、安全と取り違えられない。なお該当した場合でも、それは「Cadence を使っていた可能性がある」ことを示すだけで、被害の有無を意味しない。

2. TeamCity サーバーのログを一次調査する

JetBrains は追補アドバイザリで、ログ中の2つの例外文字列を確認するよう案内している。前者は悪用の試行または成功を示唆し、後者はパッチが試行をブロックしたことを示す。

#!/usr/bin/env bash
LOGDIR="${1:?使い方: triage.sh <TeamCityログディレクトリ>}"
if [ ! -d "$LOGDIR" ]; then
  echo "判定不能: ログディレクトリが存在しません: $LOGDIR"; exit 2
fi
n=$(find "$LOGDIR" -type f -name '*.log' 2>/dev/null | wc -l | tr -d ' ')
if [ "$n" -eq 0 ]; then echo "判定不能: *.log が1件も見つかりません"; exit 2; fi
echo "検査対象: ${n} ファイル"
a=$(grep -rl 'com.thoughtworks.xstream.converters.ConversionException' "$LOGDIR" 2>/dev/null)
b=$(grep -rl 'com.thoughtworks.xstream.security.ForbiddenClassException' "$LOGDIR" 2>/dev/null)
[ -n "$a" ] && echo "[要調査] 悪用の試行/成功を示唆する例外あり:" && echo "$a" | sed 's/^/    /'
[ -n "$b" ] && echo "[遮断済] パッチが試行をブロックした記録あり:" && echo "$b" | sed 's/^/    /'
[ -z "$a$b" ] && echo "該当なし: 既知の2つの例外は検出されませんでした（悪用がなかったことの証明ではありません）"
exit 0

こちらも4状態で検証済みである。

ConversionException は単独では悪用を確定しない——JetBrains 自身が「このメッセージだけでは悪用を確認したことにはならないが、調査に値する」としている。逆に ForbiddenClassException が出ていれば、それはパッチが効いて試行が阻止された記録である。

3. 未承認ビルドエージェントを目視で確認する

JetBrains は、未承認ビルドエージェントの一覧に scan で始まる名前のエントリが無いかの確認も勧めている。該当するエージェントは削除して問題ない。ただし一覧に表示される日付は試行時刻を示さないため、時刻の判断はログのタイムスタンプで行う必要がある。

この確認は TeamCity の管理 UI 上の操作であり、コマンドでの検証対象外である（筆者は TeamCity サーバーを保有していないため、この項目は実機で検証していない。JetBrains 公式アドバイザリの記載として紹介する）。

対処——認証情報のローテーションはどこまで必要か

Cadence を使っていた場合、JetBrains は「Cadence 実行に使われた可能性のあるすべての認証情報とシークレットを、直ちに失効またはローテーションする」よう求めている。対象として公式に挙げられているのは以下である。

・クラウド認証情報——AWS / Azure / Google Cloud
・ソース管理の認証情報とトークン——GitHub / GitLab / Bitbucket
・パッケージレジストリの認証情報——npm / Maven / NuGet / PyPI 等
・コンテナレジストリの認証情報——Docker Hub / ECR / GCR / ACR 等
・その他——Slack トークン、Webhook、API トークン、SSH／デプロイキー、サービスアカウント認証情報、署名鍵・証明書

パッケージレジストリとコンテナレジストリの認証情報が含まれている点は重い。これらが悪用されれば、影響が及ぶのは自社だけでなく配布物の利用者にまで及ぶ。同種の波及がどう起きるかは crates.io の arrayref 汚染事件 の分析が参考になる。CI/CD のシークレットが狙われる構図そのものについては AI コーディングエージェントと CI/CD シークレット でも扱った。

あわせて JetBrains が挙げている確認項目は次のとおりである。

・接続先システムの不審な活動——AWS アカウント / S3 バケット / デプロイ環境 / パッケージ・コンテナレジストリ
・ソースコードリポジトリの不正な変更——影響期間中のコミット・クローン
・リポジトリのシークレット・Webhook・コラボレーター・権限の変更
・新規または変更されたアクセストークン・API トークン・SSH 鍵
・クラウド IAM のロール・ポリシー・権限の想定外の変更
・2026-08-08 以降の、Cadence 由来の認証情報を用いた認証・活動

JetBrains は侵害指標（IoC）として6つの IP アドレスも公開しているが、同社自身が「これらの指標は網羅的ではなく、指標が無いことは影響が無かったことを意味しない」と明記している点は押さえておきたい。IoC の一致だけを根拠に「うちは大丈夫」と結論しないこと。

なお Cadence 利用者は、JetBrains に問い合わせることで自分の Cadence 利用に紐づく認証情報の一覧を請求できる。ただしこれも「網羅的とは見なすべきでない」とされている。

この事案から読み取れること

教訓は「TeamCity が危険」ではない。むしろ次の3点である。

1つ目は、パッチ適用の期限は組織の内側でこそ守られないということ。 JetBrains は脆弱性を自ら発見・修正・公表し、緩和策まで用意していた。それでも自社の1台が漏れた。修正版を出す能力と、自社の全資産に確実に適用する能力は別物である。攻撃者が侵入したのは、修正版公開から12日後だった。

2つ目は、古いバックアップが現在のリスクになるということ。 侵害されたのは2024年のバックアップであり、そこに含まれていた AWS IAM 認証情報が2026年の時点でまだ有効だった。バックアップの保持は復旧のためだが、その中の認証情報を棚卸ししていなければ、それは2年前の鍵を攻撃者に渡すことになる。

3つ目は、報道と一次ソースの距離を意識すること。 本記事で確認したとおり、報道は概ね正確でも細部（年号の誤記、調査の完了状況、攻撃経路）で一次ソースと差が出る。とくに「誰がやったか」は、一次ソースが沈黙している間に憶測が流通しやすい。2026-09-06 時点で帰属は判明していない。

サプライチェーン全体での攻撃手口の分類は サプライチェーン攻撃の仕組み に整理してある。

本記事は 2026-09-06 時点の一次ソースに基づく。JetBrains は調査完了を宣言しているが、公式ページは今後も更新される可能性がある。最新の状況は下記の公式ブログを確認してほしい。

参照ソース

• Security Incident Affecting JetBrains Cadence — JetBrains 公式。Cadence インシデントの一次情報。最終更新 2026-09-03 19:00 CEST（調査完了を宣言）
• Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077) — JetBrains 公式。2026-07-27 の初回アドバイザリ。影響バージョン・修正版・パッチプラグイン
• CVE-2026-63077: Additional Guidance Following Reports of Active Exploitation — JetBrains 公式。2026-08-07 の追補。ログ確認用の例外文字列と未承認エージェントの指標
• NVD — CVE-2026-63077 — CVSS 9.8 / CWE-502 / 影響バージョン範囲の機械可読な定義
• CISA Known Exploited Vulnerabilities Catalog — KEV 登録日 2026-08-05 / 対応期限 2026-08-08
• The Hacker News「Attackers Breached JetBrains Cadence via Unpatched TeamCity, Extracting AWS Credentials」（2026-09-05）— 二次情報。本記事では一次ソースとの差分検証にのみ使用