StyleSmuggler(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
社区失陷指标(IOC)、失陷扫描器以及缓解/修补指南,针对 StyleSmuggler(CVE-2026-75650)——由 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 更新,发布于 2026-09-08。Adobe 声明 VULN-39341 必须在此更新之外另行应用,而非替代它。 |
| CVSS | 10.0(3.1 和 4.0)— 严重 |
| CWE | CWE-1336,模板引擎中特殊元素的中和不当 |
| 官方补丁 | 已发布。 热修复 VULN-39341。覆盖范围并非普遍适用 — 见下表。 |
| 所需认证 | 无 — 未认证 |
| 受影响版本 | 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-07 加入 |
| 已知 Rust 植入变体 | [kworker/u:8:0](9 月 4 日)→ fc-cache v2.1.4(9 月 6 日)→ chronyd v2.1.5(9 月 7 日)— 同一操作者、同一代理 ID、版本递增 |
| 第二个无关攻击者 | PHP Web Shell 位于 pub/media/catalog/product/cache/,此前有 DNS 外传侦察探测 — 独立于 Rust 植入程序,确认于 2026-09-07 |
| 已知投递向量 | GraphQL styles[] 参数;无效商店代码记录到 var/log/system.log;通过 Magento 客户自定义选项上传文件;无关第二攻击者的 Store: 头注入 |
| 影响 | 远程代码执行 → 持久化 Rust 后门、独立 PHP Web Shell、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 |
如果您运行的是较旧、不受支持的版本,即使同样可被利用,Adobe 也不会为您提供修复。请参阅 docs/PATCHING.md 了解您的选项。
此信息变化很快。 在采取行动前请与主要来源交叉核对:Sansec 公告和 Adobe 公告。运行日志请参阅 docs/TIMELINE.md,更新任何内容时请注明来源。
Magento 自身的 GraphQL styles 参数及其基于依赖注入的文件扫描被滥用为一种两阶段、基于文件的延迟执行原语,而非单一的明显注入点:
var/log/system.log,或进入 var/report/<hash>),通过 GraphQL styles[] 参数、变异的请求头或(对于下方第二个无关攻击者)Store: 头走私进入。getProcessedTemplate 路径)会走一条代码路径,使 Magento 自身的 DI/代码扫描器 include() 被投毒的文件,从而运行攻击者的 PHP。您无需打开邮件——在服务端渲染它就足够了——而且即使邮件投递失败,该链也能触发。一个无需工具的简易早期预警信号:收件箱中收到一封乱码的“支付交易失败提醒”邮件,包含未渲染的原始 {{var ...}} 标签,且客户地址以 .invalid 结尾。这通常是第一个可见迹象,早于任何人检查日志。
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 植入程序并不意味着您的商店是干净的。
Rust 植入程序本身也在演变:最初的伪装为 [kworker/u:8:0] 的构建(9 月 4 日)之后是伪装为 fc-cache 的 v2.1.4 构建(9 月 6 日),以伪装成 NTP 流量的方式向外信标通信,然后是伪装为 chronyd 的 v2.1.5 重新部署(9 月 7 日)——同一植入程序、同一代理 ID——证明攻击者正在积极迭代以规避您发布的任何检测。Sansec 表示尚未看到证据表明该植入程序被武器化用于持久性/侦察之外——鉴于无关攻击者在同一访问路径上拥有可用的 Web Shell,请不要将此解读为令人安心的消息。
快速解答请参阅 docs/FAQ.md,完整技术分析和来源请参阅 docs/VULNERABILITY.md,应用 Adobe 官方修复请参阅 docs/PATCHING.md,扫描器发现异常时的处理请参阅 docs/INCIDENT_RESPONSE.md。
1. 如果您的版本受覆盖,请修补:
# 完整流程请参阅 docs/PATCHING.md — 这不是单行命令,需要
# Adobe 仓库凭据和您项目的补丁管理工具。
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)。
[kworker/u:8:0] 构建:~/.local/share/.gvfsd/gvfsd-user、其锁文件、/tmp/.kw_*、/tmp/.gvfsd_*fc-cache 构建 v2.1.4(9 月 6 日):~/.cache/fontconfig/fc-cache、/tmp/.fc_<8hex>.lockchronyd 构建 v2.1.5(9 月 7 日):/tmp/.chrony-<8hex>/chronydgvfsd-user 构建每 5 分钟一次,fc-cache 每小时两次(13,43 * * * *)[kworker/u:8:0]、 或 的,其由 root 拥有(或对于 /,与真实系统二进制不匹配)完整指标列表及来源:iocs/。
docs/PATCHING.md。这现在是优先事项,优先于下方的临时缓解措施。mitigations/ 中的临时缓解措施:
styles[] 投递路径
(nginx /
Apache)pub/media/pub/static 下的 PHP 执行
(nginx /
Apache)— 针对第二个无关攻击者 Web Shell 技术的定向防御mitigations/README.md — 这些措施均无法关闭客户自定义选项向量或第二攻击者的 头投递。docs/ 漏洞分析、时间线、FAQ、修补指南、事件响应手册
iocs/ 哈希、IP、域名、文件路径、YARA、Suricata/IDS 规则
scripts/ stylesmuggler_scan.sh / .py、crontab 清理辅助工具
mitigations/ nginx / Apache / ModSecurity / fail2ban 规则
CVE-2026-75650、APSB26-146、VULN-39341、Magento 零日漏洞 2026、Adobe Commerce 零日漏洞、StyleSmuggler 补丁、Magento GraphQL 漏洞、Magento styles 参数 RCE、gvfsd-user 恶意软件、fc-cache Magento 后门、chronyd Magento 恶意软件、Magento kworker 进程恶意软件、Magento Redis 会话劫持、Magento 未认证 RCE 2026 年 9 月、Magento 2.4.9 漏洞利用、Adobe Commerce 后门清除、Magento pub/media Web Shell、eComscan StyleSmuggler、Sansec Shield StyleSmuggler。
本仓库中的每个指标都追溯到已引用、已发布的来源 — 主要是 Sansec 的公告(至少更新至 2026-09-07 20:50 UTC)、Adobe 的 APSB26-146 公告,以及处理过活跃感染的事件响应人员的社区事件响应分析。请参阅 iocs/ 中每个文件底部的引用。
请勿将此处任何内容视为详尽或最终版本。IOC(触发头、用户代理字符串、植入伪装,以及现在第二攻击者的活动标记)在披露后数天内已多次变化;预计它们还会再次变化。在脚本允许的情况下,匹配形状和行为,而非仅匹配字面字符串。
发现了变体、新哈希、新源地址或误报?请提交 issue 或 PR,附上您观察到的内容及观察方式。请注意:
本仓库代码采用 MIT 许可证(见 LICENSE)。指标数据按“原样”提供,仅供防御使用,并全程注明来源。
这是非官方的、社区构建的防御工具,并非 Adobe 或 Sansec 产品,也与两者无关联。它按无担保方式提供。Adobe 的官方补丁(APSB26-146)已发布,但覆盖范围仅限于特定产品版本 — 在假设您的安装已受覆盖或已修复之前,请直接查看 Adobe 安全公告。
| 2.4.5 及以下 |
fc-cachechronydfc-cachechronyd/proc/<pid>/exe 镜像的 SHA-256(两者可能不同 — 已观察到植入程序在内存中自我更新)var/log/system.log、var/report/)中的注入 PHP、两种已知触发头形状(X-TRACE-<10hex> 和 X-<12hex>),以及第二个无关攻击者的活动标记(ss5_/ss6_<hex>)和 DNS 金丝雀域名(oast.site)MG<20hex>::...::/MG<20hex>)pub/media 下的 PHP 文件 — 在配置正确的 Magento 商店中不应包含可执行 PHP — 匹配第二攻击者的 Web Shell 投放模式fc-cache/chronyd 构建向 ntp.timesync.to:123/UDP(及备用地址)的 NTP形态信标通信,以及其对公共 IP 查询服务的明文 HTTP 调用127.0.0.1:6379 进行,零出站 C2 流量 — 安静的网络并非干净的网络)— 请注意,仅将会话从 Redis 迁移并不能关闭第二条基于文件上传的利用向量Store:app/etc/env.php。至少,在隔离后:清空会话存储(Redis 和/或数据库)、轮换 Magento crypt/key、所有管理员密码(并使现有管理员会话失效)、数据库密码、env.php 中的每个支付提供商 API 密钥和其他集成凭据,以及站点用户可读取的任何 SSH/部署密钥。同时检查 admin_user 表是否存在恶意账户,以及 pub/media/ / pub/static/ / 主题目录中是否被投放了 Web Shell — 包括 Rust 植入程序和无关第二攻击者的 — 然后才能认为商店是干净的。完整有序步骤:docs/INCIDENT_RESPONSE.md。