WordPress 备份插件，可能正在\"裸奔\"：一个只认 Apache 的 .htaccess 把站点卖了

Ots安全

2026年10月2日 15:26
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

威胁简报

恶意软件

漏洞攻击

一、背景：WordPress 跑在谁的服务器上，插件其实管不着

WordPress 用 PHP 写，理论上跟哪家 Web 服务器都能搭。Apache 和 Nginx 是最常见的组合，但远不止这两家。

站点功能的扩展靠插件，而插件在带来能力的同时，也把自身的安危绑上了整站的安全。问题就出在：很多插件为了\"拦住\"某些敏感文件（比如备份、上传目录），选择在目录里塞一个 .htaccess。

二、核心原理：.htaccess 只是 Apache 的\"方言\"

.htaccess 是 Apache 的\"目录级防火墙\"：放在某个目录里，就能对该目录及其子目录下发 Allow/Deny 规则。例如下面这段，禁用目录索引并拒绝访问所有 .zip / .gz：

Options -Indexes<FilesMatch \"\\.(zip|gz)$\">  Order allow,deny  Deny fromall</Files>

甚至一行就能封死整个目录：

deny fromall

关键在于：这套机制是 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 专属大厂，默认就把你推到了非 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。响应头里的服务器名，不能单独作为判断依据。

参考地址

1. 原文（Carl Pearson / UltraStrike）：https://ultrastrike.io/2026/10/server-specific-vulnerabilities-in-wordpress-plugins/
2. Everest Backup 插件页：https://wordpress.org/plugins/everest-backup/
3. BackWPUp 插件页：https://wordpress.org/plugins/backwpup/
4. BackWPUp 相关 CVE-2026-86815（REST 路由缺失鉴权，5.7.5 修，与本文不同）：https://www.cve.org/CVERecord?id=CVE-2026-86815
5. WPScan 工具：https://github.com/wpscanteam/wpscan
6. WordPress 主机环境手册：https://make.wordpress.org/hosting/handbook/server-environment

END

公众号内容都来自国外等平台- 搜索的内容通过结合编写 -

公众号 | AnQuan7 (Ots安全)