安全研究人员发现了首个在野的恶意 MCP 服务器,攻击者通过在 npm 上发布的伪造包 postmark-mcp 将所有通过该 MCP 服务发送的邮件静默抄送到攻击者控制的邮箱,从而导致大量敏感通信被外泄。这一事件不仅暴露了开源生态中包名仿冒的老问题,也突出了 MCP 等新兴代理化、具有高权限运行组件在软件供应链中的危险地位。 事件概况与关键细节 安全团队 Koi Security 报告称,名为 phanpak 的开发者在 2025 年 9 月 15 日向 npm 上传了一个名为 postmark-mcp 的包,该包模仿官方 Postmark Labs 的同名 JavaScript 库,功能看似正常,但在 1.0.16 版本中加入了一行恶意代码:在发送邮件时对目标邮件进行 BCC,将副本发送到受控地址 phan@giftshop[.]club。该 npm 包共被下载 1,643 次,发布者还维护着 31 个其他包。发布者随后已从 npm 删除该包。 Koi Security 首席技术官 Idan Dardikman 指出,自 1.0.16 起,包会悄悄复制每封邮件到开发者的私有服务器,这是首个在真实环境中发现的恶意 MCP 服务器样本。
安全厂商 Snyk 亦警示 MCP 服务器通常运行在代理化工具链中,拥有广泛权限,可能处理密码重置、发票、客户沟通与内部备忘等敏感内容,因此一旦被滥用,后果严重。 为什么这类攻击特别危险 MCP(Model Context Protocol)及类似代理化服务逐渐被集成进更复杂的自动化与智能代理工作流中。这类组件通常被赋予高信任级别与广泛权限,能够代表应用或代理发送邮件、访问模板和触发自动化流。攻击者只需要在依赖链上做出微小修改,就能把敏感数据悄悄外泄。 与传统依赖被植入恶意代码相比,这起事件的特点在于伪造包名与针对邮件发送逻辑的单行后门。攻击者并非直接篡改官方库,而是通过与官方同名但由恶意维护者上传的包来混淆用户。
许多开发者在自动化构建或依赖解析时并不会核验包的来源是否与官方仓库一致,从而增加了中招概率。 可导致泄露的数据类型包括但不限于密码重置链接、交易发票、用户个人信息、内部审批邮件以及包含敏感凭证的沟通。由于邮件往往被用于传递确认链接与一次性密码,攻击者可以利用截获的邮件进行进一步横向入侵或账户接管。 安全影响与合规压力 对企业而言,这类邮件外泄可能触发合规与法律后果。若邮件中包含受保护的个人信息或敏感商业信息,组织可能面临数据泄露通报义务、客户信任损失以及监管罚款。尤其在严格的数据保护法规环境下,如欧盟 GDPR 或地区性隐私法规,未能保护用户通信数据可能带来显著法律风险。
此外,供应链攻击的影响往往具有放大效应。一旦恶意包进入一个自动化构建流程,它可能随着构建产物传播到多个服务与环境中,造成跨项目、多租户的连锁暴露。MCP 类服务因为运行权限高,传播后果尤为严重。 检测与响应建议 首先,已安装或曾使用 postmark-mcp 包的开发者与组织应立即检查依赖清单与构建产物,确认是否包含来自非官方来源的同名包。若存在风险点,应尽快移除该包并回滚到安全状态。建议对所有通过 MCP 服务发送的邮件记录进行审计,重点查找是否存在 BCC 到未知或可疑域名的记录。
对疑似受影响的账户应尽快进行凭证轮换,包括但不限于 API 密钥、SMTP 凭据与任何可能通过邮件泄露的认证令牌。对被窃取邮件所涉及的用户或业务单位应进行通知与风险告知,必要时启动法务与合规团队协助应对可能的监管申报。 建议设置高级告警策略以监控不寻常的邮件抄送行为、邮件传输路径与发送频率。若邮件系统支持,可对外发邮件中的 BCC 字段进行严格日志记录与异常检测。对内部代理与 CI/CD 流程添加对关键依赖变更的审计与审核环节,防止未经人工核验的包自动被拉取到生产流水线。 长期防护与最佳实践 组织层面需把供应链安全纳入常态化治理。
优先策略包括在私有注册表中托管关键依赖、对第三方包启用签名验证、在构建流程中使用固定校验和与锁文件(如 package-lock.json)并启用依赖完整性校验。对公开包应核实维护者身份并关注包的发布与作者信息,避免直接依赖与知名项目同名但来源不明的包。 建立软件物料清单(SBOM)以便在供应链事件发生时能够快速追溯受影响组件。对关键组件启用自动化依赖扫描与威胁情报整合,及时发现新增的可疑发布。对运行代理化服务如 MCP 的环境应采用最小权限原则,将邮件发送能力隔离在受限环境中,并对外部网络通信施加严格策略。 开发与运维团队应接受关于供应链风险、依赖管理与包签名的培训,避免盲目使用未核实来源的第三方库。
鼓励在生产环境启用多重验证、审计日志保留与实时告警,以便在首次发现异常行为时能迅速响应。 技术缓解措施包括对邮件发送 SDK 增加运行时校验与白名单策略,验证发送逻辑中是否存在未经授权的抄送目标。引入内容安全策略与审计钩子,自动检测邮件中包含的外部回传地址或未经授权的收件人列表变更。 开源生态与社区责任 该事件再次提醒开源社区维护者与生态平台需要加强对包名仿冒与恶意发布的防护措施。平台方应完善包发布验证机制,鼓励或强制包签名、维护者身份验证与多重验证流程。社区应建立更为便捷的包声誉查询与警示通道,使开发者能在安装前更容易辨别包的可信度。
维护者应对关键项目启用更严格的访问控制、采用多重维护者模型并定期审查依赖。开源项目可以考虑在 README 与官方文档中明确说明官方包的发布源与校验方法,降低用户被类似名称包迷惑的可能性。 官方与厂商声明 Postmark 已声明 npm 上的 postmark-mcp 包并非官方发布,官方 Postmark API 与服务未受影响。该声明有助于区分官方服务与伪造包,但并不能替代针对受影响用户的后续补救措施。厂商与第三方安全团队的联动在此类事件中极为重要,包括情报共享、受影响用户告知与防护建议发布。 结语与行动呼吁 postmark-mcp 恶意包事件为开发者与安全团队敲响了警钟:在信任与便利面前,供应链安全与包来源核验必须成为软件开发生命周期的基本环节。
MCP 等代理化服务因其高权限特性,应被视为高价值目标并获得额外防护。每一个依赖、每一行代码都可能成为入侵的跳板。 对开发者而言,安装第三方包前务必核实来源、启用依赖锁定、使用私有注册表与签名验证。对安全负责人而言,建立快速响应与日志审计机制、将供应链安全纳入风险评估并对关键服务实行最小权限策略,是降低类似事件影响的有效手段。对整个生态而言,加强包管理平台的验证与社区自律,是减少此类伪造与后门发生概率的根本途径。 当软件供应链被证明是攻击者偏好的路径之一时,组织必须采取更为主动与系统化的防护措施。
不仅仅是删除一个恶意包、轮换一个密钥,更要从治理、流程、技术与文化四个层面一并入手,构建对抗供应链攻击的长期能力与弹性。只有如此,才能在未来面对更多复杂的依赖攻击时立于不败之地。 。
