Adobe Commerce 文件上传漏洞遭大规模利用：Magento 网店该如何排查和加固-速维云

事件概述：953 家网店被注入恶意脚本，漏洞三天前被正式列入 KEV

荷兰电商安全公司 Sansec 近日发布报告，披露一轮针对 Magento / Adobe Commerce 网店的大规模入侵活动：约 953 家电子商务商店被注入恶意 JavaScript 加载器，其中约 471 家是通过一个名为 PolyShell 的文件上传漏洞（CVE-2026-48356）上传 WebShell 完成入手的，另有 102 家店的入口是 PolyShell 或另一个已知漏洞 SessionReaper（CVE-2025-54236）。

2026 年 10 月 27 日，美国 CISA 正式将 CVE-2026-48356 列入"已遭利用漏洞目录"（KEV），要求联邦民事行政机构在 11 月 10 日前完成修复。值得注意的是，这个漏洞的官方补丁早在 2026 年 7 月就已随 Adobe Commerce 例行安全公告 APSB26-73 发布，当时 Adobe 将其标注为优先级 2，并称"未发现在野利用"。三个半月后，情况发生了变化：补丁还在，但大量站点没有打。

漏洞原理：购物车"自定义选项"里的文件上传

PolyShell 的问题出在 Magento REST API 处理购物车商品自定义选项的环节。当商品选项类型为"文件"时，接口会接收一个内嵌的 file_info 对象，其中包含 base64 编码的文件数据、MIME 类型和文件名，文件最终被写入服务器的 pub/media/custom_options/quote/ 目录。由于该路径未对文件类型和扩展名做有效限制，攻击者可以未认证地上传伪装成图片的 PHP WebShell；再结合常见的 Web 服务器配置，上传的文件可能被直接执行，形成远程代码执行，或者退而实现存储型 XSS 与账户接管。

该漏洞评分为 CVSS 3.1 的 9.3 分（AV:N/AC:L/PR:N/UI:R/S:C），无需任何账户权限即可触发，攻击面就是面向公网的商店 REST 接口。Sansec 在其披露的案例中展示了一家运行 Magento 2.4.7-p1 的商店：pub/media/custom_options/quote/ 目录下出现了伪装成 PNG 图片的 PolyShell WebShell，紧邻着 CMS 区块里的外部脚本加载器——两者配合完成入侵与持久化。

影响范围：2.4.4 到 2.4.9 全线，云版也要确认

受影响的版本包括 Adobe Commerce 与 Magento Open Source 2.4.4 至 2.4.9 的各支持分支（即 2.4.4-p18 及更早、2.4.5-p17 及更早、2.4.6-p15 及更早、2.4.7-p10 及更早、2.4.8-p5 及更早的补丁级别），以及 Adobe Commerce B2B 1.3.3 至 1.5.3。修复版本为 2026 年 7 月各分支对应的安全发布（APSB26-73）。

需要特别提醒的是时间线：该漏洞今年 3 月首次被披露时，Adobe 只修复了 2.4.9-alpha2 预发布分支（APSB25-94），生产分支直到 7 月才拿到独立补丁，中间几个月生产环境实际上是裸奔状态。使用 Adobe Commerce Cloud 或托管服务的站点，应向服务商确认云端补丁是否已包含该修复——云环境自动打补丁的节奏和自建站点并不相同。

电商站点直接接触支付与订单数据，是数字撇取攻击的典型目标

这次攻击是怎么做的：过滤扫描器，只打真实顾客

Sansec 追踪到的攻击链有几个值得注意的特征。入侵者放置的加载器脚本会从攻击者域名加载外部 JavaScript，并把载荷存进浏览器 localStorage——即使外部域名后续被封，暂存的代码仍能在顾客再次访问时继续执行。第二个版本更进一步，加入浏览器指纹检测，主动过滤机器人和安全扫描器，确保只有真实购物者会接触到恶意代码。攻击早期还用过 Keitaro 流量分发系统，根据访客特征决定投放载荷、跳转或无响应。以普通桌面访客身份请求时，脚本甚至只返回一个无关紧要的标记 Cookie，扫描器很难发现问题。

