Description

The BackWPup WordPress plugin before 5.7.7 does not properly restrict web access to the working directory it uses during backup restores, allowing unauthenticated attackers, on webservers that do not honour .htaccess rules such as NGINX, to download the full backup archive (database dump and site files, including credentials and secret keys) left behind by an interrupted restore.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-10-08T06:16:44.617Z",
  "pubdate": "2026-10-08T06:16:44.617Z",
  "executiveSummary": "The BackWPup WordPress plugin prior to version 5.7.7 contains a critical security vulnerability involving improper access control for its backup restore working directory.\nThis flaw allows unauthenticated, remote attackers to access and download sensitive backup archives, including database dumps, source code, and configuration files containing secrets.\nThe issue specifically impacts web server environments that do not respect .htaccess rules, such as NGINX, where traditional directory protection mechanisms fail to apply.\nBy targeting the predictable directory path used during an interrupted backup restore process, an attacker can obtain a complete snapshot of the WordPress installation.\nThe risk implication is severe, as exposed files often contain database credentials, authentication unique keys, and salts, enabling full site compromise, privilege escalation, or further lateral movement within the hosting infrastructure.\nExploitation requires no authentication or special privileges, making it a low-complexity attack for actors with visibility into the target web server's directory structure.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient enforcement of access control mechanisms within the BackWPup plugin's restore workflow. During the restore process, the plugin creates a working directory to temporarily hold backup files. If the restoration process is interrupted, these files—including full database dumps and sensitive site configuration files such as wp-config.php—are left behind in the filesystem.\nThe security mechanism originally intended to prevent public access to these files relies on .htaccess directives. Because these directives are only parsed by Apache-based web servers, the protection is non-functional on NGINX or other non-Apache environments. Consequently, the directory and its contents remain publicly accessible via HTTP GET requests if the directory path is known or discovered.\nThe attack flow proceeds as follows: First, an attacker identifies a target site using a vulnerable version of BackWPup. Second, the attacker triggers or waits for a backup restore process to be interrupted, leaving the sensitive data in the default working directory. Third, because the directory lacks proper NGINX configuration (e.g., location block restrictions), the attacker performs direct enumeration or guesses the directory path to locate the backup archive.\nOnce the path is identified, the attacker issues unauthenticated HTTP requests to download the sensitive archives. The payload behavior is passive; the attacker simply retrieves the site's entire database and file system, which serves as a treasure trove of information.\nPost-exploitation impact is catastrophic: The database dump typically contains the wp_users table, which includes hashed passwords and user metadata. Access to wp-config.php provides clear-text database credentials and security keys used to encrypt session cookies. With this information, an attacker can gain administrative access to the WordPress dashboard, modify plugin code to implement persistent backdoors, or pivot to the underlying database server if it is externally reachable."
}