悪意のあるMCPサーバーと電子メールセキュリティ：新たなサプライチェーンの脅威

2025年9月、あるオープンソースのnpmライブラリに潜んでいたたった1行のコードが、サプライチェーンの安全性に関する我々の常識を覆した。これにより、悪意のあるMCPサーバーのメールセキュリティが、危険な新たな脅威として注目を集めることになった。

「postmark-mcp」と呼ばれるこのマルウェアは、1週間以上にわたり、毎日3,000通から15,000通の社内メールを攻撃者に転送し続けた。派手なゼロデイ攻撃などではなく、単なる基本的なBCC（隠しCC）ルールを、管理者権限をフルに活用して実行しただけだった。その結果、パスワード、社内請求書、顧客データ、有効な認証トークンなどが流出するという壊滅的な被害をもたらした。

これは、実環境における悪意のあるMCPサーバーへの侵入が確認された初の事例です。自律型AIエージェントが企業のパイプライン全体に普及するにつれ、巨大な死角が生じています。SPF、DKIM、および DMARC は、予測可能で人間主導のメールルーティングが主流だった時代に構築されたものです。Model Context Protocol（MCP）というパラダイムは、その防御態勢を根本から覆し、従来の境界線フィルターでは到底捕捉できない「内部者による脅威」という新たな層をもたらしています。

何が起きたのか ― ポストマーク・MCP事件

Postmark（ActiveCampaignが運営）は、パスワードのリセットや注文確認といった重要な自動通知の送信に、数千社の企業が利用する人気のトランザクションメールサービスです。生成AIの急成長に対応するため、GitHub上に公式のオープンソースリポジトリが開設され、開発者はModel Context Protocolを通じてAnthropic社のAIアシスタント「Claude」をPostmarkのインフラに直接連携できるようになりました。

攻撃の好機と見た悪意のある攻撃者は、「postmark-mcp」という名前の類似パッケージを公開した。これは単なるタイプミスによるドメイン乗っ取りなどではなく、手っ取り早くnpm installを実行しようとする開発者を罠にかけるために、意図的に名前を完全に一致させたものだった。

長期的な視点：信頼の構築

攻撃者は綿密に練られた長期戦略を展開した。15回にわたる連続したバージョンリリース（1.0.0から1.0.15まで）の間、このパッケージは問題なく動作した。公式リポジトリのコードを忠実に再現し、API呼び出しを完璧に実行し、警告を一切発しなかった。これにより、自動化されたサンドボックス検査を容易にすり抜け、セキュリティ追跡システムから基本的な信頼を獲得することができた。

ペイロードの起動

2025年9月17日、バージョン1.0.16のリリースに伴い、重大な被害が発生しました。index.jsの231行目の奥深くに、発行者が1行のコードを追加しました。この変更により、サーバーを経由するすべてのメール本文に隠されたBCCアドレスが追加され、そのコピーが攻撃者が管理するドメイン[giftshop.club]に転送されるようになりました。

このモジュールは検証済みのアプリケーション層内に存在していたため、本番環境のAPIキーへのアクセス権限をすでに有していました。この攻撃には、特殊な権限昇格の手法は一切必要ありませんでした。攻撃が成功したのは、コードが信頼された企業のパイプライン内で実行されていたためです。データ漏洩は2025年9月25日まで続き、その日、Koi Securityのリスクエンジンが、このライブラリに起因する異常な動作パターンを検知しました。

その影響

Koi SecurityとSnykによる事後監査の結果、このパッケージのダウンロード数は約1,643件に上り、これは週あたり約1,500件のアクティブなインストールに相当し、毎日データが漏洩していたことが判明した。

この問題が発覚すると、パブリッシャーはnpmからそのパッケージを削除しました。しかし、ここが本当の頭痛の種です。パブリックレジストリからパッケージを削除しても、稼働中の環境からは削除されないのです。 バージョン1.0.16を実行している稼働中のクラウドクラスタやコンテナパイプラインは、チームが追跡して手動で削除するまで、データ漏洩を続けました。Postmarkは直ちに声明を発表し、同社がこのパッケージを開発、承認、または保守していないことを明らかにしました。これはコードの欠陥ではなく動作上のバックドアであったため、正式なCommon Vulnerabilities and Exposures（CVE）識別子は割り当てられませんでした。その結果、検証されていない独自のMCPサーバーサプライチェーン攻撃の痕跡が残されることになりました。

