953家网店被注入恶意脚本，扫描器访问一律空手而归

一个身份不明的攻击者感染了953家在线商店，其中大多数运行Magento。这场活动自2025年7月起持续至今，荷兰电商安全公司Sansec披露了相关细节。

攻击的落点很具体：往商店页面里塞一小段代码。当毫不知情的访客打开页面时，这段代码通过Magento的CMS区块，向浏览器投放恶意的JavaScript加载器。

Sansec对这套机制的解释是：访客一进页面，浏览器就会去问攻击者那边的服务器"接下来做什么"。服务器先判断来者是真实购物者还是安全扫描器——扫描器什么也拿不到。

五个域名，一条时间线

随着活动推进，至少出现过五个不同的域名：

• manulfie[.]click，首次出现于2025年7月
• neswnsssn[.]click，首次出现于2025年12月
• lanhd6549tdhse[.]top，首次出现于2026年3月
• additionalver[.]com，首次出现于2026年6月
• deepveindrilling[.]com，首次出现于2026年10月

Sansec称，自deepveindrilling[.]com于2026年10月6日注册以来，已在83家在线商店的CMS区块中发现了这个域名。最新的加载器域名托管在Cloudflare之后，只响应来自被感染商店真实访客的脚本请求。

加载器被安放在Magento的cms_block数据库表中，这张表原本用于把静态内容渲染到店铺前台页面。攻击的最终目的，就是在购物者打开被入侵网站、CMS区块完成渲染的那一刻，让攻击者控制的代码跑起来。

至于攻击者是修改已有的CMS区块（比如页头、页脚或促销横幅），还是新建一个区块，Sansec没有披露。两种方式都能让加载器运行。

两个版本，一层比一层难缠

目前观察到加载器有两个版本。第一个版本把从攻击者域名加载的外部JavaScript所携带的载荷存进浏览器的localStorage，这样即便外部域名后来不可用，暂存的代码在后续访问中仍会被再次执行。

第二个版本在此基础上更进一步：加入浏览器指纹检测，把机器人和安全扫描器过滤掉，确保只有真实购物者会接触到恶意代码。最终载荷的确切性质仍不清楚。

活动早期阶段还用过Keitaro——一个广告追踪与分析平台——充当流量分发系统，根据访客特征返回不同响应：投放载荷、跳转，或者什么都不给。

Sansec举例说，以Windows桌面访客身份请求additionalver[.]com的脚本，返回的是"QWE=123;"，除了设置一个为期24小时的访客标记Cookie之外什么也不做。而deepveindrilling[.]com则去掉了Keitaro组件，把机器人过滤逻辑直接整合进加载器本身。

入口在哪

初始入侵途径方面，估计有471家Magento商店是通过PolyShell（即CVE-2026-48356）漏洞被注入加载器的。另有102家商店的文件是通过PolyShell或SessionReaper（即CVE-2025-54236）漏洞上传的。

Sansec描述了一个案例：一家运行Magento 2.4.7-p1的商店，在pub/media/custom_options/quote/目录下出现了伪装成PNG图片的PolyShell webshell，紧挨着CMS区块里的additionalver.com加载器。该区块在10月7日切换到了deepveindrilling[.]com。这家商店至今仍未安装APSB26-73——Adobe针对受支持版本线的PolyShell修复。

另一个案例里，一家运行Magento 2.4.7-p10、核心补丁一个不缺的电商商店被入侵，攻击者添加了一个流氓管理员账户，再用它注入代码。

Sansec建议站点所有者审计是否存在可疑账户，并检查cms_block和cms_page表中是否有意料之外的CMS区块，同时保持站点更新、强制使用强密码。

这次披露的背景是PHP2Shell——PHP中的两个严重漏洞（CVE-2026-109618和CVE-2026-109619），在上周公开后已出现大量利用尝试。Perplexity研究员Adel Karimi记录到，这似乎是这些漏洞首次在野成功利用、在蜜罐服务器上执行shell命令。观察到的命令使用wget、curl或PHP CLI从远程服务器（"162.35.99[.]94:80"）获取额外载荷。目前尚未观察到下载成功的第二阶段产物。