Postmark MCP供应链攻击：生产环境中的ASI04

zealynx 发布于 2026-06-13 阅读 68

2025年9月，Postmark MCP服务器被植入木马并发布到npm，该木马在AI Agent发邮件时自动密送攻击者邮箱，实现数据侧信道窃取。攻击者通过窃取维护者账户发布恶意版本，未修改正常邮件发送逻辑，导致检测困难。OWASP将此类攻击列为ASI04（代理供应链漏洞）的典型示例。文章详细分析了攻击原理、检测难点（如侧信道泄露、维护者信任失效）、防御措施（版本哈希锁定、网络出站白名单、操作信封检查）以及针对Web3场景的特别建议。并提供了Zealynx审计方法论和FAQ。

TL;DR

  • 2025 年 9 月，一个被植入木马的 Postmark MCP 服务器版本被发布到 npm。安装或自动更新该包的组织，令恶意服务器工具在其 AI Agent 上获得了权限。
  • 木马的行为：Agent 通过被冒充的服务器发送的每一封邮件，都会被静默密送给攻击者控制的收件箱。从用户角度看，Agent 正常工作；从操作者角度看，每一条外发通信都在被静默窃取。
  • OWASP 将此事件列为 ASI04（Agentic 供应链漏洞） 下 MCP 冒充 的典型示例。它是 OWASP 2026 年 Agentic 应用 Top 10 中的实际案例。
  • 该攻击在结构上很简单——不需要新颖的密码学、奇异的利用原语或零日漏洞。它之所以有效，是因为 Agent 宿主将已安装的 MCP 服务器视为权威，而没有任何独立的来源验证。
  • Postmark 的模式具有通用性：任何代表 Agent 执行“发送”或“发布”操作的 被植入木马的连接器，都可以利用侧信道将该操作的内容复制给攻击者。

发生了什么

Postmark MCP 服务器是一个合法的连接器，允许 AI Agent 通过 Postmark 的 API 发送事务性邮件。它是一个生产力工具：Agent 可以“向客户发送后续邮件”或“将报告通过电子邮件发送给团队”，而操作者无需编写 API 集成代码。

2025 年 9 月，一名攻击者将植入了木马的版本发布到 npm。依赖该包（直接或通过自动更新间接依赖）的组织静默地收到了恶意版本。木马的修改极小：在发送电子邮件的路径中，构造外发消息后，木马添加了一个密送地址，指向攻击者控制的电子邮件地址。Agent 通过该服务器发送的每封邮件都被复制给了攻击者。

检测在设计上就很困难。合法的邮件仍然正常发送，收件人依旧收到。Postmark 仪表盘仍显示预期的外发流量。唯一的信号是密送行——在大多数电子邮件客户端和许多日志配置中，用户或操作者无法看到。组织只是在攻击者的收件箱最终通过无关调查被追踪到时，才发现这个木马。

为什么这是典型的 ASI04 案例

OWASP 2026 年 Agentic 应用 Top 10 明确将 Postmark 事件列为 ASI04（Agentic 供应链漏洞） 的实际案例。原因是 Postmark 以无多余细节的方式完美诠释了该模式：

  • 被攻陷的组件是加载到 Agent 运行时的第三方工具——教科书式的 ASI04 攻击面。
  • 攻击向量是供应链攻陷（恶意 npm 包），而非运行时利用。
  • 木马与合法行为并行运行，使得检测困难，并延长了可利用窗口。
  • 影响同时波及每个客户的数据——木马对所有安装实例是相同的，因此每个操作者都面临同样的数据窃取风险。

OWASP 将此模式命名为 MCP 冒充——一个恶意 MCP 服务器冒充合法供应商（Postmark），在每次 Agent 调用时静默执行攻击者选择的动作。Postmark 事件是该模式大规模生效的生产环境验证。

木马是如何进入的

已披露的攻击记录指向 维护者账户失陷 是最可能的向量。攻击者通过凭证钓鱼、会话劫持或其他经典的账户接管原语，获得了 Postmark MCP 包 npm 分发的发布权限，然后通过合法发布渠道推送了木马版本。

这个向量之所以重要，是因为它绕过了所有在安装时起作用的供应链防御。包的签名（如果有）是有效的，因为合法维护者的账户签署了它。版本号遵循项目的正常节奏。发布说明没有标记任何可疑内容。锁定版本并验证签名的操作者并未得到保护——合法维护者的权限正是攻击者劫持的目标。

