文章总结： WordPress备份插件EverestBackup与BackWPUp依赖Apache专属的.htaccess保护敏感文件，但在Nginx、Caddy等非Apache服务器上该机制失效，导致备份文件与数据库备份可被未授权下载。EverestBackup漏洞未修复，BackWPUp已在v5.7.4修复。建议用户检查服务器类型，避免依赖.htaccess，改用插件官方安全机制或服务器层访问控制。
综合评分： 85
文章分类： 漏洞分析,WEB安全,应急响应
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 服务器 |
| — | — |
| 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
END
公众号内容都来自国外等平台- 搜索的内容通过结合编写 –
公众号 | AnQuan7 (Ots安全)
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Ots安全 《WordPress 备份插件，可能正在”裸奔”：一个只认 Apache 的 .htaccess 把站点卖了》