MCPサーバーをご存じでしょうか。AIアシスタントにメール送信やデータベースクエリの実行など、手作業では面倒な処理を任せられる便利なツール群です。ただ、ここであまり語られていない重要な問題があります。私たちはこうしたツールに神レベルの権限を与えているという点です。しかも、それを作ったのは会ったこともなく、検証する手段もない人物です。それでも私たちのAIアシスタントは、そのツールを完全に信頼して使ってしまいます。
本稿を書いている理由はまさにここにあります。postmark-mcpというパッケージは、週あたり1,500回もダウンロードされ、何百もの開発者のワークフローに組み込まれています。バージョン1.0.16以降、このツールはひっそりと、すべてのメールを開発者個人のサーバーへコピーし続けていました。パスワードリセット、請求書、社内メモ、機密文書――あらゆるものが対象です。
これは実世界で確認された初の悪意あるMCPサーバー事例です。エンドポイントのサプライチェーン攻撃という攻撃対象領域は、企業にとって最大級のリスクになりつつあります。
リスクエンジンは何を検知したのか
事の発端はこうです。Koiのリスクエンジンが、バージョン1.0.16で不審な挙動の変化が加わったpostmark-mcpを検知しました。私たちの研究者が、リスクエンジンが検知したマルウェアに対していつも行っているように詳しく調査したところ、非常に憂慮すべき内容が判明しました。
表面上、このパッケージは完璧に見えました。開発者はパリ在住のソフトウェアエンジニアで、実名を使用し、GitHubのプロフィールには正当なプロジェクトが並んでいました。アニメアバターを使った怪しい匿名アカウントなどではありません。カンファレンスで一緒にコーヒーを飲みたくなるような、実在の評判ある人物だったのです。
15バージョンもの間――15回です――このツールは何の問題もなく動作していました。開発者たちはチームにこのツールを勧め合っていました。「Postmark連携用のこのMCPサーバー、なかなか良いよ」と。日々のコーヒーと同じくらい、開発者の日常的なワークフローに溶け込んでいたのです。
そしてバージョン1.0.16がリリースされました。231行目にひっそりと、私たちのリスクエンジンはこの一文を見つけました。
たった一行です。それだけで、以降すべてのメールに招かれざる同乗者が加わるようになりました。
興味深いことに、同じ名前を持つ完全に正規のGitHubリポジトリが存在し、Postmark(ActiveCampaign)によって公式に管理されています。攻撃者はそのリポジトリから正規のコードを拝借し、悪意あるBCCの一行を加えたうえで、同じ名前でnpmに公開したのです。典型的な成りすましの手口です。
もちろん、人生には色々なことが起こります。開発者が経済的な困難に陥ったのかもしれません。誰かから断れないような誘いを持ちかけられたのかもしれません。あるいは、ある日ふと「これをやったらバレずに済むのでは」と思い立っただけかもしれません。何が引き金となって、正当な開発者が突如として自分を信頼してくれた1,500人のユーザーを裏切る決断をするのか、私たちには本当のところは分かりません。
しかし、まさにそこが問題なのです。私たちにはそれを知ることも、予測することもできません。そして実際に起きたとき、多くの人は手遅れになるまで気付きすらしないでしょう。現代の企業にとって、この問題はさらに深刻です。セキュリティチームが従来型の脅威やコンプライアンス対応に注力する一方で、開発者たちは既存のセキュリティ境界の外側で、独自にAIツールを導入しています。こうしたMCPサーバーはAIアシスタント自体と同じ権限――メールへの完全なアクセス、データベース接続、API権限――で動作するにもかかわらず、資産管理台帳には現れず、ベンダーリスク評価もすり抜け、DLPからメールゲートウェイに至るあらゆるセキュリティ管理をも回避します。AIアシスタントが何カ月にもわたって静かに外部サーバーへメールをBCC送信していたと誰かが気付いたときには、被害はすでに壊滅的な規模に達しているのです。
影響の大きさについて
ここで実際にどれほどの規模の話をしているのか、整理してみましょう。
AIにメール処理を任せたいからMCPサーバーを導入する――それ自体は理にかなっています。時間の節約になり、生産性も上がります。良いことずくめに見えます。しかし実際にやっていることは、会ったこともない相手にメールフロー全体の完全な制御権を渡すことに他なりません。
影響の規模は概算するしかありませんが、次のように見積もれます。
- 週あたり1,500件のダウンロード
- 控えめに見て、実際に稼働しているのはそのうち20%程度
- 組織数にして約300
- 各組織が1日あたり10~50通程度のメールを送信していると仮定
- 1日あたり3,000~15,000通ものメールがgiftshop.clubへ直接流出している計算になる
そして、本当に問題なのはここです。この開発者は何もハッキングしていません。ゼロデイ脆弱性を突いたわけでもなく、高度な攻撃手法を用いたわけでもありません。私たちが自ら「このコードをフル権限で実行してくれ」と鍵を渡し、AIアシスタントに1日に何百回も使わせていたのです。これは私たち自身が招いた結果なのです。
長年セキュリティの仕事をしてきましたが、この問題は特に夜も眠れないほど気にかかります。見ず知らずの他人が作ったツールをインストールし、それが次のようなことをできてしまうのが「当たり前」だと、いつの間にか私たちは受け入れてしまっています。
- 私たちになりすましてメールを送信する(私たちの権限をフル活用して)
- 私たちのデータベースにアクセスする(すべてのデータベースに)
- 私たちのシステム上でコマンドを実行する
- 私たちの認証情報でAPIを呼び出す
そして、いったんインストールしてしまえば、あとはAIアシスタントがひたすら実行し続けます。レビュープロセスはありません。「このメールを本当にgiftshop.club宛てにBCCで送っていいのか」といった確認もありません。ただ盲目的に、自動的に実行されるだけです。何度も、何度も。1日に何百回も。
ここにはセキュリティモデルというものが事実上存在しません。サンドボックスもなければ、封じ込めもありません。何もないのです。ツールが「このメールを送信しろ」と言えば、AIはそれを送信します。「ついでにこの適当なアドレスにもコピーしろ」と言えば、AIはそれも実行します。疑問を差し挟むことは一切ありません。
postmark-mcpのバックドアは決して高度なものではなく、拍子抜けするほど単純なものでした。しかし、それこそがこの仕組み全体がいかに壊れているかを如実に物語っています。開発者一人、コード一行。それだけで、無数のメールが盗まれ続けたのです。
攻撃のタイムライン
フェーズ1: 正規のツールを構築する
バージョン1.0.0から1.0.15までは正常に動作します。ユーザーはこのパッケージを信頼します。
フェーズ2: 一行を追加する
バージョン1.0.16でBCCが追加されます。それ以外は何も変わりません。
フェーズ3: 収穫する
あとは腰を据えて、パスワードやAPIキー、財務データ、顧客情報を含むメールがgiftshop.clubへと流れ込むのを眺めるだけです。
このパターンには心底恐怖を覚えます。あるツールが何カ月もの間、完全に正当なものとして存在し得るのです。実運用の中で鍛え上げられ、ワークフローに不可欠な存在となり、チーム全体がそれに依存するようになります。そしてある日突然――マルウェアと化すのです。バックドアが発動する頃には、もはやそれはただのパッケージではなく、信頼されたインフラそのものになっているのです。
ちなみにgiftshop.clubというドメインは、どうやらこの開発者の別のサイドプロジェクトだったようです。しかし今では、まったく違う種類の「贈り物」を集める場所になっています。あなたのメールこそが、その贈り物なのです。
説明を求めて開発者に連絡を取りましたが、返ってきたのは沈黙でした。説明もなければ、否定もありません。何もなかったのです。ただし、行動は起こしました――残念ながら私たちが望んでいた種類のものではありませんでした。彼はnpmから当該パッケージを速やかに削除し、証拠を消そうとしたのです。
しかしここで重要なのは、npmからパッケージを削除しても、すでにインストール済みの端末からは削除されないということです。週あたり1,500件のダウンロードのすべてが、依然として侵害されたままです。今もなおgiftshop.club宛てにBCC送信を続けています。開発者はこの事実を承知しています。パッケージがnpmから消えたことで、被害者が自分たちがまだ感染したままだと気付かないことに賭けているのです。
MCPのモデル全体が根本的に破綻している理由
ここではっきりさせておきたいことがあります。MCPサーバーは通常のnpmパッケージとは違います。これらはAIアシスタントが自律的に利用することを想定して設計されたツールです。それこそがMCPの存在意義そのものなのです。
postmark-mcpをインストールするということは、単にpackage.jsonに依存関係を一つ追加するというだけの話ではありません。AIアシスタントに対し、「何かおかしい」と立ち止まって考えることなく、自動的に何百回も使うツールを与えているのです。
あなたのAIには、そのBCC欄を検知することはできません。メールが盗まれていることにも気付きません。AIの目に映るのは、正常に機能しているメールツールだけです。メール送信、成功。また送信、成功。その裏で、すべてのメッセージが静かに外部へ流出し続けています。来る日も来る日も、週を追うごとに。
postmark-mcpのバックドアは、一人の悪意ある開発者や週1,500件の侵害されたインストールだけの問題ではありません。これはMCPエコシステムそのものに対する警鐘なのです。
私たちは、素性も分からず検証もできず、信頼する理由もない人物が作ったツールに神レベルの権限を与えています。これらは単なるnpmパッケージではなく、最も機密性の高い業務へと直結するパイプラインです。それを、疑問を挟むことなく何千回も使用するAIアシスタントが自動的に動かしているのです。
このバックドアは、この記事を読んでいる今この瞬間も、メールを収集し続けています。私たちはこれをnpmに報告しましたが、恐ろしい問いが残ります。他にどれだけのMCPサーバーがすでに侵害されているのでしょうか。そして、それをどうやって知ることができるのでしょうか。
Koiでは、こうしたパッケージの挙動変化を検知しています。MCPエコシステムには組み込みのセキュリティモデルが存在しないためです。素性の分からない開発者にAIの能力を委ねる以上、必要なのは信頼ではなく検証です。私たちのリスクエンジンは、バージョン1.0.16でBCCの挙動が導入された瞬間にこのバックドアを自動的に検知しました。従来型のセキュリティツールであれば、まず検知できなかったはずの変化です。しかし検知はあくまで第一歩に過ぎません。私たちのサプライチェーンゲートウェイは、こうした悪意あるパッケージがそもそも環境に入り込まないようにします。開発者とnpm、MCPサーバー、ブラウザ拡張機能という無法地帯との間のチェックポイントとして機能し、既知の脅威をブロックし、不審な更新にフラグを立て、メールやデータベースアクセスなど機密性の高い操作に触れるパッケージについては承認を必須とします。他社が開発者の良識に期待するだけの間に、私たちは検証済みかつ継続的に監視された選択肢からしか選べない仕組みを構築しています。
postmark-mcpのバージョン1.0.16以降を使用している場合、あなたの環境はすでに侵害されています。直ちに削除し、メール経由で漏洩した可能性のある認証情報はすべてローテーションしてください。しかしそれ以上に重要なのは、利用しているすべてのMCPサーバーを監査することです。自問してみてください。あらゆる権限を委ねているそのツールを、実際に誰が作ったのか、あなたは本当に把握していますか。
警戒を怠らないでください。MCPに関しては、疑い深さこそが正しい判断力なのです。
IOC(侵害指標)
パッケージ: postmark-mcp(npm)
悪意あるバージョン: 1.0.16以降
バックドア送信先メールアドレス: phan@giftshop[.]club
ドメイン: giftshop[.]club
検知方法:
- メールログ内でgiftshop.club宛てのBCCヘッダーを確認する
- MCPサーバーの設定に予期しないメールパラメータがないか監査する
- postmark-mcpのバージョン1.0.16以降がnpmパッケージに含まれていないか確認する
対策:
- postmark-mcpを直ちにアンインストールする
- 侵害期間中にメール経由で送信された認証情報をすべてローテーションする
- 機密データが流出していないか、メールログを監査する
- 侵害が確認された場合は、適切な当局に報告する
翻訳元: https://www.koi.ai/blog/postmark-mcp-npm-malicious-backdoor-email-theft