结构性的教训：对维护者的信任是一种信任假设，与所有信任假设一样，它可能失效。仅依赖维护者签署的发布的防御措施，会在维护者的签名密钥或发布权限被攻陷时失效。

侧信道数据窃取作为一种模式

Postmark 木马添加了一个密送。合法的邮件路径继续工作。恶意行为是一个侧信道——一个与可见操作互不干扰的并行数据窃取路径。

侧信道数据窃取是执行“发送”、“发布”或“通信”操作的 被植入木马的连接器 的主要模式。每个此类操作都有天然的侧信道：电子邮件中的密送、消息中的隐藏收件人、数据库的镜像写入、HTTP 请求的额外头部、文件存储的并行上传。在正常使用下，这些对用户都是不可见的，并在每次合法操作时创建窃取能力。

对防御的启示：仅监控合法操作是不够的。合法操作正确完成了；恶意操作与之并行执行。检测需要检查完整的操作包络（每个收件人、每个头部、每次并行写入），或者在网络出口白名单上操作，阻止侧信道到达攻击者的目的地。

检测与缓解

对于任何运行具有基于连接器的“发送”或“发布”工具的 AI Agent 的组织，以下四个运营控制措施涵盖了 Postmark 模式：

  1. 固定特定的包版本以及内容哈希。 仅靠锁定文件是不够的，因为锁定文件固定了版本，但未固定内容；劫持了维护者账户的攻击者可以用不同的内容重新发布相同的版本。锁定文件加上内容哈希固定（npm 的 --integrity 标志，pip install 中 PyPI 的哈希模式）弥补了这一差距。

  2. 验证发布者来源。 SLSA 构建证明、Sigstore 签名、npm 的来源证明——只要可用，优先选择使用加密构建来源发布的连接器，而非仅依赖维护者账户签名的连接器。

  3. 连接器进程的网络出口白名单。 连接器应仅能到达其声明功能所需的确切目的地（对于 Postmark MCP：Postmark 的 API 端点），而不能到达其他任何地方。攻击者的密送地址不会在白名单中；无论木马试图做什么，侧信道数据窃取都会在网络层被阻止。

  4. 检查操作包络中的侧信道。 对于“发送”操作，记录每个收件人、每个头部、每个并行目的地。对于“发布”操作，记录每个目的地、每个负载变体。与预期行为进行比较，对任何偏差发出警报。

对于 Web3 部署，规则是无条件的：接触钱包凭证、签名操作或交易广播的连接器，必须在其声明目的地仅包括的网络出口白名单内运行。将 Postmark 侧信道模式应用于交易签名 MCP 服务器，意味着每一笔已签名的交易广播也会被镜像到攻击者的地址——资金损失在合法流程中没有任何可见信号。

Zealynx 如何审计此模式

Zealynx 的 MCP 安全审计 将 Postmark 类发现作为标准类别。五个重点测试：

  1. 连接器来源审计。 对于部署中的每个 MCP 服务器，识别包来源、维护者信任链以及任何加密来源证明。标记来源验证薄弱或缺失的连接器。
  2. 网络出口审计。 枚举每个连接器进程实际到达的目的地，与声明功能进行比较，标记任何无法解释的目的地。
  3. 操作包络检查。 对于每个“发送”或“发布”工具，抽样完整的操作包络（收件人、头部、并行写入）并与预期形态进行比较。
  4. 维护者信任失效模式审查。 对于每个连接器，推演“如果维护者的账户被攻陷会怎样？”标记安装后失效模式无法检测的连接器。
  5. 更新向量审查。 对于每个连接器，识别更新向量（手动、自动更新、注册表拉取）。标记自动更新的高权限连接器，这些连接器的更新内容没有人工参与。

发现结果映射到 ASI04（以及 ASI03，当底层凭证信任假设失败时），并附带优先级的修复指导。

