A WordPress backup ZIP in the public web root can expose database records, users, configuration, salts, plugin data, uploads, API credentials, or private files. Removing the origin object does not prove closure when CloudFront or another cache may still hold a successful response under the exact URL, encoded variant, query string, or alternate hostname.
Use this immediately after finding a backup, migration archive, database dump, debug bundle, or site export in a publicly reachable WordPress path served through CloudFront.
Quick answer
Preserve the exact URL, headers, cache status, object metadata, and access-log window without downloading sensitive content unnecessarily. Remove or quarantine the origin file, create a CloudFront invalidation for every confirmed cache key, block archive extensions at the origin, rotate exposed secrets based on file contents, and verify the URL from multiple edges until it consistently returns a non-sensitive response.
What to check first
- Record filename, path, size, modified time, checksum, response code, Content-Type, ETag, Age, cache status, and alternate hostnames.
- Determine whether the archive contains wp-config.php, database exports, user data, private uploads, logs, or credentials.
- Search S3, web root, deployment artifacts, backup-plugin paths, CDN logs, and search results for related archive names.
- Remove or quarantine the origin file and invalidate exact CloudFront paths and known variants.
- Rotate credentials and notify owners according to the confirmed contents and access evidence.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Preserve minimal evidence and classify the archive contents and exposure window. | Record filename, path, size, modified time, checksum, response code, Content-Type, ETag, Age, cache status, and alternate hostnames. | Every confirmed archive URL and variant returns 404 or 403 from origin and multiple CloudFront edges. |
| Quarantine the origin file outside every public document root and storage prefix. | Determine whether the archive contains wp-config.php, database exports, user data, private uploads, logs, or credentials. | CloudFront invalidation is complete and no cached response includes the archive ETag or body. |
| Invalidate exact CloudFront paths and block public archive and dump extensions at origin. | Search S3, web root, deployment artifacts, backup-plugin paths, CDN logs, and search results for related archive names. | Origin and deployment controls prevent ZIP, SQL, TAR, GZ, and debug bundles from becoming public again. |
| Rotate secrets and handle privacy notification based on confirmed contents and access evidence. | Remove or quarantine the origin file and invalidate exact CloudFront paths and known variants. | Credential rotation, privacy assessment, owner notification, and evidence retention are documented. |
Why this usually happens
- Backup plugins and manual migrations write archives under the public document root for convenient download.
- CloudFront can serve a cached object after the origin copy has been removed until expiry or invalidation.
- Deployment scripts copy local archives into S3 or the web root with the rest of the site.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
url='https://example.com/site-backup.zip'
curl -sSI "$url"
aws cloudfront create-invalidation --distribution-id DIST_ID --paths '/site-backup.zip'
curl -sSI -H 'Cache-Control: no-cache' "$url"
# Search origin and storage for related archives before closing.
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 |
|---|
| Warm edge | Request exact archive URL from an edge that previously returned 200 | Returns 404 or 403 with no archive body after invalidation |
| Cold edge | Request from another region or cache-busting diagnosis | Origin policy blocks the archive rather than caching a new copy |
| Encoded path | Test safe encoded and case variants | No alternate cache key exposes the same object |
| Alternate host | Check apex, www, CDN, and origin hostname where authorized | No host serves the archived file |
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 minimal evidence and classify the archive contents and exposure window.
- Quarantine the origin file outside every public document root and storage prefix.
- Invalidate exact CloudFront paths and block public archive and dump extensions at origin.
- Rotate secrets and handle privacy notification based on confirmed contents and access evidence.
- Scan related paths, alternate hosts, deployment artifacts, and search results before closure.
Decision rule
Treat the incident as a confirmed data exposure when the archive was publicly retrievable and contains sensitive records or reusable secrets. If access logs are incomplete, state uncertainty explicitly and rotate credentials according to the plausible contents and exposure window.
Production verification checklist
- Every confirmed archive URL and variant returns 404 or 403 from origin and multiple CloudFront edges.
- CloudFront invalidation is complete and no cached response includes the archive ETag or body.
- Origin and deployment controls prevent ZIP, SQL, TAR, GZ, and debug bundles from becoming public again.
- Credential rotation, privacy assessment, owner notification, and evidence retention are documented.
Field notes
- Avoid opening or extracting the archive on an unmanaged workstation. Use an isolated evidence location with restricted access.
- Record cache headers before invalidation because they can distinguish edge exposure from an origin-only file.
- Temporary Search Console removal is not a substitute for deleting the file and fixing access at origin.
Questions teams ask during testing
Why does the ZIP still download after deletion?
A CDN edge can retain and serve the prior 200 response until it expires or the exact object path is invalidated.
Should every password be rotated?
Rotate credentials present in the archive and any secrets that could be derived or reused. Scope the action from contents and access evidence.
Can Search Console remove the result?
The removals tool is temporary. The origin and cache must stop serving the file first.
Mistakes to avoid
- Do not assume deleting the origin file clears CloudFront immediately.
- Do not circulate the archive to prove what it contains.
- Do not invalidate only the homepage or a directory path that does not match the object key.
- Do not rely on robots.txt or Search Console removal to protect a downloadable file.
What to tell the client or owner
Report the masked path, object size and checksum, first and last known 200, cache headers, contents classification, invalidation ID and status, origin removal, secret rotations, and residual uncertainty.
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, contain a WordPress backup exposure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references