WordPress Backup Security Public File Scan Runbook
WordPress backups, SQL dumps, migration packages, and old wp-config copies should never be reachable from public URLs. If they are, treat the finding as a possible data exposure, not only a cleanup task.
Use this for WordPress sites after a migration, staging copy, backup plugin change, hosting move, malware review, or Search Console query that suggests exposed files.
Quick answer
WordPress Backup Security Public File Scan Runbook should be handled with a narrow evidence-first workflow: scan public paths, confirm exposure, review logs, then verify the result before making broader changes.
What to check first
- Search public web roots for ZIP, SQL, tar, wpress, installer, and config backup files.
- Use HTTP header checks to confirm whether suspicious files are reachable publicly.
- Review access logs for requests to the exposed filenames.
- Rotate database, hosting, SFTP, admin, and API credentials if sensitive files were reachable.
- Move backups to private storage and add monitoring for new public archive files.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|---|---|
| Scan public paths | Search public web roots for ZIP, SQL, tar, wpress, installer, and config backup files. | No backup, database dump, installer, or config copy is reachable publicly. |
| Confirm exposure | Use HTTP header checks to confirm whether suspicious files are reachable publicly. | Access logs were checked for downloads or probing. |
| Review logs | Review access logs for requests to the exposed filenames. | Credentials were rotated when wp-config or database data may have been exposed. |
| Rotate credentials | Rotate database, hosting, SFTP, admin, and API credentials if sensitive files were reachable. | Future backups are stored outside the web root or in private object storage. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
find public_html -maxdepth 5 -type f \( -name '*.zip' -o -name '*.sql' -o -name '*.tar.gz' -o -name '*.wpress' -o -name 'installer.php' -o -name 'wp-config*.bak' \) -print
curl -sSI https://example.com/backup.zip
grep -Ei 'zip|sql|wpress|installer|wp-config' access.log | tail -100
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Scan public paths
- Confirm exposure
- Review logs
- Rotate credentials
- Move backups private
Production verification checklist
- No backup, database dump, installer, or config copy is reachable publicly.
- Access logs were checked for downloads or probing.
- Credentials were rotated when wp-config or database data may have been exposed.
- Future backups are stored outside the web root or in private object storage.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, review exposed WordPress backup files.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.