常见问题解答

  1. 2025 年 9 月的 Postmark MCP 供应链攻击是什么？ 2025 年 9 月的 Postmark MCP 供应链攻击是一个事件，其中被植入木马的 Postmark MCP 服务器版本被发布到 npm。安装或自动更新该包的组织，令恶意服务器工具在其 AI Agent 上获得了权限。该木马在每一封外发邮件中添加了一个密送地址，指向攻击者控制的电子邮件地址，静默窃取 Agent 发送的每一封邮件。OWASP 将此列为 ASI04 下典型的 MCP 冒充 示例。

  2. 木马是如何进入 npm 的？ 最可能的向量是 维护者账户失陷——攻击者通过凭证钓鱼、会话劫持或其他经典的账户接管原语，获得了 Postmark MCP 包的 npm 分发发布权限，然后通过合法发布渠道推送了木马版本。依赖维护者签名密钥或注册表信任的防御措施失效，因为攻击者恰恰劫持了这些。

  3. 为什么检测如此困难？ 检测困难是因为木马作为 侧信道 与合法行为并行运行。邮件仍然发送，收件人仍然收到。Postmark 仪表盘仍显示预期的外发流量。唯一的信号是密送行，在大多数电子邮件客户端或操作者日志配置中用户无法看到。仅监控合法操作是不够的；检测需要检查完整的操作包络，或将连接器运行在网络出口白名单内。

  4. 为什么这是 OWASP ASI04 的实际案例？ Postmark 是典型的 ASI04 示例，因为它以无多余细节的方式完美诠释了该模式：被攻陷的组件是加载到 Agent 运行时的第三方工具；攻击向量是供应链攻陷；木马与合法行为并行运行；影响同时波及每个客户的数据。OWASP Agentic 应用 Top 10 明确将“MCP 冒充”称为该模式，并使用 Postmark 作为示例。

  5. 锁定文件能防止这次攻击吗？ 仅靠锁定文件无法防止 Postmark 攻击，因为锁定文件固定了版本，但未固定内容。劫持了维护者账户的攻击者可以用不同的内容重新发布相同的版本。锁定文件加上内容哈希固定（npm 的 --integrity 标志，pip install 中 PyPI 的哈希模式）通过确保安装不仅匹配版本号，还匹配特定的已知良好内容哈希，弥补了这一差距。

  6. 网络出口白名单如何帮助？ Postmark MCP 连接器进程的网络出口白名单将只允许 Postmark 的合法 API 端点。攻击者的密送目的地不会在白名单中；无论木马试图做什么，侧信道数据窃取 都会在网络层被阻止。这是少数几种在安装后维护者失陷时仍然有效的防御措施——它不依赖于木马是否可检测，而依赖于目的地是否可达。

  7. Web3 部署的规则是什么？ 对于 Web3 部署，无条件的规则是：任何接触钱包凭证、签名操作或交易广播的连接器，必须在其声明目的地仅包括的网络出口白名单内运行。将 Postmark 侧信道模式应用于交易签名 MCP 服务器，意味着每一笔已签名的交易也会被镜像到攻击者的地址——资金损失在合法流程中没有任何可见信号。防御不能是“我们信任该连接器”，而必须是“该连接器无法到达未授权目的地”。

  8. Zealynx 如何审计此模式？ Zealynx 的 MCP 安全审计 在五个维度上测试 Postmark 类供应链木马发现：连接器来源审计（包来源、维护者信任链、加密证明）、网络出口审计（实际目的地与声明的对比）、操作包络检查（对“发送”/“发布”操作进行侧信道抽样）、维护者信任失效模式审查（如果维护者被攻陷怎么办？）、以及更新向量审查（标记自动更新的高权限连接器）。发现结果映射到 ASI04，并附带优先级的修复指导。

术语表

术语 定义
维护者账户失陷 一种攻击向量，攻击者通过凭证钓鱼、会话劫持或其他账户接管原语，获得包分发渠道的发布权限，然后通过合法渠道推送恶意版本。绕过依赖维护者签名或注册表信任的防御。
侧信道数据窃取 一种数据窃取模式，被植入木马的连接器 在其合法操作中添加并行窃取路径——电子邮件中的密送、消息中的隐藏收件人、数据库的镜像写入——在正常使用下对用户不可见，并且通过监控合法行为无法检测。
出站中介信任 一种信任模式，AI Agent 使用连接器代表其执行出站操作（发送电子邮件、发布消息、广播交易），将操作完整包络（收件人、目的地、并行写入）的信任转移给连接器。在 Postmark 类供应链攻击中失效的信任模式。

查看完整术语表 →

  • 原文链接： zealynx.io/blogs/postmar...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
微信扫码分享

相关文章

0 条评论

登录后发表评论