【运维实录】从一条腾讯云安全警报，到精准溯源 WordPress 插件高危漏洞
今天手机收到多条腾讯云安全报警，原本以为是常规误报，顺手排查后却发现是一次真实的 WebShell 攻击。本文记录了从提取告警“时空锚点”、分析 Nginx 访问日志，到匹配 CVE 漏洞情报及安全清场的全过程，整理成一套通用的 Web 入侵排查 SOP。
0x01 起因：被忽视的手机警报
今天上午，手机频繁响起短信提示音，打开一看是腾讯云发来的安全告警：提示服务器检测到高危木马文件（Php.Trojan.Php.Xdkl），落盘路径在 /tmp/ 目录。
起初我并没有太放在心上。作为运维和开发，这类安全警报偶尔会遇到一些误报或自动清理的事件。正好当时手头有网站编辑的工作要处理，打算等登录面板时“顺便”看一眼。
然而，当我打开宝塔面板和云安全控制台的告警详情时，两组数据引起了我的注意：
-
落盘时间极其精确：
11:24:42和11:58:46，且文件 MD5 相同。 -
触发进程：
php-fpm（运行用户为www）。
这两个特征直接告诉我：这不是误报，这是一次真实的 Web 漏洞利用攻击！ 攻击者已经利用 Web 服务的接口，成功将恶意代码写入了服务器的临时目录。
0x02 破案过程：日志比对与精准定位
服务器上运行着两个站点：一个是用于测试 Bricks Builder 的环境，另一个是给客户搭建的临时定制站点。究竟是哪一个被当成了突破口？
我开始配合 AI 辅助，按照标准的 DFIR（数字取证与应急响应） 逻辑展开溯源。
1. 抓取时间锚点，排查 Nginx 日志
既然告警给出了精确到秒的时间戳（11:24:42），且通过 php-fpm 触发，说明在那个时间点必然有对应 Web 请求。
直接在服务器终端运行命令，搜索该时间段内所有站点的 POST 请求（上传或爆破行为通常为 POST）：
grep -H "30/Jul/2026:11:2[4-5]" /www/wwwlogs/*.log | grep "POST"2. 真相大白：目标锁定客户临时站
命令输出后，结果一目了然：测试站完全没有异常请求，而客户的临时站点日志中，在 11:24:24 至 11:24:42 之间出现了一长串来自同一个恶意 IP 的密集 POST 请求：
103.149.90.37 - - [30/Jul/2026:11:24:25 +0800] "POST /wp-admin/admin-ajax.php?action=blc_save_attachments HTTP/1.1" 400 11
103.149.90.37 - - [30/Jul/2026:11:24:26 +0800] "POST /wp-json/blocksy/v1/review-attachments HTTP/1.1" 404 138
...
103.149.90.37 - - [30/Jul/2026:11:24:41 +0800] "POST /wp-admin/admin-ajax.php?action=blocksy_companion_save_attachments HTTP/1.1" 400 11
日志特征非常突出：
-
攻击手法：黑客利用自动化脚本，针对 Blocksy 主题及 Blocksy Companion 扩展插件的前端评价/附件上传接口进行轮询爆破。
-
致命一击：虽然前期大部分请求返回了
400或404，但最终在11:24:42成功命中漏洞接口，将恶意代码写入了/tmp/phpWHr48c。
0x03 匹配 CVE：锁定高危漏洞源头
拿到“Blocksy Companion + 附件上传 + 未授权”这几个关键字后，检索最新的安全情报（CVE-2026-58480）：
-
漏洞名称：
Blocksy Companion Pro - Unauthenticated Arbitrary File Upload（未授权任意文件上传） -
CVSS 评分：9.8 (Critical)
-
影响版本：
Blocksy Companion$\le 2.1.46$（官方在 $2.1.47$ 中修复） -
漏洞成因：插件在检查上传文件的扩展名时，使用了
strpos()校验.woff2或.ttf字符串，而不是验证文件末尾的真实后缀。攻击者通过伪造双后缀文件（如shell.woff2.php）绕过了校验。
事后，查看客户站点上安装的插件版本：Version: 2.1.45 —— 完美踩中漏洞区间！
0x04 彻底排查与无死角清场
找到漏洞根因后，必须确保黑客没有在网站内部留存“持久化后门”（常驻 WebShell）。
1. 检查关键时间窗口内的文件变动
排查从攻击发生时间（11:20）到升级插件完成时间（12:10）之间，网站根目录下所有被修改或新增的 PHP 文件：
find /www/wwwroot/站点目录/ -name "*.php" -newermt "2026-07-30 11:20:00" ! -newermt "2026-07-30 12:10:00" -ls检查结果为空！重点扫描的 wp-content/uploads/ 目录下也没有任何 .php 文件的踪影。
这说明：黑客的攻击被安全防护和系统权限限制在了 /tmp 临时目录，还没来得及向网站目录写入持久化后门，就被我们及时阻断了。
2. 闭环修复步骤
-
升补丁：立即将客户站点的
Blocksy Companion插件升级至最新版本（2.1.50）。 -
删残余：彻底清空系统临时目录下的恶意脚本：
rm -f /tmp/php*。 -
拉黑 IP：在防火墙/宝塔安全模块中将恶意 IP
103.149.90.37直接封禁。 -
重载服务：重启
php-fpm释放资源。
0x05 经验提炼：Web安全应急 SOP
经过这次实操，再次验证了安全无小事。面对类似的 WebShell 告警，可以总结为一套 四步快速排查 SOP：
-
一抓时间锚点：提取告警中的“精确时间（秒）”、“触发进程”与“落地路径”。
-
二查访问日志：利用时间戳 +
grep -H跨日志检索POST请求，快速锁定目标站点与漏洞接口。 -
三对 CVE 情报：结合接口路径与组件名称，查找对应 CVE 漏洞，核对本地组件版本。
-
四查窗口期后门：扫描“受袭至修复”时间窗口内的变更文件（重点关注
uploads目录），升级组件并清理残余。
