A WordPress backup ZIP in the web root can expose wp-config.php, database dumps, salts, API keys, SMTP credentials, private uploads, logs, and user data. Deleting the file prevents future downloads but does not invalidate anything already copied. CDN caches, origin aliases, object storage, alternate extensions, partial archives, and access logs can extend the exposure or hide whether a request reached the file.
Use this after finding backup.zip, site-old.tar.gz, a migration package, database dump, or another downloadable archive under a public WordPress path.
Quick answer
Preserve the filename, hashes, size, timestamps, response headers, CDN status, origin path, and relevant access logs before cleanup. Remove public access at the origin and edge, invalidate every known URL variant, and search for related archives. Inventory the secrets and personal data inside an offline protected copy. Rotate database users, WordPress salts, application passwords, SMTP, payment, analytics, cloud, deployment, SSH, SFTP, CDN, backup, and plugin API credentials according to exposure, then invalidate sessions and review privileged accounts and changes.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Database | User and password in wp-config | New credential works, old fails |
| WordPress salts | Session cookies exposed | All prior sessions invalid |
| Third-party API | SMTP or payment key | Old revoked, integration healthy |
| CDN copy | Cached archive URL | Miss or deny at every variant |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Preserve scope evidence | Record archive name, URL variants, hash, size, create and modify times, owner, permissions, response status, cache headers, ETag, and CDN age. | Every archive URL variant is denied or absent at origin and CDN. |
| Block origin and edge access | Export origin, CDN, WAF, load balancer, hosting, object storage, and security logs for the complete possible exposure window. | All exposed credentials have a new value and the old value is rejected. |
| Inventory archive contents | List configuration files, database dumps, logs, uploads, private documents, keys, tokens, passwords, salts, user records, orders, and form entries inside the archive. | Sessions, privileged users, files, jobs, and integrations have been reviewed. |
| Rotate and revoke by owner | Rotate each credential at its owning system, update approved consumers, revoke the old value, invalidate sessions, and test both rejection and new access. | The exposure window, notification decision, evidence, owner, and monitoring period are documented. |
What to check first
- Record archive name, URL variants, hash, size, create and modify times, owner, permissions, response status, cache headers, ETag, and CDN age.
- Export origin, CDN, WAF, load balancer, hosting, object storage, and security logs for the complete possible exposure window.
- List configuration files, database dumps, logs, uploads, private documents, keys, tokens, passwords, salts, user records, orders, and form entries inside the archive.
- Rotate each credential at its owning system, update approved consumers, revoke the old value, invalidate sessions, and test both rejection and new access.
- Search the web root, parent paths, object storage, snapshots, deployment artifacts, caches, search results, and monitoring for additional copies or URLs.
Field notes
- Write the expected result before changing anything and keep one repeatable synthetic fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public path and the stored server-side result, not only an admin preview, isolated command, or API response.
- Review the result again after the relevant cache, queue, cron, webhook, and observation window has completed.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
find . -maxdepth 3 -type f \( -iname '*.zip' -o -iname '*.tar.gz' -o -iname '*.sql' -o -iname '*.bak' \) -print
sha256sum suspicious-backup.zip
# Preserve evidence first. Inspect only in an isolated protected location.
# Rotate at the owning service, then prove the old credential fails.
Why this usually happens
- A migration or backup plugin writes an archive into a downloadable directory.
- The origin file is deleted while CloudFront or another CDN still serves a cached object.
- Teams rotate only the database password and miss SMTP, cloud, payment, or application secrets.
- Logs are overwritten before the possible exposure window and downloader IPs are reviewed.
Decision rule
Treat every live credential and personal-data class inside a publicly reachable archive as exposed unless reliable evidence narrows the scope. Deletion alone does not close the incident.
Production verification checklist
- Every archive URL variant is denied or absent at origin and CDN.
- All exposed credentials have a new value and the old value is rejected.
- Sessions, privileged users, files, jobs, and integrations have been reviewed.
- The exposure window, notification decision, evidence, owner, and monitoring period are documented.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Preserve scope evidence
- Block origin and edge access
- Inventory archive contents
- Rotate and revoke by owner
- Hunt for copies and monitor
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, a stable fixture, the expected result, and a tested rollback point.
- Treating one successful screen as proof while logs, stored records, background jobs, caches, emails, APIs, and downstream systems remain unchecked.
- Testing only as an administrator instead of using the role, device, locale, cache state, request path, and failure branch that users actually reach.
- Leaving debug output, temporary exclusions, helper accounts, duplicate hooks, broad permissions, or relaxed firewall rules active after verification.
Questions teams ask during testing
Can I test this directly in production?
Start with read-only evidence. Use staging for code, package, security, checkout, form, privacy, or cache changes. If a production canary is necessary, make it identifiable, reversible, monitored, and incapable of exposing personal data or charging a customer.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare the public result, stored result, and logs instead of relying on one browser view.
What evidence should I retain?
Keep UTC time, exact versions, request or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials, tokens, and personal data.
When is the work complete?
Close it when the primary path passes, failure branches are understood, stored and downstream records reconcile, temporary changes are removed, monitoring is active, and the owner has the evidence packet.
What to tell the client or owner
Give the owner a concise packet with the affected workflow, exact versions, UTC test time, synthetic fixture ID, expected result, actual result, key logs, change made, rollback point, final result, unresolved risks, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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, have HandL WP contain and investigate an exposed backup.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references