もし、ご自身のチームがこのパッケージを導入したことがあると思われる場合は、これを重大なインシデントとして扱ってください。直ちにすべての環境からアンインストールし、このパッケージを経由したすべての認証情報とAPIキーを更新し、メールログを検索して、問題のドメイン宛てのBCCメールがないか確認してください。また、このパッケージの公開者のアカウント全体を確認することも重要です。同じ作成者が約31の他のパッケージを管理しており、そのいずれもが同様のリスクを抱えている可能性があります。

なぜMCPサーバーはメール攻撃の格好の標的となるのか？

モデルコンテキストプロトコル（MCP）は、エンタープライズAI向けの標準的な統合フレームワークとして急速に普及しつつあります。ガートナーは、2026年末までにAPIゲートウェイベンダーの75％が、自律型AIによる電子メールセキュリティを管理するためのネイティブMCPツールセットを統合すると予測しています。

「モデルコンテキストプロトコル（MCP）の統合」とは、具体的にはどのようなものなのでしょうか？MCPサーバーは、AIアシスタント（Claudeなど）と外部データリポジトリ、開発環境、サードパーティ製ツールを接続する、安全なAPIブリッジだと考えてください。AIエージェントは、複雑に絡み合ったカスタムAPIを個別に管理する代わりに、この統一されたプロトコルを利用して、データベースへのクエリ実行、CRMの確認、あるいはメール配信プロセスの自動調整などを自律的に行うことができます。

根本的な脆弱性：絶対的な信頼

MCPサーバーが本来の役割を果たすためには、長期的かつ広範な運用権限が必要です。スケジューリングやカスタマーサポートを自動化するためにAIエージェントをメールゲートウェイに接続する場合、そのエージェントに完全な読み取りおよび書き込みアクセス権を付与することになります。つまり、そのエージェントは、完全な代理権限を持つ従業員のように振る舞うことになります。

Koi SecurityのCTOであるイダン・ダルディクマン氏が指摘するように、組織は実質的に、身元が確認されておらず信頼できない外部の開発者が作成したバックエンドツールに、神モードとも言える管理者権限を委ねていることになる。

（SolarWindsのような）従来のソフトウェアサプライチェーン攻撃がインフラの深層を標的とするのとは異なり、サードパーティ製MCPサーバーのリスクには、インフラへのハッキングは一切必要ありません。攻撃者は、ユーザーを騙してモジュールをインストールさせるだけでよく、AIエージェントがそれを自律的に実行します。自動化されたワークフローを再確認する人間の介入がないため、侵害されたライブラリは、何日もかけて機密データを外部へ流出させても、一切の警告を発することなくやり過ごすことができます。

メール認証の課題――DMARCで守れるものと守れないもの

リスク対策チームがこうしたAIによるサプライチェーン攻撃メールの脅威から防御しようと奔走する中、多くの人がSPF、DKIM、DMARCといったプロトコルがあれば被害を食い止められると考えている。しかし、これらの対策が実際にどのような役割を果たしているのか、またどこに脆弱性があるのかを、しっかりと見極める必要がある。

DMARC、SPF、およびDKIMが防ぐことを目的として設計されたもの

SPF、DKIM、DMARCからなる中核機能は、ドメインのなりすましを防止し、悪意のある攻撃者が貴社のブランド名を利用してメールなりすましやBEC（ビジネスメール詐欺）キャンペーンを実行することを阻止するために構築されました。

• SPFは、送信メールサーバーのIPアドレスがお客様のDNSレコードで承認されているかどうかを確認します。
• DKIMは、メッセージが送信中に改ざんされていないことを証明するために、ヘッダーに一意のデジタル署名を追加します。
• DMARCはこれらを結びつけ、受信サーバーがエラーをどのように処理すべきかについてルールを適用します。

