两款WordPress插件更新包被投毒,升级后还要查数据库

7月31日，北京时间晚上10点到次日凌晨3点左右，一些WordPress站点正常更新了Fluent Forms Pro 6.2.7或Ninja Tables Pro 5.2.11，拿到的却是被人改过的安装包。自动更新和手动点更新都可能命中。

插件厂商迁移过商店和授权系统，却留下了一台旧服务器，代理规则也还把部分更新请求送过去。攻击者进入旧服务器、替换插件包，网站再从可信更新通道下载并执行了里面的恶意代码。

代码执行后可以写入数据库和自动加载目录，创建管理员、写文件、停用安全插件，还可能读取wp-config.php里的数据库凭据。厂商已经在处置中见过这些动作，但没有证据说明每个下载问题版本的站点都发生了数据泄露。

01｜一次迁移留下了两条更新路线

更新请求先到代理，再由代理决定哪台服务器返回文件。新系统已经上线，旧服务器却没有关，几条旧路由也没有删除。攻击者不用伪造下载网站，只要控制旧服务器，就能让被改过的文件沿着厂商自己的域名和更新流程进入客户网站。

厂商称约295个客户账户下载了问题包，并向1,368名在相邻时间下载过插件的客户发出提醒。较宽的通知范围源于日志只能记录谁请求过文件，不能精确证明每个请求最终拿到哪一份缓存副本。

这次事故给迁移工作划出了一条清楚的完成线。新系统能用还不算结束，旧入口必须停止响应，代理规则必须逐条清空，旧密钥和服务器也要退役。

厂商当晚发布了Fluent Forms Pro 6.2.10和Ninja Tables Pro 5.2.14。升级会替换插件目录里的问题代码，却无法自动抹掉代码运行时写进数据库、mu-plugins目录和计划任务的内容。

mu-plugins里的文件会在每次请求时自动加载，后台普通插件列表里也没有停用按钮。数据库里的恶意记录还能继续调用后门。安全扫描没有报警，同样不能替代厂商给出的文件和数据库核验。

先查7月31日和8月1日的更新记录。只要站点在这段时间取得上述两个问题版本，或收到厂商提醒，就不要停在“已经升级”。把站点交给维护人员、主机商或厂商支持，按官方指标检查插件目录、mu-plugins、上传目录、数据库、计划任务和管理员账户。

一旦命中指标，先隔离和清理，再轮换管理员、数据库、主机、SFTP、SMTP、支付接口和其他站内密钥。清理前改密码，可能把新密码再次交给仍在运行的代码。24小时后还要复查一次，确认留存项没有重新出现。

我的倾向很明确。命中版本与时间窗的站点，应按已入侵处置；没有命中、当前版本干净且核验无异常的站点，不必因此关闭所有自动更新。未来30天，厂商若仍未给出校验和机制的上线时间和完整收尾报告，使用这两款Pro插件的生产站应先在测试站验证更新，再推到正式环境。更新通道可以继续信任，但必须留下能核对的证据。