Magento 和 Adobe Commerce 出现 10 分（满分 10 分）漏洞：到底发生了什么

先给出直接答案：2026 年 9 月 4 日，攻击者开始利用 Magento Open Source 和 Adobe Commerce 中一个尚未修补的漏洞，编号为 CVE-2026-75650，严重性评分为 10.0，也就是可能的最高分。该漏洞允许无需登录、无需任何权限即可在店铺服务器上执行命令，而 Adobe 在 9 月 7 日晚间才发布修复。这意味着整整三天里，店铺毫无防护地暴露在外。这正是仅安装补丁还不够的原因：如果你的店铺运行在这个平台上，稳妥的假设是你可能在修复出现之前就已被攻破，正确的应对是排查入侵迹象，并轮换加密密钥和所有凭据，而不是装完更新就照常过日子。

具体哪些人受影响

受影响范围异常广泛，因为其中包括了漏洞被发现时可用的最新版本：

  • Magento Open Source 和 Adobe Commerce：2.4.4 至 2.4.9 版本，包括截至 2026 年 8 月的所有补丁更新。
  • Adobe Commerce B2B：1.3.3 至 1.5.3 版本，截至 2026 年 8 月的更新。
  • 任何早于 2.4.4 的版本：早已停止支持，而且由于官方热修复不覆盖它们，是最危险的一类。

说得直白些：如果你在 9 月 1 日运行的是完全更新的 Magento，你就处于暴露状态。这不是我们通常提醒的那种疏忽场景，而是一个真正的零日漏洞（zero-day），没有人有办法抢在它前面。

攻击如何在没有密码的情况下进行

攻击分两个阶段进行，滥用的是 Magento 构建邮件模板的功能。第一阶段，攻击者向支付回调路径发送一个精心构造的请求，该请求的全部内容会被写入服务器上的一个错误报告文件。第二阶段，一个发往 GraphQL 端点的请求指回这个被投毒的文件，在准备支付失败提醒邮件时，文件内容就会被执行。

值得企业主关注的不是技术细节，而是它所揭示的问题：看起来完全无害的公开路径（支付网关的回调、店面的查询端点、一封自动邮件）组合起来，形成了一条通往服务器的完整路线。严重漏洞很少是一扇大敞的门；更常见的是一连串小门，每一扇单独看都完全合理。

攻击者进入后植入了什么

这正是破坏者和有组织行动之间的区别所在。观察到的恶意载荷并不是高调的勒索软件通知，而是悄无声息的持久化工具：

  • 一个用 Rust 编写的后门，伪装成操作系统的内核进程之一，因此粗略浏览进程列表的人不会注意到它。
  • 伪装的命令与控制流量，经由时间同步端口传输，因此在网络日志中这些活动看起来像是例行的时钟校准。
  • PHP Web Shell，写入商品图片缓存文件夹中，这些地方通常没人检查，因为里面满是临时文件。
  • 额外的远程访问工具，来自使用不相关工具的第二个攻击者，这意味着同一时间有不止一个团伙在利用该漏洞。

在一家知名网店里植入这类载荷，目的是长期潜伏，在订单和支付数据经过时读取它们，而不是让网站瘫痪。被感染的店铺会继续完全正常地运行，这才是令人不安的地方。

为什么仅安装更新还不够

因为如果攻击者在 9 月 7 日之前就已进入，他们现在手里就有你的加密密钥和已存储凭据的副本。补丁关上了他们进来的那扇门，却不会把他们从里面赶出去。Adobe 自己的指引在这一点上说得很明确：先应用修复，然后轮换加密密钥、管理后台密码、API 令牌、支付网关凭据、数据库密码和服务器访问密钥。

补丁能止血。轮换密钥才能把不速之客请出家门。

给店主的实用行动计划

  • 第一，确认修复确实已安装，而不是有人说已经装了。请团队拿出服务器本身补丁日志中的证据，而不是一条让人安心的消息。
  • 第二，排查入侵痕迹：名称模仿系统进程的可疑运行进程、媒体和图片文件夹中的 PHP 文件，以及异常的错误报告文件。
  • 第三，检查外发邮件日志。支付失败提醒邮件突然激增，是漏洞利用尝试的直接指标，任何运营负责人无需深厚的安全知识就能看懂。
  • 第四，轮换每一把密钥，无一例外，尤其是支付网关凭据。这需要一个事先规划的维护窗口，而不是在高峰时段临时拍板。
  • 第五，如果你的版本早于 2.4.4，别再等一个不会到来的官方补丁了。制定一个有明确日期的升级计划，并在此期间把店铺置于 Web 应用防火墙之后。
  • 第六，记录你所做的一切。如果事后发现客户数据已经泄露，你将需要一份做了什么、何时做的时间线。

沙特阿拉伯的监管视角：客户数据不只是技术问题

一家保存客户姓名、地址、手机号码和订单历史的网店，正在处理受《个人数据保护法》管辖的个人数据。数据泄露不会只是店铺与托管服务商之间的内部事务；它会产生对主管机构以及对数据主体本人的义务。因此，店主今天应该问的不只是“服务器打补丁了吗”，还有“我能否证明客户的数据没有被动过”。

如果你的店铺运行在 Salla 或 Zid 这样的托管云平台上，你就不在这个特定漏洞的影响范围内，因为给平台打补丁不是你的责任。但同样的教训适用于你接入店铺的任何扩展或第三方集成：打补丁的责任跟着服务器的所有者走。

Origami 如何处理此类事件

我们为客户构建系统所遵循的原则是：安全事件不是遥远的可能，而是被推迟的必然。落到实践中意味着三件事：凭据不放在代码库里，而是存放在独立的保险库中，这样轮换凭据只需几分钟，而不是一个长达一周的项目；运营日志存放在服务器之外，让攻击者无法抹去自己的痕迹；备份经过实际恢复测试，而不只是设了定时任务。

如果你经营一家 Magento 店铺却没有专职技术团队，今天该做的事情很简单：请你的托管服务商或技术合作伙伴提交一份书面报告，只回答三个问题：修复究竟是什么时候安装的，入侵扫描发现了什么，以及密钥是否已经轮换。这三个问题比任何演示文稿都更能看出一个技术合作伙伴的准备程度。

参考来源