postmark-mcpのエクスプロイトでは、これらの制御は迂回されたのではなく、まったく無意味なものとなっていました。悪意のあるパッケージは正規の企業用アプリ内に埋め込まれていたため、有効なAPIキーを使用して、承認されたPostmarkサーバーを経由してメッセージを送信していたのです。盗まれたメールにはすべて完璧なDKIM署名が付与されており、SPFチェックも問題なく通過していました。ここには皮肉な事実があります。その有効なDKIM署名のおかげで、攻撃者自身の受信サーバーでさえ、盗まれたメッセージが本物であることを確認できてしまったのです。

メール認証が部分的に役立つ場面

メール認証でできること、できないこと

DMARC、SPF、およびDKIMは、なりすまし対策として設計されたものであり、内部関係者による情報漏洩対策として設計されたものではありません

DMARCレポートが持つ可視化の力

初期のコード注入を阻止することはできませんが、十分に整備されたメール認証環境は、フォレンジック調査において極めて重要な可視性を提供します。これは、詳細なDMARCレポート（RUA/RUF）によって実現されます。

適切に設定されていれば、これらのレコードにより、ドメイン上でアクティブなすべてのIPアドレスと送信サービスに関する明確なマップが得られます。集計レポート（RUA）は送信元ごとの送信量を要約し、フォレンジックレポート（RUF）は個々の障害に関する詳細情報を記録します。SecOpsチームがこれらのデータストリームを継続的に監査していれば、送信されるトランザクション量に原因不明の急激な増加が見られた場合に、それを検知することができます。こうした異常を追跡することは、統合機能からデータが漏洩していることを知らせる「煙探知機」のような役割を果たします。

厳格な執行を伴うセーフティネットの構築

ドメインを厳格な「p=reject」設定のDMARCポリシーに移行することは、二次的な被害を防ぐための重要な安全策となります。これにより、社内のMCPサーバーからのBCC送信を阻止することはできませんが、攻撃者が盗み出した情報を悪用することを防ぐことができます。「reject」ポリシーを設定することで、脅威アクターが流出した請求書や顧客データを利用して、実際のドメインを悪用し、貴社のクライアントやパートナーに対して高度に標的を絞ったなりすましフィッシング攻撃を仕掛けることを阻止できます。

真のギャップ――資格と権限の管理

本質的に、今回のセキュリティ侵害は認証プロトコルの問題ではなく、IDとアクセス管理の不備によるものでした。この攻撃が成功したのは、検証されていないソフトウェアが、正当な高権限のAPIキーにアクセスできていたためです。

ここでの主な防御策は、コードの依存関係監査と認証情報の適切な管理です。しかし、アクティブな可視化レイヤーなしに自律型AIツールを導入すると、状況が全く把握できなくなってしまいます。継続的なDMARCモニタリングは、悪意ある攻撃の兆候となる行動の異常を検知するために必要な、能動的な安全網を構築します。

悪意のあるMCPメール攻撃から組織を守る方法

悪意のあるMCPサーバーに対する電子メールセキュリティ対策には、以下のような運用上の措置が必要です：

1. MCPサーバーの導入状況を点検する

追跡していないものは保護できません。メール設定に関連するすべてのアクティブな連携機能、プラグイン、接続ポイントについて、明確な一覧を作成してください。

• その統合が、公式ベンダーのリポジトリから提供されているものか、それともnpmやPyPI上の検証されていないコミュニティパッケージから提供されているものかを確認してください。
• 各統合がどのデータやエンドポイントにアクセスできるかを明確に記録する。
• mcp-scan などのオープンソースのセキュリティツールを使用して、環境内の挙動の異常を列挙・分析してください。

2. AIメール連携機能に最小権限の原則を適用する

自動化ツールに無制限の管理者権限を与えるのはやめましょう。

