Backup File Exposure in Bug Bounty: Finding .bak, .old, and Zips

Developers make copies. Editors leave swaps. Deploy scripts dump zips next to the live app. When those files sit under the web root, you get source, configs, or database exports without authenticating.

The hunt is patterned guessing plus content-type checks—not blind faith that every 200 is a jackpot.

Patterns that still pay

For each interesting path (/index.php, /config.yml, /appsettings.json, /wp-config.php), try siblings:

filename.bak, .old, .orig, .copy, .tmp
filename~, .swp, .swo, .save
filename.zip, .tar.gz, .7z of a directory name
Dated copies: config-20240115.php, db.sql

Also try directory-level archives: /backup.zip, /www.zip, /html.tar.gz, /site-backup/.

Tools help, but verify manually. A WAF may serve a generic 200 page. Check Content-Type, length, and a snipping of the body for PHP tags, JSON keys, or SQL INSERT lines.

Prove disclosure, do not hoard PII

Download only enough to show the issue. If the zip is huge, list contents and quote a non-sensitive config key or a redacted connection string shape. Strip secrets from the public report body; share full files out of band if the program asks.

Severity scales with content:

Application source with hard-coded secrets → high/critical after validating the secret is live
Config without secrets → medium
Empty or duplicate of public static files → often informative

Never use a discovered database dump against production users. Your canary account and a single redacted row are enough when schema disclosure matters.

Where people forget to look

Secondary hosts: staging, VPN help sites, old marketing CMS. Extension swaps on APIs (/openapi.json.bak). Object storage buckets that mirror the site. CI artifact links that were briefly public and still indexed.

I've seen .DS_Store and Thumbs.db treated as joke findings; sometimes they only confirm a directory listing problem. Lead with the listing or the real backup, mention the junk files as supporting noise if at all.

Editor swap files (.swp) sometimes contain partial buffers with secrets that never reached the final saved config. Worth checking when the main .bak is a dud.

Language-specific leftovers show up too: index.php.dist, config.php.example that somehow gained real credentials, and web.config.bak on IIS hosts. Match suffixes to the stack you already fingerprint from response headers.

Clean report shape

Give the exact URL, HTTP status, content type, and a short excerpt proving source or data. Explain how a stranger would find it (common suffix on a public path). Recommend removing backup artifacts from web-served directories, blocking archive extensions at the edge, and keeping backups off the content root entirely.

One confirmed wp-config.php.bak with DB credentials beats a spreadsheet of 500 guessed suffixes that all returned the homepage HTML.