StyleSmuggler 正在攻击 Magento：Adobe 修复发布前，商家该如何应对

StyleSmuggler 是 Sansec 对一条已公开报告、且被称为正在遭利用的 Magento Open Source 与 Adobe Commerce 零日漏洞链所使用的名称。其风险等级很高：未认证攻击者可在店铺服务器上实现远程代码执行（RCE）。Sansec 称，攻击始于 2026 年 9 月 4 日，并于 9 月 5 日披露该问题。2223

这仍是一宗快速演进的事件，而非已经完成的厂商安全公告。对商家的现实含义很明确：不要因为披露前已安装全部补丁，就认定公网暴露的 Magento 环境安全。应立即收缩攻击面、保全证据，并在依赖任何缓解措施前排查是否已被入侵。

初始披露期已知情况

Sansec 表示，所有当前版本均受影响，包括 Magento Open Source 2.4.9；研究人员已在干净安装的 Magento Open Source 2.4.7、2.4.8 和 2.4.9 上复现完整的未认证攻击链。22 另有公开报告称，一名受害者运行的是 2.4.6-p15，且已安装 2026 年 7 月及 8 月安全更新。这意味着，此前保持补丁更新并不能解决这一刚披露的问题。32

截至 9 月 6 日的报道发布时，Adobe 尚未发布专门针对 StyleSmuggler 的 CVE、安全公告、补丁或临时解决方案。23 Adobe Commerce as a Cloud Service 原定于 9 月 8 日进行生产环境发布，但该发布计划并不等于确认会修复 StyleSmuggler。8

上述时间点仅反映最初披露窗口的情况。作出补丁决策前，商家仍应查看 Adobe 最新的安全公告与发行说明，确认厂商的当前结论。

已报告的攻击链：GraphQL 到服务端模板执行

根据 Sansec 的说明，攻击者滥用未认证 GraphQL 输入中的 styles 属性，绕过既有防护，并将攻击者控制的 PHP 注入 Magento 的模板相关处理流程。该链分为两个阶段：先将代码写入 Magento 生成的内容中，例如失败报告；随后，通过失败支付邮件的渲染流程触发被污染内容执行。22

“Payment Transaction Failed”（支付交易失败）通知本是 Commerce 中可配置的常规邮件功能。18 在这条被报告的攻击链里，关键是服务器端模板渲染，而不是收件人打开邮件。因此，事件响应不能只关注邮件是否成功送达：即使外发邮件发送失败，或没有收件人与邮件互动，可疑的支付失败活动仍可能与攻击有关。

公开报道将后续载荷描述为持久化 Linux 后门，可能伪装为 kworker 等进程名，并通过 cron 任务维持持久化。2035 这些是有用的排查线索，却不是完整或永久有效的指标清单；攻击者可以随时改变文件名、进程名、路径及网络基础设施。

尚未得到独立证实的说法

部分事件情报报告还提出了更多主张，例如：无需可观察到的命令与控制（C2）流量即可窃取 Redis 中的会话数据，以及通过污染 var/log/system.log 来规避基于 var/report/ 的排查。现有材料并未提供可复现的恶意软件分析，也没有第二个独立的取证来源证实这些具体行为。

因此，应将其作为未经验证的情报主张，而不是既定事实。这种不确定性并不意味着可以不调查；相反，它意味着取证范围不能局限于 Magento 报告文件，还应覆盖主机、进程、cron、Web、PHP-FPM、Redis、DNS 与防火墙遥测数据。

立即遏制：优先做什么

1. 限制公网 GraphQL 暴露

如果店铺可在不使用公网 GraphQL 的情况下正常运行，应暂时禁用或阻断 /graphql。若 GraphQL 属于关键业务能力，则应在 CDN、WAF 或反向代理层仅允许必要客户端、运维来源和查询模式访问。Sansec 的公开建议指出，在官方修复尚不可用时，禁用 GraphQL 是直接的非厂商防护手段。22

但这只是补偿性控制，并不能证明服务器未被入侵，必须与调查并行推进。

2. 谨慎采用紧急缓解方案

Sansec 表示，其 Shield 规则可阻断已知攻击的两个阶段。22 Disrex 也称已发布用于阻断已知攻击链的紧急缓解补丁，但同时强调：这类补丁不会清除现有感染。35

所有第三方补丁或 WAF 规则都应经过代码审查、预发布环境测试，并纳入受控变更流程。官方修复经过测试并确认封堵相关攻击路径之前，不应过早撤除这些临时控制。

3. 清理前先保全证据

若存在失陷可能，应在删除文件或重启服务之前，留存相关日志，并采集主机与进程快照。重点包括：

• /graphql 的 Web 服务器及反向代理请求，尤其是包含 styles 的异常 POST 请求；
• PHP-FPM、应用、cron、运行账户、DNS 与防火墙日志；
• 支付失败邮件异常激增，或异常模板渲染活动；
• 新增或被修改的 cron 任务，特别是由 Web 服务账户执行的命令；
• PHP-FPM 异常子进程、伪装成系统工具的可疑进程，以及位于可写或隐藏路径中的陌生可执行文件；
• Web 与 PHP 运行账户发起的开放套接字和外连连接。

不要只收集 var/report/ 或 Magento 应用日志。即使不存在刻意篡改，这些来源也可能并不完整。

降低成功入侵后的破坏面

在事件调查期间，以下加固措施普遍有益：

• 让 Web 与 PHP 工作进程使用专用、非特权账户运行，并将文件系统权限压缩至最小；
• 对运行账户将应用代码设为只读，只对 Commerce 确有需要的目录开放写入；
• 在兼容的前提下，阻止从临时目录、缓存、上传、媒体、日志、报告及生成目录等可写位置执行文件；
• 经兼容性测试后，为临时或高频写入文件系统考虑 noexec、nodev 和 nosuid 挂载选项；
• 将应用主机的出站流量限制为明确的允许列表，并对异常 DNS 或 UDP 活动告警；
• 不要将 Redis 暴露在公网，应使用私有网络，并配置适当的认证与传输保护；
• 对新增 cron 项、由 PHP-FPM 启动的异常进程，以及部署产物变更设置告警。

这些控制不能替代应用层修复，但能限制持久化能力，并让异常活动更容易被发现。

一旦发现迹象，应如何处置

任何阳性指标都应被视作整台服务器可能已失陷。应隔离受影响主机、保全取证证据，并轮换应用环境中可能可被访问的凭据：Magento 管理员与集成凭据、API 密钥、数据库和 Redis 凭据、部署及 SSH 密钥，以及支付服务商凭据。再根据自身环境，适当使客户会话失效。

对于已确认的入侵，从已知可信镜像或备份重建，通常比只删除一个可见二进制文件后让原主机重新上线更安全。缓解补丁或许能够阻止再次入侵，却无法证明既有后门、凭据窃取行为或持久化机制已经被完全清除。

给商家的核心结论

StyleSmuggler 的重要警示在于：一条刚披露、且被报告为正在遭利用的攻击链，可能绕过原本已处于最新补丁水平的 Magento 环境。在最初披露窗口内，最合理的应对是减少或移除公网 GraphQL 暴露，部署经过审查的临时防护，从应用和主机两侧排查失陷，并在 Adobe 官方修复可用后尽快测试、部署和验证。222335