To fix exposed backup files, delete every backup archive and config copy from your web root (backup.zip, wp-config.php.bak, database.sql, etc.), store backups off-site only, and rotate any credentials that were inside them. Re-scan to confirm paths return 404.
Backup files left in public web directories are a goldmine for attackers — full database dumps, WordPress config with passwords, and site archives downloadable with a single URL. Removing them from web-accessible paths and rotating exposed credentials fixes the finding.
Check your website
See how your site handles how to fix exposed backup files — free, no account needed.
Business impact
An exposed backup.zip or database.sql can hand attackers your entire customer database, admin credentials and source code in one download. This is a common cause of data breaches on small business sites. Fixing it takes minutes; ignoring it can end your business.
Why this happens
The scanner probes paths like /backup.zip, /wp-config.php.bak, /database.sql, /dump.sql and flags HTTP 200 responses with matching content. Developers and plugins often create .bak, .old, or .zip copies during updates and forget to delete them. SQL dumps left after migrations are especially dangerous — they contain raw user data.
How to confirm the issue
Manually: try https://yoursite.com/backup.zip and /wp-config.php.bak. Any download or readable config means exposure.
With Plexa Trust: look for "Backup Archive Exposed", "WordPress Backup Exposed" or "SQL Database Dump Exposed". Re-scan after removal.
Step-by-step fix
Search your web root for backup patterns:
*.zip,*.sql,*.bak,*.old,wp-config.*.Delete every backup file from public web directories.
Store future backups outside the document root or in off-site/cloud storage only.
If a SQL dump or wp-config backup was exposed, rotate database passwords and API keys.
Configure your backup plugin to save off-site, not in the web root.
Re-scan to confirm all backup paths return 404.
Platform-specific fixes
WordPress
Check web root via FTP/SFTP for backup.zip, wp-config.php.bak, wp-config.txt, *.sql.
In backup plugins (UpdraftPlus, etc.), set remote storage — disable local backups in web root.
After removing wp-config backups, change the database password in hosting panel and wp-config.php.
cPanel / shared hosting
File Manager → public_html — search for .zip, .sql, .bak, .tar.gz files and delete.
Use cPanel backups (stored outside web root) instead of manual zips in public_html.
Developer workflow
Add *.sql, *.bak, backup.zip to .gitignore.
Never upload database dumps to production web space for "convenience".
Use secure transfer (SFTP, S3) for migration files, then delete immediately.
Apache / Nginx
Optionally block common backup extensions: deny .sql, .bak, .zip in server config.
Defence in depth — but deleting exposed files is the real fix.
How to verify the fix
Automate backups to off-site storage (S3, Google Drive, host backup service).
Never leave migration or restore files in public directories after deploys.
Rotate credentials if any config backup was ever publicly accessible.
Re-scan with Plexa Trust and confirm backup findings clear.
Common mistakes
Renaming backup.zip to backup.zip.old instead of deleting it.
Leaving SQL dumps in public_html after a database migration.
Backup plugins saving archives inside the web root by default.
Not rotating DB passwords after wp-config.php.bak was exposed.
Frequently asked questions
Which backup filenames are dangerous?
backup.zip, database.sql, dump.sql, wp-config.php.bak, wp-config.php.old, wp-config.txt, and any .sql or .zip in the web root.
Where should backups be stored?
Off-site only — cloud storage, host backup service, or a directory outside the web root. Never in public_html or /var/www/html.
Do I need to rotate passwords if backup.zip was exposed?
If the archive contains wp-config, .env, or database dumps — yes, rotate every credential inside it.
Can I block .zip files via .htaccess?
You can deny .sql and .bak extensions, but deleting exposed files is essential — blocking alone does not remove already-public files if rules fail.
My backup plugin saves locally — is that OK?
Only if the folder is outside the web root and access-controlled. Never in public_html.
What about automated host backups?
Host-level backups (IONOS, cPanel) are stored outside your web root — those are fine. The risk is manual copies you create in public directories.
How do attackers find backup files?
Automated scanners probe hundreds of common paths including /backup.zip and /database.sql.
How do I confirm the fix?
curl common backup URLs — all should 404. Re-scan with Plexa Trust.
Think you've fixed it?
Run a free scan to verify the issue is resolved. Upgrade to Pro on Plexa Trust for the full audit, monitoring alerts, and score history.
Verify with a free scan