• APIキーの権限範囲を限定し、必要なアクション（例：通知の送信）のみを許可すると同時に、メールボックスの読み取り・書き込み権限については明示的にブロックするようにします。
• APIキーのローテーションスケジュールを厳格に実施し、依存関係からアラートが通知された場合は直ちに認証情報を無効化する。
• ファイアウォールおよびネットワークセキュリティポリシーを使用して、MCPサーバーからの送信先を制限し、既知の社内メールAPIエンドポイントのみを許可リストに登録してください。

3. DMARCレポート機能を有効にし、異常を監視する

DMARCの集計データを積極的に分析していない場合、運用面において重大な盲点が生じています。専用のDMARCアナライザーを導入することで、チームは継続的な可視性を確保でき、データストリームの追跡やトラフィック量の基準値の把握が可能になります。また、深刻な被害が発生する前に、送信されるトランザクションメールの急激な増加を検知してアラートを受け取ることができます。

4. DMARCをp=rejectで適用する

ドメインの設定を脆弱な「p=none」のままにしておいても、実質的な保護にはなりません。厳格な「p=reject」の適用レベルに移行することで、たとえ攻撃者が侵害された連携機能を通じてメールの内容を盗み出したとしても、その盗んだ情報を悪用して、貴社の公式ブランドドメインを装ったなりすましキャンペーンを展開することは絶対にできなくなります。

5. 展開前にMCPサーバーを検証する

MCPサーバーモジュールについては、企業のインフラストラクチャにおけるその他の特権的なコンポーネントと同様に、厳格な審査を行う必要があります。本番環境へ移行する前に、発行元の実績を確認し、パッケージ内容をベンダーの公式ドキュメントと照合し、基盤となるソースコードを精査してください。

リスクを最小限に抑えるため、未検証のコミュニティ製パッケージは避け、ベンダーによって検証済みの統合ソリューションを利用してください。自動化を導入するチームにとって、PowerDMARC MCP Serverのような検証済みのベンダー製ソリューションを採用することは、安全な企業運営のために特別に構築された、認証済みのセキュアな統合レイヤーを確保することにつながります。

全体像 – MCPセキュリティが電子メール脅威の次の局面を決定づける

postmark-mcpライブラリの脆弱性は、設計上、極めて単純なものでした。開発者は1人、基本的な名前照合の手法、そして1行の隠されたコードだけでした。それにもかかわらず、この脆弱性は広範囲にわたるデータ漏洩を引き起こしました。企業が自律型AIツールを急速に導入し、MCPがソフトウェアアーキテクチャの標準となっていくにつれ、脅威グループは必然的に、はるかに高度な攻撃を展開するようになるでしょう。

セキュリティチームは、いくつかの新たな脅威の経路に備える必要があります：

• 間接的なプロンプト注入：受信トレイを読み取るAIエージェントを操作し、機密データの誤った転送や内部キーの漏洩を引き起こすよう仕向けることを目的とした悪意のあるメールを送信する攻撃者。
• 悪意のあるワークフローツール：攻撃者は、一見便利そうなAI生産性向上ツールを公開し、バックグラウンドで密かに認証情報やトークンを収集している。
• 高価値な類似ドメイン：開発者向けパッケージネットワーク上で、企業のCRM、人事、財務システムとの連携を標的とした、高度なタイポスクワッティング攻撃。

電子メールは、企業内コミュニケーション、本人確認（パスワードのリセット）、そして重要な業務データの交差点に位置しているため、非常に脆弱です。AIとこのインフラを橋渡しするMCPサーバーは、これら3つすべてにアクセス可能です。

結論

電子メールによる脅威の状況は、単なる外部からのフィッシング攻撃をはるかに超えたものへと変化しています。Postmark-MCPのインシデントは、組織が今や、信頼された内部環境の中で静かに活動するAIネイティブなサプライチェーン脅威に直面していることを証明しています。こうした統合型攻撃は、有効な認証情報を利用して従来のフィルタを迂回するため、悪意のあるMCPサーバーに対する電子メールセキュリティ対策は、今やすべてのCISOの優先課題となるべきものです。

企業のセキュリティを確保するには、厳格なアクセス制御と継続的なデータ追跡のバランスをとることが不可欠です。厳格なポリシーと詳細なレポート分析を組み合わせることで、異常な送信量の検知や不正な連携の特定が可能となり、データが永久に失われる前に未然に防ぐことができます。

