>_ BREACHHUNTER

Research · ← All guides

Deleted ≠ Gone: What the Wayback Machine Keeps After You Delete Your Secrets

Published: October 12, 2026 · Last updated: October 13, 2026 · 9 min read

By the Ingenious AI team

Methodology note: this post documents exactly how BreachHunter's Ghost Files check works and what it looks for. The mechanisms are described precisely; outcomes vary per site. We do not touch archived file contents, only snapshot metadata.

You found a .env sitting in your web root. You deleted it within the hour, rotated the database password, and breathed out. You're safe — right?

Maybe not. If the Internet Archive's Wayback Machine crawled that URL while the file was live, it keeps its own copy. Deleting the file from your server does not delete the archived snapshot. Anyone on the internet can still open it and read every API key, database credential, and signing secret the file ever contained. We call these ghost files: dead on your server, alive in the archive.

The mechanism: why deletion isn't enough

The Wayback Machine is an independent copy. It crawls the public web on its own schedule and stores what it finds. Your server and the archive are two separate systems with two separate delete buttons:

This is the part most site owners miss. Incident response checklists say "remove the exposed file and rotate the secrets." Rotating the secrets is the step that actually saves you, because the archived copy of the old secrets stays public regardless.

A hypothetical timeline: how a ghost file is born

To make the mechanics vivid, here's a clearly hypothetical scenario: none of this happened to a real customer; it's the composite of how these exposures typically unfold:

Tuesday, 9:14 AM. A contractor debugging a production issue drops a .env into the web root so the app can read its config, planning to remove it after lunch. Tuesday, 11:02 AM. The Wayback Machine's crawler, on its ordinary rounds, fetches /.env, gets HTTP 200, and stores the full file — database URL, mail API key, session secret — with a timestamp. Tuesday, 2:40 PM. The contractor deletes the file. The live site is clean. Eight months later, someone queries the archive for that URL and downloads the whole thing. The file was public for five hours. The snapshot is public forever, until someone asks the Archive to remove it.

The uncomfortable truth in that timeline: the exposure window that mattered wasn't the five hours the file was live. It was the eight months nobody knew a snapshot existed. That's why this check runs on every scan. People can't fix what they can't see, and nobody remembers to check the archive by hand.

What we check: the 8 ghost-file paths

BreachHunter's Ghost Files check runs on every scan, on every tier, because this is the finding people most want to know about. For each of these 8 paths, we query the Wayback Machine's CDX API:

How the check works (metadata only — we never touch your secrets)

A deliberate design decision: the scanner queries snapshot metadata only: timestamps and status codes from the CDX API — never the archived file body. Even if the archive holds a live copy of your leaked credentials, our scan never downloads or stores them. You can run the same query yourself; it's a plain HTTP request:

https://web.archive.org/cdx/search/cdx
  ?url=yourdomain.com/.env
  &output=json
  &filter=statuscode:200
  &collapse=digest

That returns one line per archived snapshot (timestamp, original URL, status code, digest) and nothing else. No file contents cross the wire. For each path we record whether any HTTP-200 snapshot exists at all, the first and most recent snapshot dates, and how many snapshots exist.

If snapshots exist, the finding is rated HIGH and the report links straight to the archived copy so you can see exactly what's exposed, plus the fix steps, in order:

  1. Remove the file from your server if it's still there. Stops future snapshots.
  2. Rotate every secret that was ever in it — assume compromise, because the archived copy is public and you don't know who downloaded it.
  3. Ask the Internet Archive to exclude the URL. Email info@archive.org with the exact URLs, the time period to exclude, and the period during which you controlled the site — that's the Archive's documented process (their help center lists exactly these three items). It's a review, not a guaranteed takedown, and it takes time; that's why step 2 comes first.
  4. Block the path going forward — in robots.txt and at the server level — so it's never archived again. Note the nuance: robots.txt only affects future crawling. It does not delete snapshots the Archive already holds. Anyone telling you otherwise is selling something.

Rotation is the real fix (and it's bigger than you think)

Step 2 deserves emphasis because it's where most cleanups quietly fail. "Rotate the secrets" doesn't mean changing one database password. It means inventorying everywhere the exposed secret ever lived or was copied:

Assume compromise isn't paranoia; it's arithmetic. You cannot prove nobody downloaded the snapshot, so you proceed as if somebody did. The archived copy staying public is then harmless. It's a museum exhibit of credentials that no longer work.

What this looks like in practice

A typical ghost-file finding reads like this: "The Wayback Machine holds 4 archived snapshot(s) of /.env that returned HTTP 200 (first 2022-03-14, most recent 2024-11-02). Even if you deleted this file from your server, anyone on the internet can still download the archived copy, including every secret it ever contained."

Note the date range: a file deleted in 2023 can still be downloadable from a 2021 snapshot. The archive doesn't care when you cleaned up — it cares when it crawled. This is also why rotating secrets matters more than deleting files: deletion stops future crawling, rotation neutralizes what's already archived.

Prevention: stop secrets reaching the web root at all

The best ghost file is one that was never archived. Three habits, in increasing order of effort:

Try it on your own site

No scanner looks at the past except this one. Every other check in every other tool tests the live server. Ghost Files is BreachHunter's answer to the question "what did I leave behind?" It ships on the Free plan: scan your site and look for the 👻 findings.

Run the Ghost Files check on your site — free →

Frequently asked questions

Can people still download files I deleted from my website?

Possibly. If the Wayback Machine crawled the file while it was live, it keeps its own copy. Deleting the file from your server doesn't delete the archived copy. Anyone can replay the archived snapshot, including every secret the file ever contained.

How do I check whether my deleted files are archived?

Query the Wayback Machine's CDX API for the exact URL: it returns metadata for every archived snapshot. BreachHunter's Ghost Files check automates this for 8 dangerous paths on every scan, using metadata only, so it never downloads archived secrets.

How do I remove a secret from the Wayback Machine?

First, rotate every secret the file contained — assume compromise. Then email info@archive.org with the exact URLs, the time period to exclude, and the period you controlled the site; the Archive reviews exclusion requests for sensitive material. Note this is a review, not a guaranteed takedown, and it doesn't undo the exposure. Rotation is what neutralizes it.

Does blocking the archive in robots.txt delete old snapshots?

No. A robots.txt rule only affects future crawling. It doesn't remove snapshots the Archive already holds. To remove existing snapshots you must request exclusion via info@archive.org. And rotate the exposed secrets first: removal is a review process that takes time, while the archived copy stays public until it completes.

Which files should I check in the archive?

Start with /.env, /.git/HEAD and /.git/config, /backup.zip, /.aws/credentials, /id_rsa, /wp-config.php.bak and /config.php.bak: the paths most likely to hold credentials, keys, or database dumps.

Share this: X · Facebook · LinkedIn · WhatsApp

Related guides