我的导航站被入侵了！WebStack主题漏洞复盘，很多人都中招了

事件背景

2026年4月中旬，使用 WebStack 导航主题的 WordPress 站点遭遇大面积入侵。攻击者利用主题内置的图片上传接口，无需登录即可上传任意 PHP 文件（webshell），进而完全控制服务器。本站（dh.kejilion.pro）也在此次事件中被攻破，以下是基于真实入侵日志的完整复盘与修复方案。

漏洞定位：WebStack 主题 ajax.php

漏洞出在 WebStack 主题的 inc/ajax.php 文件中的 io_img_upload() 函数：

核心问题如下：

1. 注册了 nopriv 钩子：add_action('wp_ajax_nopriv_img_upload', 'io_img_upload')，任何人无需登录即可调用
2. 扩展名白名单未生效：变量 $extArr 定义了只允许 jpg/png/jpeg，但实际从未校验，注释写着"使用前台 JS 判断"，服务端完全放开
3. 使用 rename() 代替 wp_handle_upload()：绕过了 WordPress 内置的文件类型安全检查机制
4. 无 nonce 验证、无权限检查：零认证即可上传任意文件

攻击者只需一行命令即可上传 webshell：

curl -F "[email protected]" https://目标站点/wp-admin/admin-ajax.php?action=img_upload

该漏洞已于 2026年4月15日被报告至 WebStack 官方 GitHub 仓库（Issue #76），截至目前主题作者尚未修复。

入侵时间线

Webshell 类型分析

本次入侵共上传 34 个 PHP 文件，按功能分类：

1. 全能 WebShell（最危险）

633KB 的 System Manager，带文件管理器 + 终端 + 数据库操作，密码 P@55w()rD，内置 Ace Editor 代码编辑器，等同于获得一个 cPanel 控制面板。

2. 冰蝎（Behinder）加密后门

3 个冰蝎 webshell，使用加密通信密钥 900bc885d7553375，攻击者通过冰蝎客户端执行任意命令，流量加密后 WAF 无法检测。

3. 数据库接管脚本

读取 wp-config.php 中的数据库凭据，直接连接 MySQL，将管理员密码改为 admin123。

4. 命令执行后门

system($_GET['cmd']) 等简单一句话木马，用于快速执行系统命令。

5. 文件上传跳板

简易上传器，用于上传更多 webshell，无需再走原始漏洞入口。

6. CVE 利用工具

标记为 PoC CVE-2026-1555 by RubahIlang / SNIPERGROUP，具备自动创建目录、批量上传、删除文件等功能。

WAF 为什么没拦住？

本站配置了 ModSecurity + OWASP CRS 规则集，且开启了拦截模式（SecRuleEngine On），但还是被绕过了。原因分析：

1. WordPress 排除插件过度放行：CRS 自带的 wordpress-rule-exclusions-plugin 默认开启，对 admin-ajax.php 和上传接口做了大量规则豁免，导致上传请求不被检查
2. 上传可以穿过，执行也没拦：Nginx 配置中 uploads 目录允许执行 PHP，webshell 上传后直接可运行
3. 混淆绕过检测：633KB 的大马使用 goto 跳转 + 八进制编码（\74\41\x44...），绕过了 CRS 的 PHP 注入规则（933xxx 系列）
4. 冰蝎加密通信：加密隧道使得出站检查同样无效

修复方案

第一步：修复 WebStack 主题漏洞

修改 inc/ajax.php 中的 io_img_upload() 函数：

• 移除 wp_ajax_nopriv_img_upload 钩子（未登录用户不能上传）
• 加入 nonce 验证 + 权限检查（至少需要 edit_posts 权限）
• 服务端强制扩展名白名单（jpg/png/jpeg/gif/webp）
• MIME 类型二次校验（finfo 检测真实文件类型）
• 使用 wp_handle_upload() 替代 rename()
• 同理修复 img_remove 函数，移除 nopriv 钩子

第二步：禁用废弃上传入口

inc/img-upload.php 文件自身注释已标明"弃用，已经移至ajax.php"，但该文件仍可直接访问，必须禁用或删除。

第三步：Nginx 禁止 uploads 目录执行 PHP

在站点 Nginx 配置中加入：

location ^~ /wp-content/uploads/ {
    location ~ \.php$ {
        deny all;
    }
}

这样即使有文件被上传，也无法被执行。

第四步：wp-config.php 安全加固

添加以下常量：

• define('DISALLOW_FILE_EDIT', true); — 禁止后台编辑主题/插件文件
• define('DISALLOW_FILE_MODS', true); — 禁止后台安装/更新/删除插件和主题

第五步：清理 webshell + 重置凭据

• 删除 wp-content/uploads/ 下所有 .php 文件
• 重置 WordPress 管理员密码
• 更换数据库密码
• 更换 WordPress 安全密钥（AUTH_KEY、SECURE_AUTH_KEY 等）
• 全盘排查其他目录是否有隐藏后门

通用排查清单

如果你也在使用 WebStack 主题，请立即执行以下检查：

1. find /path/to/wordpress/wp-content/uploads/ -name "*.php" -type f — 查找 uploads 下的 PHP 文件
2. grep -r "nopriv_img_upload" wp-content/themes/ — 确认是否存在该漏洞钩子
3. 检查 wp_users 表是否有异常管理员账号
4. 检查 wp_options 表中 siteurl 和 home 是否被篡改
5. 检查 Nginx/Apache 日志中是否有对 admin-ajax.php?action=img_upload 的异常 POST 请求
6. 在 Nginx 配置中禁止 uploads 目录执行 PHP

总结

这次事件的核心教训是：永远不要只在前端做安全校验。WebStack 主题的图片上传接口把扩展名校验放在了前端 JavaScript，服务端完全信任客户端提交的文件类型，加上 nopriv 钩子让任何人都能调用，形成了经典的"未授权任意文件上传 → RCE"攻击链。

安全从来不是一层防线的事。WAF、服务端校验、最小权限、文件执行限制——每一层都是最后一层的备份。只有纵深防御，才能在面对 0day 和应用漏洞时不至于一穿到底。