自動化されたシステムを放置してはいけません。今すぐ、アプリケーション層に潜む脅威からドメインを守りましょう。ドメインを名乗ってメールを送信しているすべての送信元を把握し、PowerDMARCのDMARCアナライザーで監視を開始してください。

よくあるご質問

ちょっと待って、もし私のメールがSPFとDKIMを通過しているなら、どうしてそれが悪用になるんですか？

なぜなら、その呼び出しは社内のシステムから発信されているからです。悪意のあるパッケージは、どこかの不正なサーバーからあなたのドメインを偽装しているわけではありません。それは、あなたが信頼しているアプリケーション環境のまさに内部に潜み、あなたの実際の正当なAPIキーを乗っ取っているのです。外部から見れば、あなたのサーバーがそのメールを正当に送信したように見えるため、暗号化された境界プロトコルもそれを許可してしまうのです。これはサーバーのなりすまし問題ではなく、データ流出の問題なのです。

DMARCではデータの漏洩を防ぐことができないのなら、なぜ有効にする必要があるのでしょうか？

RUAのDMARC集計レポートは、ネットワークの煙探知機のようなものだと考えてください。もしMCPサーバーが、何千通もの運用メールを第三者の受信箱に密かにBCCで送信し始めた場合、トランザクションメールの送信量は劇的に急増することになります。DMARCのデータフィードを積極的に監視していれば、その急激な送信量の変化は一目瞭然であり、SecOpsチームに早期の警告を発し、稼働中のコードの依存関係を監査するきっかけとなります。

私たちのチームでは、サポートメールを処理するためのAIツールが必要です。連携機能を完全に停止させることなく、これを安全に実現するにはどうすればよいでしょうか？

AIによる自動化を遮断する必要はありません。必要なのは、その周りに適切な枠組みを設けることだけです。まず、MCPサーバーをリスクの高いインフラコンポーネントとして扱うことです。コードレビューを経ずに、コミュニティで公開されているスクリプトをそのままインストールしてはいけません。次に、APIキーの権限を極めて詳細かつきめ細かく設定します。エージェントがサポート応答の送信のみを必要とする場合、そのAPIトークンを厳重に制限し、データの大量読み取り、アカウント作成、BCCルールの実行が物理的に不可能なようにします。 最後に、検証されていないコミュニティのクローンではなく、PowerDMARC MCPサーバーのような検証済みのベンダー統合ソリューションを利用するようにしてください。

開発チームが誤って悪意のあるMCPサーバーをインストールしてしまったかどうかを確認するにはどうすればよいですか？

まず第一に、ソフトウェア構成分析（SCA）スキャンを実行するか、mcp-scan などのオープンソースツールを使用して、稼働中の環境を把握します。 npmやPyPIなどの公開パッケージレジストリを精査し、通信パイプラインを処理するサードパーティ製で検証済みのコミュニティライブラリがないか確認してください。公式のPostmarkリポジトリやセキュアなPowerDMARC MCPサーバーのように、検証済みの企業ベンダーによって直接公開・署名されていないライブラリについては、コードが手動で監査されるまではリスク要因として扱う必要があります。

• について
• 最新記事

ミレーナ・バグダサリャン

コンテンツスペシャリストPowerDMARC

ミレーナは、IT、サイバーセキュリティ、バーチャルイベントなどに関する魅力的なコンテンツ制作に7年以上の経験を持つ、熟練したライター兼コンテンツ制作者です。ニューヨーク大学アブダビ校、UWCチャイナ校、カレッジ・オブ・ヨーロッパなどの名門校を卒業。

最新記事 by Milena Baghdasaryan(全て見る)

• カスタマーサポートのメールセキュリティ：偽の返信、アカウント乗っ取り、データ漏洩を防ぐ方法 - 2026年6月12日
• 悪意のあるMCPサーバーとメールセキュリティ：新たなサプライチェーンの脅威 - 2026年6月9日
• 新規登録ドメインのメール認証設定方法 - 2026年6月2日