MCPサーバーはご存知でしょうか。AIアシスタントにメール送信やデータベースクエリの実行をさせるなど、面倒な作業を任せられる便利なツール群です。しかし、あまり語られていない事実があります。私たちはこうしたツールに「神モード」の権限を与えているのです。しかも、会ったこともなく、検証しようがない人物が作ったツールに対してです。私たちのAIアシスタントはどうしているかというと、ただ…信頼しているだけです。完全に。
だからこそ、この記事を書いています。postmark-mcp——毎週1,500回ダウンロードされ、何百もの開発者のワークフローに組み込まれているこのツールは、バージョン1.0.16以降、静かにすべてのメールを開発者個人のサーバーへコピーし続けていました。パスワードリセット、請求書、社内メモ、機密文書——あらゆるものが対象です。
これは実世界における初のマルウェア混入MCPサーバーの発見事例です。エンドポイントのサプライチェーン攻撃という攻撃対象領域は、じわじわと企業にとって最大のリスクになりつつあります。
私たちのリスクエンジンは何を検知したのか
ことの始まりをお話しします。Koiのリスクエンジンがpostmark-mcpのバージョン1.0.16で挙動の不審な変化を検知し、フラグを立てました。リスクエンジンが検知したマルウェアはすべて調査する私たちの研究者チームが詳しく調べたところ、非常に憂慮すべき事実が判明しました。
表面上、このパッケージは申し分のないものでした。開発者はパリ在住のソフトウェアエンジニアで、実名を使用し、GitHubプロフィールには正当なプロジェクトが並んでいました。アニメアバターを使う怪しい匿名アカウントではありません。実名と実績を持つ、カンファレンスで気軽にコーヒーを飲めそうな、れっきとした人物だったのです。
15バージョンもの間——15回です——このツールは問題なく機能していました。開発者たちは「Postmark連携ならこのMCPサーバーがいいよ」とチームに勧め合っていました。毎朝のコーヒーと同じくらい信頼される、開発者の日常ワークフローの一部になっていたのです。
そしてバージョン1.0.16がリリースされました。231行目に埋め込まれていたのが、私たちのリスクエンジンが発見したこの一文です。
たった一行。それだけで、すべてのメールに招かれざる同乗者が付くようになりました。
実は、Postmark(ActiveCampaign)が公式に管理している、まったく同名の正規のGitHubリポジトリが存在します。攻撃者はその正規リポジトリのコードをそのまま流用し、悪意ある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で送っても本当にいいんですか?」という確認もありません。ただ盲目的に、自動的に実行されるだけです。何度も、何百回も。
ここには文字通り、セキュリティモデルというものが存在しません。サンドボックスもなければ、封じ込めの仕組みもありません。何もないのです。ツールが「このメールを送信せよ」と言えば、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