从手法上看，这是典型的数字撇取（digital skimming，即 Magecart 式攻击）链路：WebShell 负责在服务器端落脚，CMS 区块负责向前端页面注入加载器，最终瞄准的是结账流程中顾客输入的支付信息。目前最终载荷的确切性质尚未完全明确，但其持续运营的基础设施已经在多个域名间切换。

另一个必须正视的事实是：Sansec 报告的案例中，有一家核心补丁一个不缺、运行 Magento 2.4.7-p10 的商店同样被入侵——攻击者添加了一个流氓管理员账户，再用它注入代码。这说明"打完补丁"并不等于"清理干净"，是否已经失陷需要单独排查。

排查思路：从版本、文件、数据库到账户

对站长和运维来说，建议按以下顺序做一次自查（具体以官方公告和专业取证为准，怀疑失陷时应先对服务器做镜像备份、保留证据，再动手处置）：

1. 确认版本。通过命令行 magento --version、composer.lock 或管理后台确认站点版本与补丁级别，对照上文修复版本线判断是否受影响；云版用户向服务商确认补丁覆盖情况。

2. 检查上传目录。重点查看 pub/media/custom_options/quote/ 下是否有伪装成 .png/.jpg 的 PHP 文件、近期被修改的可疑文件；同时对 pub/media/ 全目录做一次 WebShell 特征扫描。

3. 审计内容表。检查 cms_block 和 cms_page 数据表中是否出现意料之外的 CMS 区块或页面，尤其注意含有外部 script 标签、陌生域名的记录。

4. 审计管理员账户。检查是否存在陌生的管理员账号、异常的账号权限变更和登录记录，必要时重置全部管理员凭据。

5. 回查日志。检索 Web 访问日志中 REST API 自定义选项上传接口的异常调用记录，确认入侵时间窗口，作为后续处置的依据。

修复与缓解建议：升级为主，暴露面收敛为辅

根本修复是升级到所在分支 7 月对应的安全版本。升级生产环境前，建议先对文件与数据库做完整备份（快照不能替代备份），在测试环境验证主题与扩展兼容性，并安排在业务低峰期执行，同时预留回滚方案；重启或重载服务前，先评估对在线交易的影响。

对于暂时无法升级的站点，可以通过 Web 服务器规则或 WAF 限制 pub/media/custom_options/ 目录下 PHP 的执行与直接访问，降低 WebShell 被触发的概率。但要注意：Sansec 明确指出，单纯阻断目录访问并不能阻止文件上传，未部署 WAF 的环境仍可能被写入恶意文件，因此这只能作为过渡手段，不能替代升级。

如果排查确认站点已被入侵，不要只删除找到的 WebShell：应轮换所有管理员口令、API 密钥与数据库凭据，检查站点的计划任务与定时作业，评估顾客数据受影响的范围，并按照事件响应流程决定是否重建环境；涉及顾客支付数据的，还需考虑监管通报与顾客告知义务。

后续观察

CISA 的联邦修复期限是 11 月 10 日，KEV 目录通常意味着攻击活动会进一步升温，尚未升级的站点应把这件事提到最高优先级。Sansec 对该攻击活动的追踪仍在继续，加载器基础设施切换域名是这类攻击的常见操作，已修复的站点也建议保持对 CMS 内容表和外部脚本注入的持续监控。电商安全的教训反复出现：补丁发布了不等于补丁打了，打了补丁也不等于清理干净了——版本、文件、内容、账户、日志，每一层都要看。本文信息以 Adobe 官方安全公告及 Sansec 报告为准，操作前请结合自身环境评估。

文章版权归作者所有，未经允许请勿转载。

THE END