插件目录里塞一个 .htaccess，就能把敏感文件拦在门外？这个假设在 Apache 上成立，但你的站点真的跑在 Apache 上吗？近期 UltraStrike 披露的一组 WordPress 备份插件漏洞，恰恰戳破了这个默认假设。云栈社区整理了这份技术复盘，供运维和安全同学参考。
一、背景：WordPress 跑在谁的服务器上，插件其实管不着
WordPress 基于 PHP 构建，理论上可以搭配任意主流 Web 服务器。Apache 和 Nginx 是最常见的组合，但实际选择远不止这两家。
站点功能扩展几乎离不开插件。插件在带来便利的同时，也把整站安全的担子挑了起来。问题在于：不少插件会选择往目录里放一个 .htaccess 文件，试图靠它来拦截敏感内容——比如备份文件、上传目录。
二、核心原理：.htaccess 只是 Apache 的“方言”
.htaccess 是 Apache 的“目录级防火墙”：放在某个目录里，就能对该目录及其子目录下发 Allow/Deny 规则。例如下面这段，禁用目录索引并拒绝访问所有 .zip / .gz：
Options -Indexes
<FilesMatch "\.(zip|gz)$">
Order allow,deny
Deny from all
</Files>
甚至一行就能封死整个目录：
deny from all
关键在于：这套机制是 Apache 专属的。 Nginx、IIS、Caddy 都不认 .htaccess 文件——它们在读到这个文件时会直接忽略，照常对外提供目录里的内容。研究中仅有 LiteSpeed 这一款“非 Apache 却支持 .htaccess”的异类。
所以本文里说的“非 Apache”，指的是不支持 .htaccess 的服务器。当插件把安全建立在 .htaccess 之上、而站点却跑在 Nginx / Caddy 上时，那道“防火墙”就形同虚设，敏感文件随之暴露。
三、案例一：Everest Backup —— 厂商说修了，其实没修
Everest Backup 是款站点备份插件。它把备份文件存在 <web根>/wp-content/ebwp-backups/，文件名里带一段随机串，本意是防止被猜到。该目录里也放了一个 .htaccess。
备份进行中，插件会把当前状态持续写入一个名为 .PROCSTAT 的文件。这个文件名是固定的、可预测的——于是 .htaccess 就成了保护它的关键手段。
在 Apache 上，.htaccess 挡住了 .PROCSTAT 的下载；但在非 Apache 上，任何匿名的远程访客都能直接把它拉下来。
当备份临近完成时，.PROCSTAT 里会写出该次备份的完整文件名。攻击者拿着这个文件名，就能直接下载整站备份——上传数据、插件产物、数据库备份全在里面。
披露时间线（原文披露）：UltraStrike 自 2026-08-17 起多次联系厂商，厂商一度声称 v2.3.13 已修复；复测证明漏洞依旧，后续厂商停止回应。截至 2026-10-01 公开披露，该漏洞仍未修补。
本文增补（核实）：该 Everest Backup 的 .PROCSTAT 问题为厂商未确认、未打补丁的原创性披露，截至发稿尚无第三方独立复现或 CVE 编号，归为“公开信息未说明 / 尚未被第三方独立证实”，请相关用户以厂商后续公告为准。
四、案例二：BackWPUp —— 修好了，但教训同样深刻
BackWPUp 也是备份插件。当管理员从备份还原时，它会把备份解包到 <web根>/wp-content/uploads/backwpup-restore/extract/，其中包含一个 manifest.json（记录备份里各文件、包括数据库 .sql 文件名等元数据）。该目录同样挂了一个 .htaccess 拒绝规则。
在 Apache 上，下载 manifest.json 会得到 403：
而在非 Apache 上，manifest.json 可以被直接下载：
攻击者解析 manifest.json 拿到数据库 .sql 的文件名，再直接下载数据库备份：
影响：未授权拿到一份站点数据库副本。更糟的是，BackWPUp 还原后不会删除解包文件——攻击者可能在最后一次还原的几个月后还能下到 manifest.json。当然，前提是站点至少还原过一次备份，否则目录里根本没有可下之物。
修复：BackWPUp 在 v5.7.4 中改为还原时不再解包 manifest.json，从源头消除了该攻击向量。UltraStrike 也点名表扬了团队的响应速度。
本文增补（核实与澄清）：经交叉检索，BackWPUp 在 2026 年确有多个独立漏洞（如 CVE-2026-86815：Job REST 路由缺失鉴权导致数据库备份外泄，影响 5.2.2–5.7.4、由 5.7.5 修复）。本文讨论的“非 Apache 下 manifest.json 暴露”是另一个不同的问题，按原文叙述由厂商于 5.7.4 修复、且原文未提及 CVE 编号；请勿与 CVE-2026-86815 混淆。
五、你的站中招了吗？托管商环境实测
这事到底多普遍？UltraStrike 拉了一批主流托管商的“一键 WordPress”方案，看它们后台到底跑什么服务器：
| 托管商 |
默认 WordPress 服务器 |
| DigitalOcean |
Caddy |
| Azure AppService |
Nginx |
| AWS LightSail |
Apache |
| Akamai (Linode) |
用户自选 Apache 或 Nginx |
| WordPress.com |
Nginx |
| DreamHost |
Apache |
| LiquidWeb |
Apache（前端 Nginx 反代） |
| BlueHost |
Apache（前端 Nginx 反代） |
两个大云厂商 + 一个 WordPress 专属大厂，默认就把你推到了非 Apache 的坑里。
各家的细节也很有意思：
- DigitalOcean 的 Marketplace 镜像是 Caddy——明确不支持
.htaccess，照常吐目录内容。
- Azure AppService 用 Nginx，同样忽略
.htaccess。
- AWS LightSail 预置的是 Apache，插件写的
.htaccess 会被纳入访问控制。
- Akamai (Linode) 创建时让用户自己选 Nginx 或 Apache，支不支持
.htaccess 看你当时选了啥。
- LiquidWeb / BlueHost 的响应头写着
Server: nginx，但那是前端反向代理的标识，后端实际跑的是 Apache——所以 .htaccess 仍然生效。
研究还顺手查了 Shodan：仅按 Nginx 过滤就有超过 2.9 万个 WordPress 站点返回 Nginx 标识——但其中很多可能像 LiquidWeb/BlueHost 那样只是反代，真实后端未必是 Nginx。响应头里的服务器名，不能单独作为判断依据。
参考地址
- 原文（Carl Pearson / UltraStrike）：https://ultrastrike.io/2026/10/server-specific-vulnerabilities-in-wordpress-plugins/
- Everest Backup 插件页：https://wordpress.org/plugins/everest-backup/
- BackWPUp 插件页：https://wordpress.org/plugins/backwpup/
- BackWPUp 相关 CVE-2026-86815（REST 路由缺失鉴权，5.7.5 修，与本文不同）：https://www.cve.org/CVERecord?id=CVE-2026-86815
- WPScan 工具：https://github.com/wpscanteam/wpscan
- WordPress 主机环境手册：https://make.wordpress.org/hosting/handbook/server-environment
发表于 前天 23:33
|
查看: 26|
回复: 0
