セキュリティ事故分析「JetBrains悪性AIプラグイン事件」と非保持型権限委譲

0. はじめに

この記事は、セキュリティ関連のニュースを取り上げ、それに対して非保持型権限委譲をどのように適用できるか考察する技術記事です。

非保持型権限委譲については、以下の記事を参照してください。

1. JetBrains悪性AIプラグイン事件

2026年6月、JetBrainsは、Marketplaceで公開されていた15個のサードパーティ製AIプラグインが、利用者の入力したAIプロバイダのAPIキーを盗む目的で作られていたと公表しました。¹

これらのプラグインは、AIによるコード補助、コードレビュー、テスト生成、コミットメッセージ生成など、通常のAIプラグインとして動作していました。

利用者はプラグインの設定画面にAPIキーを入力します。

プラグインはそのキーを正規の設定情報として保存する一方、攻撃者のサーバーにも送信していました。

2. 正常な処理の組み合わせでAPIキーを盗む

プラグインが行っていた個別の処理は、一般的なものでした。

• 設定画面を表示する
• APIキーを受け取る
• 設定を保存する
• JSONを生成する
• 外部サーバーと通信する
• AIプロバイダを呼び出す

この攻撃の巧妙な点は、APIキー入力欄から、攻撃者サーバーまでのデータの流れにあります。
一見正常な各機能に、窃取処理を一つ追加するだけで攻撃が成立するため、単純な禁止API検査や動作確認では検出しにくかったようです。

盗んだキーの再販売疑惑

プラグインには有料機能もあり、利用者が少額を支払うと、攻撃者サーバーから別のAPIキーが返され、そのキーを使ってAIプロバイダを呼び出す処理が確認されています。

Aikidoは、無料利用者から集めたキーを有料利用者に配布する、再販売サービスを構築していた可能性を指摘しています。

3. X509TrustManager

悪性プラグインは、独自のX509TrustManagerも設定していました。
X509TrustManagerは、HTTPS通信先のサーバー証明書を検証する機能を持ちます。

証明書を無条件に信頼するようX509TrustManagerを設定すると、自己署名証明書や信頼されていない証明書を使用するHTTPSサーバーにも接続できます。

ただし、今回確認されたAPIキー送信先は平文HTTPだったため、この機能はAPIキー窃取に必須ではありませんでした。
この処理はAPIキー窃取自体には不要でしたが、サードパーティプラグインがIDEのJVM全体へ影響する設定を変更できたことを示しています。

4. 問題はプラグインがAPIキーを保持すること

このように見ていくと、JetBrainsの事件は、正常を装ったプラグインが秘密情報を盗んでいた事件でした。

どのようにすれば、このような悪意あるプラグインから、秘密情報を守れるのでしょうか？

公開前の検査で厳しくチェックしたとしても、プラグインが動作を偽装していると、今回の事件のように検査をすり抜けてしまいます。

問題の本質は、プラグインにAPIキーを渡すことにあります。

そもそも秘密情報を持たなければ、プラグインに取られるものがありません。

5. 分離されたアプリ内ブラウザによる非保持化

JetBrainsのIDEに非保持型権限委譲を適用する場合、IDEプロセスから分離されたアプリ内ブラウザを用意し、プラグインはそのブラウザを経由してAIサーバーを利用する構成が考えられます。

構成要素を単純化すると、次のようになります。

• AIサーバー
  • 秘密鍵を保持
• プロセス分離されたアプリ内ブラウザ
  • IDEプロセスから分離され、プラグインからセッション領域へアクセスできないこと
• AIプラグイン
  • AIサーバーの公開鍵を保持

利用者は、アプリ内ブラウザ上でAIサーバーへログインします。
プラグインは、共通鍵を生成し、AIサーバーの公開鍵で暗号化し、ブラウザに送信します。
ブラウザはログイン後のセッション上で、プラグインから渡された暗号化共通鍵を、AIサーバーに送信します。
AIサーバーは、秘密鍵で暗号化共通鍵を復号化し、共通鍵とセッションを対応付けます。

AI機能を利用するとき、プラグインは共通鍵で認証した処理要求をアプリ内ブラウザへ渡します。
ブラウザは、自身が保持する認証済みセッションを使って要求をAIサーバーへ中継します。

プラグイン
  ↓ 共通鍵で認証した要求

アプリ内ブラウザ
  ↓ ログイン済みセッションで中継

AIサーバー

この構成では、CookieやセッションIDなどの認証情報はアプリ内ブラウザに隔離され、プラグインから直接アクセスできません。また、AIサーバーを利用するためのAPIキーをプラグインへ発行する必要もありません。

悪性プラグインが共通鍵を外部へ送信したとしても、その共通鍵に対応するブラウザセッションが存在しない別端末からは利用できません。

このように、プラグインにAIサーバーの認証情報を保持させず、認証情報の漏えいと、盗んだ権限による別端末への横展開を防止します。

6. Marketplace審査ではなく構造で防ぐ

JetBrainsは今回の事件を受け、該当プラグインの削除や公開者アカウントの停止、検査ルールの強化を行いました。

こうした対応は必要ですが、Marketplaceの審査だけで同様の攻撃を完全に防ぐことは難しい。

AIプラグインにとって、APIキーの入力、設定情報の保存、外部サーバーとの通信は、いずれも正規の機能です。
悪性プラグインとの差は、入力されたAPIキーを攻撃者のサーバーにも送信していたことにあります。

正規機能と悪性動作の差が小さい以上、公開前の審査ですべてをチェックすることには限界があります。

構造の転換

プラグインが悪性であっても、再利用可能な認証情報を取得できない構造へ転換する必要があります。
非保持型権限委譲では、プラグインに秘密情報を安全に保存させるのではなく、秘密情報を持たなくても機能するように設計します。

悪性コードを検出する防御に加えて、検出をすり抜けても被害が横展開しない仕組みを用意することが重要です。

1. JetBrains Marketplace Ecosystem Security Update: Addressing Malicious Third-Party AI Plugins
   https://blog.jetbrains.com/platform/2026/06/marketplace-ecosystem-security-update-malicious-ai-plugins ↩