Postmarkのバックドアがメールをダウンロードしている

 (koi.security)
2 ポイント 投稿者 GN⁺ 2025-09-28 | 1件のコメント | WhatsAppで共有
  • 最近、postmark-mcp モジュールで悪意ある挙動が発見された
  • 1.0.16バージョンから、メールを開発者の外部サーバーへコピーするコードが追加された
  • 数百の組織の機密メールが漏えいしうる構造的な脆弱性が明らかになった
  • MCPサーバーの信頼モデル不在により、サプライチェーン攻撃のリスクが高まっている
  • すべてのMCP利用者は直ちに点検と削除対応が必要である

MCPサーバーの実態とpostmark-mcp事件の概要

  • MCPサーバーは、AIアシスタントがメール送信、データベースクエリ実行などの反復作業を自動処理するためのツールである
  • これらのツールは非常に高い権限で動作し、開発者が作成したコードをほぼ信頼だけでインストールしており、検証体制は事実上存在しない
  • 人気パッケージの postmark-mcp は、公式Postmark GitHubリポジトリからソースコードを持ってきて、悪意あるBCCの1行を追加したうえで、npmに同じ名前で公開していた
  • 1.0.16バージョンから、通常どおり動作するコードに1行が追加され、すべてのメールが開発者個人のサーバー（giftshop.club）へコピーされる機能が動作していた
  • つまり、パスワードリセット、請求書、社内メモ、機密文書に至るまで、すべてのメール情報が露出する事故である

異常挙動の検知と攻撃の構造

  • KoiのRisk Engineが1.0.16バージョンで異常な兆候を検知した
  • 開発者の身元はGitHubなどでは正常に見え、初期の15バージョンは問題なく動作して信頼を築いていた
  • 1.0.16で、たった1行のコードにより重要情報を外部へ流出させる機能が追加された
  • 攻撃者はコードのコピーと同時に、既存開発者になりすます手法（Classic impersonation）を用いた
  • 既存で正常に使われていたツールが、ある時点から信頼ベースのインフラとして定着し、その後に悪性動作を行うようになった

メール漏えいの影響と手口

  • おおよそ週1,500回のダウンロードがあり、実際に約20%が活発に利用されていると仮定すると、数百の組織が露出対象である
  • 毎日3,000〜15,000件のメールが giftshop.club に送信されていた規模と推定される
  • 利用者はツールの挙動を逐一検証せず、AIアシスタントに実行の大半を自動的に任せている
  • 別個のセキュリティモデル、サンドボックス、検証プロセスがまったく存在しない
  • 開発者がnpmからパッケージを削除したものの、すでにインストール済みの利用環境では削除の効果がなく、データ流出は継続している

攻撃段階の分析

  • 第1段階: 正常ツールの配布

    • 1.0.0〜1.0.15までは問題なく動作し、信頼を蓄積

  • 第2段階: 悪性コードの挿入

    • 1.0.16でBCCを1行追加し、外部へメールをコピーする機能を適用

  • 第3段階: 情報収集

    • giftshop.club へ、パスワード、APIキー、金融/顧客データなどが流出

  • 開発者とは連絡が取れておらず、npmからパッケージを削除したが、すでに導入済みの環境での被害は継続している

MCPエコシステムの構造的欠陥

  • MCPサーバーは一般的なnpmパッケージとは異なり、AIアシスタントが自動で数百、数千回呼び出す高リスクツールである
  • コードの悪性有無をAIや既存のセキュリティソリューションが検知できず、信頼のみに依存している
  • MCPエコシステム全体が、匿名の開発者に危険資産へのすべての権限を委任する危険な構造になっている
  • 挙動変化の検知による攻撃識別と、サプライチェーンゲートウェイなどのセキュリティ制御が必要である
  • KoiはRisk Engineとゲートウェイにより、同様の悪性パッケージの流入遮断と検証を進めている

対応策とIOC

  • 悪性パッケージ: postmark-mcp (npm)
  • 悪性バージョン: 1.0.16以上
  • 漏えい先メール: phan@giftshop[.]club
  • ドメイン: giftshop[.]club

検知方法

  • メールログで、giftshop.club が BCC として送信された痕跡を確認
  • MCPサーバー設定で、想定外のメール転送パラメータを点検
  • postmark-mcp 1.0.16以上のバージョンのインストール履歴を精査

対応と復旧

  • postmark-mcp を直ちに削除
  • 侵害期間中にメールで共有したすべての認証情報をローテーション
  • 流出した機密情報に関するメールログを全面調査
  • 被害事実を確認した場合は、直ちに所管当局へ報告

