- Ultrastrike found two WordPress backup plugins could expose data on servers that ignore .htaccess files. BackWPup is fixed in version 5.7.4; Everest Backup is unpatched.
- BackWPup exposure needs a prior restore. Everest Backup exposure needs a backup in progress. Protection that depends on the web server can be lost when hosting changes.
- Check which server runs each WordPress site and audit plugins that write .htaccess files. Ask the same question before any hosting move or plugin approval.
A security rule only works if something reads it. Ultrastrike, a security firm, found two WordPress backup plugins that placed their protection in a file many web servers ignore. On those servers the protection does not apply. Under certain conditions, data can then be reached: during a backup for one plugin, after a past restore for the other. Ultrastrike describes what an attacker could do, not an attack that happened.
A rule that only one server understands
Ultrastrike observed that certain plugins place a small access-control file, called .htaccess, in their own folders. The plugin appears to count on it to keep items such as backups and uploads private. The file lists which visitors may fetch which files in that folder and everything below it.
Apache reads these files and enforces them. Nginx, IIS and Caddy do not support them, the researchers report. Nginx ignores the file and serves the folder's contents. LiteSpeed was the one non-Apache server the team found that does support .htaccess.
Two plugins, two different conditions
Everest Backup stores backups in wp-content/ebwp-backups/. Each file name carries a random string, so outsiders cannot guess it. During a backup, the plugin writes progress to a file called .PROCSTAT in that folder. As the job nears completion, the file holds the full name of the new backup.
On Apache, the .htaccess file blocks .PROCSTAT. On a non-Apache server, anyone can download it without logging in. While a backup is running, an attacker could read the name, fetch the backup, and obtain uploads, plugin files and a copy of the database.
The vendor first said version 2.3.13 fixed the issue. Ultrastrike's retest found it still present. The vendor then stopped responding. The researchers say the flaw is unpatched as of publication.
BackWPup has a narrower gap. When an admin restores a backup, the plugin unpacks it into wp-content/uploads/backwpup-restore/extract/. That includes manifest.json, which names the database backup. On Apache, a deny rule blocks the folder. On other servers, an attacker could read the manifest and then download the database file.
The unpacked files stayed after the restore finished, so the window could last months. A site is exposed only if it has restored at least one BackWPup backup. Version 5.7.4 closes the gap: restores no longer unpack the manifest, so there is nothing left to read. Ultrastrike praised the team's quick response.
Which hosting setups are in scope
Ultrastrike checked the quick-deploy WordPress options at several hosting providers. DigitalOcean's marketplace image uses Caddy. Azure App Service uses Nginx. WordPress.com uses Nginx as its backend server. All three ignore plugin-created .htaccess files.
AWS Lightsail, DreamHost, LiquidWeb and Bluehost run WordPress on Apache. Akamai's Linode lets the customer choose Nginx or Apache. Organisations that host their own sites pick their own server, so the review covered only cloud and managed options.
The "Server" header can mislead. LiquidWeb and Bluehost show "nginx" there. That comes from a reverse proxy, a front-door server that passes requests on. Apache runs the site behind it, so .htaccess still works.
That figure is a starting point, not a count of vulnerable sites. Many of those sites may sit behind an Nginx proxy with Apache behind it. The researchers say so themselves.
The control lives in the environment, not the plugin
The lesson here is that a protection kept in a server file is a promise made by the environment, not by the plugin. The plugin's code never checks that anyone is listening. If the environment changes, the promise can lapse without a single line of code changing.
That has three consequences for decision-makers. First, plugin approval. When you approve a plugin, you also approve its assumptions about the server. Ask vendors which server types they test on, not only which WordPress versions.
Second, hosting moves. Ultrastrike notes that a file protected on Apache may be exposed on another server. A migration to a managed platform or a new cloud image is a security change, even when it is sold as a cost or speed decision. Three of the quick-deploy options reviewed use non-Apache servers.
Third, vendor vetting. The two vendors here responded very differently. BackWPup shipped a fix. Everest Backup claimed one, failed a retest, then went quiet. How a vendor handles a report is part of the risk you are buying.
What to ask your team
Start with a plain question: which web server runs each of our WordPress sites directly? Do not rely on the Server header. The researchers checked from PHP itself.
Then ask for a search of each web root for .htaccess files. For every one found, ask whether sensitive files with predictable names sit in that folder or below it. Backups, logs and extracted archives are the examples in this research.
If you cannot reach the web root, Ultrastrike suggests fingerprinting installed plugins with WPScan. Then rebuild the same plugins on a test site and look for sensitive files in folders that hold .htaccess files. Ask the same questions before any hosting move.
Check whether Everest Backup is installed anywhere, and update BackWPup to 5.7.4 or later. Custom plugins are in scope too. The researchers say the issue affects any plugin, and developers should build for every server it could run on.
A rule the server does not read is not a control. It is a hope.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: ultrastrike.io.
