jithinkrishnanrs/stylesmuggler-ioc-toolkitStyleSmuggler（CVE-2026-75650）IOC 工具包，适用于 Magento Open Source 和 Adobe Commerce。检测被入侵的商店、Rust 植入程序、PHP Web Shell、持久化痕迹以及已知的入侵指标。
Magento 零日漏洞 · Adobe Commerce 零日漏洞 · CVE-2026-75650 · APSB26-146 · VULN-39341 · 未认证 RCE · Magento 恶意软件 · Magento 后门清除 · Magento 2.4.9 漏洞 · Rust 植入程序 · GraphQL styles 注入 · PHP web shell
面向 StyleSmuggler（CVE-2026-75650）的社区失陷指标（IOC）、失陷扫描器以及缓解/修补指南——该漏洞是 Sansec 于 2026 年 9 月 5 日披露的未认证 Magento Open Source / Adobe Commerce RCE，并已确认自 2026 年 9 月 4 日起存在在野利用。Adobe 于 2026 年 9 月 7 日发布了官方修复 APSB26-146。如果你搜索的是“StyleSmuggler IOC”、“CVE-2026-75650”、“APSB26-146”、“VULN-39341”、“Magento fc-cache 恶意软件”、“Magento chronyd 后门”、“gvfsd-user Magento”或“Magento GraphQL styles RCE”，那么这就是你要找的仓库。
本仓库仅为防御性工具包。 它包含检测签名、失陷扫描器，以及基于已公开的第一手事件报告构建的加固/阻断规则。 它不包含漏洞利用代码、概念验证触发程序，或任何可生成攻击载荷的内容。如果你在寻找这些内容，那你找错仓库了—— 请去打补丁并开展狩猎。
| 漏洞 | StyleSmuggler（Sansec 的命名）— CVE-2026-75650 |
| 厂商 | Adobe（Magento Open Source、Adobe Commerce） |
| CVE | CVE-2026-75650，分配于 2026-09-07 |
| Adobe 公告 | APSB26-146，发布于 2026-09-07 20:20 UTC，优先级 1（最高） |
| 同时需要 | APSB26-138（Adobe 2026 年 9 月的常规 Commerce 更新，独立补丁 249-2026-09-001-CE，发布于 2026-09-08）。Adobe 声明 VULN-39341 必须在此基础之上应用，而不是替代它。 |
| CVSS | 10.0（3.1 和 4.0）— 严重。完整的 3.1 向量：AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| CWE | CWE-1336，模板引擎中特殊元素的不当中和 |
| CISA KEV | 于 2026-09-08 被加入 CISA 的已知被利用漏洞目录。 联邦文职行政部门（FCEB）的修复截止日期：2026-09-11。CISA 的条目还将其标记为需要取证/事件响应（IR）分诊，并将已知的勒索软件活动使用情况列为“未知”。这已不只是 Magento 社区的问题——它现在是一个被联邦追踪、正被积极利用的 RCE。 |
| 官方补丁 | 已发布。 热修复 VULN-39341。覆盖范围并非普遍适用——见下表。 |
| 是否需要认证 | 不需要——无需认证 |
| 公开利用代码 | Adobe/Sansec 没有官方 PoC，但佐证报道提到一个公开的 GitHub 仓库（创建于约 9 月 8 日），其自述为对完整攻击链的研究实验室复现——“没有公开利用代码”这一说法比听起来要弱。参见 docs/VULNERABILITY.md。 |
| 受影响版本 | Sansec 在干净的 Magento Open Source 2.4.7、2.4.8、2.4.9 上复现；首个确认的受害者在完全打补丁（基于此前补丁）的 2.4.6-p15 上运行 |
| 利用情况 | 自 2026-09-04 22:20 UTC 起活跃；持续至补丁发布之后；截至 2026-09-14，至少确认三个独立工具包利用同一入口点。一个漏洞利用追踪网络报告称，自 9 月 9 日以来有 500 多个不同源 IP。第三方 WAF 遥测（Imperva）报告称，观察到的目标偏向零售（约 39.5%）、生活方式（约 19.5%）和医疗保健（约 17.9%）——这是各厂商可见性范围的快照，并非对全部易受攻击商店群体的断言。 |
| 已知 Rust 植入变体 | [kworker/u:8:0]（9 月 4 日）→ fc-cache v2.1.4（9 月 6 日）→ chronyd v2.1.5（9 月 7 日）——同一操作者、同一代理 ID，版本号递增。已观察到 chronyd 构建版本在没有 cron 条目、父进程为 PID 1 的情况下自行重新启动。 |
| 第二个无关攻击者 | pub/media/catalog/product/cache/ 中的 PHP web shell，此前有一次 DNS 外传侦察探测——与 Rust 植入无关，确认于 2026-09-07 |
| 第三个独立工具包 | 确认于 2026-09-14。 一个远程文件包含后门被直接编辑进核心框架文件 vendor/magento/framework/App/View.php，由一个伪装成广告技术追踪的 cookie（gl_google_advisor_824808）作为门控。按需获取并执行远程载荷，随后删除临时文件——请求之间磁盘上除了厂商文件中那一行被篡改的代码外，不留下任何东西。 |
| 无需邮件即可引爆 | 确认于 2026-09-14。 第二条攻击链通过 POST /paypal/transparent/response/（查询字符串中的 PHP 源代码）实现完整代码执行，而无需渲染“支付失败”邮件——标记为 MGPROOF::/MGKWSIM::，通过 kwc 参数直接执行命令。仅围绕邮件触发点构建的缓解措施无法覆盖此路径。 |
| 已知投递向量 | GraphQL styles[] 参数；无效商店代码被记录到 var/log/system.log；通过 Magento 客户自定义选项上传文件；无关的第二攻击者的 Store: 头注入；/paypal/transparent/response/ 查询字符串中的 PHP 源代码（与邮件无关） |
| 影响 | 远程代码执行 → 持久化 Rust 后门、独立 PHP web shell、隐蔽的框架级 RFI 后门、Redis 会话窃取、通过 app/etc/env.php 泄露凭据/密钥 |
| 产品 | 由 APSB26-146 覆盖 | 无官方修复 |
|---|---|---|
| Adobe Commerce（含 B2B、Cloud） | 2.4.4 – 2.4.9 | 低于 2.4.4 |
| Adobe Commerce B2B | 1.3.3 – 1.5.3 | 低于 1.3.3 |
| Magento Open Source | 仅 2.4.6 – 2.4.9 | 2.4.5 及以下 |
如果你使用的是较旧的、不受支持的版本，Adobe 不会为你提供修复，尽管你同样容易受到攻击。请参阅 docs/PATCHING.md 了解你的可选方案——其中包括给 Mage-OS 用户的说明，他们有一个专门的紧急版本（3.5.0），而不是 Adobe 针对 Commerce 的热修复包。
这些信息变化很快。 在采取行动前，请与一手来源交叉核对：Sansec 的公告 和 Adobe 的公告。请参阅 docs/TIMELINE.md 获取持续更新的日志，并在更新此处任何内容时注明来源。
Magento 自有的 GraphQL styles 参数及其基于依赖注入的文件扫描被滥用为一种基于文件的延迟执行原语。最初记录的利用链有两个阶段，但——截至 Sansec 9 月 14 日的更新——它并不是唯一已确认的利用链，而且引爆并不总是需要第二阶段最初描述的内容：
var/log/system.log，或 var/report/<hash>），通过 GraphQL styles[] 参数、被篡改的请求头，或（对于下面第二个、不相关的攻击者）Store: 请求头夹带进入。getProcessedTemplate 路径）会走一条代码路径，使 Magento 自身的 DI/代码扫描器 include() 被投毒的文件，从而运行攻击者的 PHP。你不需要打开邮件——在服务器端渲染它就足够了——而且即使邮件投递本身失败，该利用链也能触发。一个简单、无需工具的早期预警信号：你的收件箱中出现一封乱码的“Payment Transaction Failed Reminder”邮件，带有原始的、未渲染的 {{var ...}} 标签，且客户地址以 .invalid 结尾。这通常是第一个可见迹象，早于任何人检查日志。
但那封邮件并不是达到执行的唯一途径。 Sansec 确认了第二条独立的引爆链，它完全跳过邮件：POST /paypal/transparent/response/，在查询字符串中植入 PHP 源代码，导致观察到会打印 MGPROOF::（一种执行证明检查，同时伴随一个名为 mgproof717.txt 的文件）或 MGKWSIM:: 的载荷——后者是一种直接命令执行原语，会运行以 base64 编码形式到达 kwc 请求参数中的任何内容，全程不涉及邮件。任何仅围绕监视或禁用失败支付邮件构建的缓解措施都无法覆盖此路径。
Sansec 的更新还确认了针对同一 Rust 植入物活动的第二条独立利用路径：即使是将会话存储从 Redis 迁移到数据库的商店也仍然被攻陷——同一操作者的第二次尝试在几秒后通过 Magento 客户自定义选项功能上传的文件成功了。迁移会话存储本身并不是修复。
另外，在9月7日，Sansec发现了一个完全无关的攻击者，其使用了完全相同的StyleSmuggler入口点，但载荷要简单得多：一个PHP web shell被投放到Magento自带的产品图片缓存中（pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php），在此之前还有一次侦察探测，该探测将其载荷隐藏在Store: HTTP头中，并通过DNS而非HTTP响应来外泄其发现结果。据Sansec称，这是“现成的工具”，并非持续性攻击活动——但这意味着单个存在漏洞的主机可以通过一个缺陷承载两次互不相关的入侵。清理掉Rust植入程序并不意味着你的商店就是干净的。
而在9月14日，Sansec确认了第三个、截然不同的工具集——与上述两者又有所不同。它没有投放新文件，而是直接编辑了一个Magento核心供应商文件（vendor/magento/framework/App/View.php），添加了一个按需触发的远程文件包含后门，该后门由cookie（gl_google_advisor_824808）控制，并故意伪装成广告技术追踪。当该cookie存在时，后门会将其值进行base64解码作为URL，获取该URL，将响应写入/tmp/tmp.log，执行它，然后立即删除——在两次请求之间，除了供应商文件中那一行被篡改的代码外，磁盘上不会留下任何额外内容。对pub/media的扫描永远无法发现这一个；你必须直接检查供应商文件的完整性。
Rust植入程序本身也在不断演变：最初的[kworker/u:8:0]伪装版本（9月4日）之后，是伪装成fc-cache的v2.1.4版本（9月6日），该版本伪装成NTP流量进行信标通信，随后是伪装成chronyd的重新部署版本v2.1.5（9月7日），这是同一个植入程序、同一个代理ID——这证明攻击者正在积极迭代，以规避你发布的任何检测手段。还观察到chronyd版本在没有cron条目且父进程ID为1的情况下自行重新启动，这与重命名是自行发起而非由cron触发的情况一致——对于此版本而言，空的crontab并不能证明主机是干净的。Sansec表示尚未看到证据表明该植入程序已被武器化到超出持久化/侦察的范围——鉴于无关攻击者已拥有可用的web shell，且现在第三个工具集在同一访问路径上拥有可用的后门，请不要将此视为安慰。
有关快速解答，请参阅docs/FAQ.md；有关完整的技术说明和来源，请参阅docs/VULNERABILITY.md；有关应用Adobe官方修复程序，请参阅docs/PATCHING.md；有关扫描器发现问题后该怎么做，请参阅docs/INCIDENT_RESPONSE.md。
1. 打补丁，如果你的版本在覆盖范围内：
# See docs/PATCHING.md for the full process — this is not a one-liner, it requires
# Adobe repo credentials and your project's patch-management tooling.
2. 无论补丁状态如何，都要扫描是否存在已有的入侵痕迹 — 打补丁只能阻止新的利用行为，并不能清除已有的后门或 Web Shell：
git clone https://github.com/jithinkrishnanrs/stylesmuggler-ioc-toolkit.git
cd stylesmuggler-ioc-toolkit
sudo bash scripts/stylesmuggler_scan.sh --magento-root /var/www/html
或使用 Python 版本以获取结构化（JSON）输出，例如用于向 SIEM 提供数据：
sudo python3 scripts/stylesmuggler_scan.py --magento-root /var/www/html --json report.json
这两个脚本默认是只读的——它们只检测和报告，不会终止进程或删除文件，除非你传入 --remediate，因为过早清理会破坏取证证据（参见 docs/INCIDENT_RESPONSE.md）。