結論と勧告

  • すべてのMCPサーバーについて、開発者の身元確認、コード検証、セキュリティ点検の手順を必ず実施する必要がある
  • MCP（自動化AI補助インフラ）の特性上、最低限の不信モデルの適用と継続的モニタリングが必須である
  • postmark-mcp 1.0.16以上の利用者は、即時削除とセキュリティ対応が必須である
  • 信頼ベースの利用は、そのままサプライチェーン攻撃のリスクに直面することを念頭に置く必要がある
  • Paranoia（不信/疑念）を基本方針として受け入れることが、MCP活用における合理的な戦略である

関連記事

1件のコメント

 
GN⁺ 2025-09-28
Hacker Newsのコメント
  • Thunderbird拡張機能のバックドアとこの事件が何が違うのか気になる。以前Thunderbird拡張のメンテをしていたとき、興味を失ってくると、ある人物が何度か実際に貢献したあと、突然しつこくプロジェクトを引き継がせろと強く要求してきた。結局、見ず知らずの人に何万件ものメールボックスの鍵を渡すなんてありえないと思って断った。そもそも人々が私をそこまで信頼していたこと自体おかしいが、少なくとも私は善良な人間ではあった
    • 私もまったく同じ考えだ。これはMCPのせいではなく、あらゆるソフトウェアに同じように当てはまる問題だ。結局のところ、開発者と提供者を信頼するしかない。Microsoftが私のOutlookメールをコピーするのを防ぐことはできないし、GoogleがGmailをコピーするのを防ぐこともできない。オープンソースだからといって「多くの目」がコードをレビューすると言っても、人気プロジェクトならともかく、それでもリスクは残る。結局ほとんどの人は開発者をただ信頼しているだけだ。この問題はソフトウェアと同じくらい古い慢性的な課題だ
    • 君の言っている状況だと、Zuckerbergのプライバシーに関する発言を何度も思い出す。なぜ私たちが無条件に誰かにデータとプライバシーを預けてしまうのか、考える必要がある
    • 酔った見知らぬ人を車に乗せて家まで送った経験が何度もある。だから、そういう見知らぬ人の車に乗るのは本当に危険だといつも伝えている。正直、私みたいに時間に余裕のある善良な人間にたまたま出会えたのは幸運だ。地元の小さなバーに遅い時間に行くタイプなので、こういうことがよく起きるようだ
  • npmの単一ダウンロードがそのまま固有の組織1つを意味するという前提には同意できない。その数字は本当に誇張されている。npmでの1ダウンロードは、誰か（npm iコマンドを実行する人）または何か（自動化環境）がインストールしたというだけだ。実務ではCIの設定が雑だと、実行ごと、下手するとステップごとにnpm iが走る。だから1,500回のダウンロードも、実際にはたった2社から発生しているだけかもしれない。片方は開発者がPoC用に使っていて、もう片方はCI設定がめちゃくちゃなケースだ。公式リポジトリを見ても watch 1、fork 0、star 2 しかない https://github.com/ActiveCampaign/postmark-mcp。MCPやサプライチェーンの問題自体は深刻だが、今回のケースの実際の影響はほぼゼロだ
    • 同じ理屈でいけば、人気のPythonパッケージのダウンロード数もそのうち地球上の全人類—子どもから高齢者、コンピュータが何かも知らない人まで—が1人1回ずつダウンロードした水準になりそうだ。https://pypistats.org/top
  • この記事自体は良いが、なぜわざわざChatGPTで要約したAI翻訳版を読まなければならないのかわからない。単に元のプロンプトを見せてくれればいい。今の形は無駄に遅く、ユーザーを軽視している感じがする
    • 君もそう感じていたと知って安心した。私はAIが介入した文体が大嫌いなのだが、友人の中にはまったく気づかないか、気にしない人もいるようだ
  • 最近よく見かけるが、私たちはこうしたツールに神のような権限を委ねることについて十分に話していない気がする。作った人の顔も知らないツールなのに、そのまま信じて任せている。AIアシスタントも同じだ。みんなただ100%信頼してしまう。こういうことを指摘する記事はあるが、「銃口を自分の足に向けて引き金を引けば足を撃つって知ってましたか??」みたいな感じだ。あまりに当たり前すぎて、記事は大した内容でもないことでコンテンツを作っているように見える。本当にここまでわかっていない人が多いのか、それとも記事を書くために無理やり作っているのか気になる
    • 少し前に、AIコードアシスタントが会社の本番データベースを吹き飛ばしたという記事もあった https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. レイヤーがいくつかあって、1) その創業者はAIツールを全面的に信頼して自分で被害を受けた。つまり本当に無知だったわけだ。2) しかも本番DBに開発環境から直接アクセスできるよう開けていた。どのみちいつかは事故が起きる環境だった
    • HNユーザーにとっては当たり前の話でも、世の中の大半にとってはまったく当たり前ではない。こういう記事はそういう人たちに必要なコンテンツだ。実際、MCPサーバーやAIエージェントの設計では、そもそもセキュリティが議論すらされておらず、構造的に安全ではない。今後変わるかどうかはわからないが、それまでは繰り返し知らせるのが最善だ
    • 「人々は本当にここまで鈍感なのか？」基本的なSQL injectionですら毎年莫大な被害を出し続けていて、今でもOWASP上位にある。SQL injectionも結局はデータベースに神のような権限を与える話で、仕組みを理解していないことから生じる問題だ。AIエージェントの行為権限も、ユーザーから見ると見えにくい可能性がある
    • MCPによるこうした無分別なアクセスが大規模に起きているという事実は、もっと広く議論されるべきだ。普段は慎重な人でさえ、危険性をきちんと認識できていない場合が多い
    • 昔は、メールクライアントがインターネット上の誰かが送ったスクリプト入りメールを実行することが「自動化革命」と呼ばれていた。昔はまた、子どもにTVの代わりにインターネットを使わせる方が健全だとも思われていたが、それがどういう結末になったかはみんな知っているだろう？
  • 「ランダムな誰かが作ったツールをインストールするのが当たり前になった状況」とあるが、実際にはWindows XP時代から、CDリッピングソフトやBonzi Buddyのようなものを何の心配もなく入れてきた。利便性は常にセキュリティより優先されてきた。結局いちばん重要な教訓は、なぜいまだに『サンドボックス、サンドボックス、サンドボックス』が現実になっていないのか、という問いだ。今回の件では、AIが既存のあらゆるセキュリティ原則を完全に工場出荷状態へ戻してしまったように見える
    • 「人はセキュリティより利便性を選びがちだ。なぜいまだにサンドボックスが現実になっていないのか」という問いへの答えは、サンドボックスの実装が簡単ではないからだ。そしてここでいう『簡単』とは、OSが標準で提供していることを意味する
  • ユーザーがGMailで、人間が開かなくてもAIにプロンプトインジェクションされたスパムメールを送ることもできる https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
  • このブログ記事は読むのがつらすぎる。AIが手を入れた感じがする。不要な文や装飾が多すぎる。残念ながらテーマ自体は興味深い
  • サプライチェーンセキュリティの問題では、npmパッケージがほぼ必ず言及される。npmが最も広く使われ、攻撃者にとっても動機が大きいからだろうが、それでも苦々しさは残る
    • OpenAIもnpmでCodex CLIを配布している。Rustで作られているのにnpmパッケージを使っている。個人的には理にかなっていないと思う。それでも代替手段の方が不便なのだろう
    • そういう理由で、私はstdio MCPサーバーを動かさない。すべてのMCPは、Dockerコンテナで隔離されたVMホスト上で、信頼しないVLANに載せている。そして接続はSSE経由のみにしている。もちろんプロンプトインジェクションには脆弱だが、主要ブラウザープロファイルやメール、クラウドアカウントには接続しない。機微情報とは完全に分離している
    • 上のコメントがあまりに支持を集めすぎていて、この記事の主な示唆がそれであるかのように誤解されるのは望ましくない。そう受け取ると本質が見えなくなる
  • もしかすると開発者が本当に意図的にやったわけではないのかもしれない。私もデバッグコードを入れたままリリースしたことが何度かある。単なる plain bcc なら、本当にデバッグコードだった可能性もある
    • 私もそれを言いに来た。正直、自分のメールアドレスをあんなふうに露骨に残しておくとは思えない。2025年にもなってテスト用に個人のGmailを使うのは恥ずかしいことだ。そしてこれはMCP固有の問題ではなく、どんなパッケージでも起こりうる
    • パッケージ削除という反応も、正直セキュリティ問題に初めて直面した初心者開発者の典型的な対応だ。悪意ではなく単なるデバッグミスだったなら、重要なのはコミュニケーションだ。悪性バージョンを取り下げ、パッチを配布し、ブログやここHN、ソーシャルメディアなどの公開チャネルで説明することが信頼回復への道だ。正確な事件のタイムライン（そしてOPのようなAIが書いた要約ではなく）も、信頼回復に役立つ
  • MCPサーバーの問題も危険だが、この種の攻撃はsmtpパッケージのような外部依存を使うあらゆる場面で起こりうると思う
    • とはいえsmtpパッケージは、たいてい検証済みで長年信頼されてきたライブラリを使うことになる。MCPは何もかもが新しく、信頼の歴史が積み上がっていないのが問題だ。いわばソフトウェアの荒野で、6連発を装填して歩き回らなければならないような環境だ