How Hackers Use waybackurls to Find Vulnerabilities
The internet does not forget. That page a company quietly took down last year, the API endpoint they replaced in a redesign, the debug file someone swore they deleted: an archive recorded it, and it is still sitting there in the record. To a security researcher, that record is a map to the parts of a target nobody is looking after anymore.
waybackurls is the tool that reads that map. It’s a tiny command-line program that does one clever thing: it asks web archives, chiefly the Internet Archive’s Wayback Machine, for every URL they have ever seen on a domain and hands you the list. It doesn’t crawl the live site or guess at paths. It just shows you the site’s own forgotten history.
This guide explains why that history is so valuable, how to use the tool, and how to turn a wall of old URLs into actual findings. It fits alongside the rest of the recon toolkit: the subdomain enumeration guide maps a target’s breadth, while this one digs into its past.
Why the past is a vulnerability
To understand why archived URLs matter, you have to understand a simple truth about how websites change: things get replaced, but they rarely get properly removed.
A company redesigns its site. The old checkout flow is swapped for a new one, and the old pages are no longer linked from anywhere: the menus point to the new version, the sitemap lists the new version, a normal visitor never sees the old one. But the old code is often still sitting on the server, reachable if you know the exact URL, still running whatever logic it ran two years ago.
And here is the security kicker: old code was usually written to weaker standards. It predates a security fix that was only applied to the new version, uses a deprecated parameter that skips a validation check added later, or exposes a debug feature everyone forgot was there. The neglected page is the one nobody re-tested, patched, or is monitoring.
Live crawling and normal browsing will never find these pages, because nothing links to them. That is the whole point. But the archives remember them, and waybackurls reads the archives.
What the tool actually does
The mechanism is simple. Web archives like the Wayback Machine have spent decades crawling the internet and recording the URLs they encounter. Every time their crawler saw a page on a domain, it noted the URL. Over years, that builds into an enormous list of paths a domain has served.
waybackurls queries that data for a domain you give it and prints every URL the archive has on record. Install it (it is a Go program, like ffuf):
go install github.com/tomnomnom/waybackurls@latestThen run it:
waybackurls target.com > urls.txtThat single line asks the archives for target.com’s history and saves the result to a file. On an established target with years of history, this can return thousands of URLs, including a great many that do not exist anywhere on the current live site. You now have a historical map of the target’s attack surface that no amount of clicking around the live site would have revealed.
Notice what has not happened here: you have not touched the target’s servers at all. Every request went to the archive. This is passive reconnaissance: quiet, low-risk, and invisible to the target.
Making sense of thousands of URLs
A file with thousands of URLs is not a finding. It is raw material. The skill, exactly as with ffuf’s output, is filtering it down to the handful of URLs actually worth investigating. Here is what I look for.
Look for URLs with parameters first. Anything with a ? and a = in it is a page that takes input, and input is where a huge share of vulnerabilities live. An old URL like search.php?query= or view?id= is a candidate for injection and access-control testing. Pull these out:
grep "=" urls.txt | grep "?"Old backups and data files are pure gold, so filter for extensions that tend to leak things they should not:
grep -E "\.(bak|old|zip|sql|json|config|txt|log)" urls.txtA .sql file is a database export. A .bak is a backup of source code. A .config might hold credentials. These are the archived paths that make experienced hunters sit up.
Also check for old API endpoints and admin paths: anything with api, admin, internal, dev, test, or debug in the path. Old API versions are notorious for still being live and lacking the controls added to newer versions. An endpoint like /api/v1/users might have been superseded by v2, but if v1 still answers and skips a permission check, that is a serious finding.
Finally, watch for anything that just looks odd. After a while you develop an eye for the URL that does not fit the pattern: the one-off, the leftover, the thing that looks like it was never meant to be public. Follow those hunches.
The grep and filtering skills from the command-line tools guide are exactly what you use here to carve the signal out of the noise.
From an old URL to a real finding
Filtering gets you a shortlist. Now comes the part that turns recon into an actual vulnerability, and the part where authorisation starts to matter, because you are about to touch the live target.
The first question for any promising archived URL is simply: does it still work? Request it against the live site and see. Many will be genuinely gone, returning a 404. But some, often more than you would expect, still respond: a page the company thinks was removed years ago, quietly answering requests. That alone is worth noting.
For the ones that are still live, you test them like any other endpoint, now armed with the knowledge that this is old, likely under-maintained code:
- An old URL with a parameter goes into Burp Suite for injection and access-control testing.
- An exposed backup or data file gets downloaded and read carefully, since it may contain real data.
- An old API endpoint gets checked for whether it still enforces authentication and authorisation.
The recurring story in bug bounty write-ups is some version of this: a hunter pulls a target’s history with waybackurls, spots a forgotten endpoint, checks whether it is still live, and finds it exposing data or missing a control the current site has. The tool did not find the vulnerability. It found the forgotten page, and the forgotten page had the vulnerability. That is the whole play.
The JavaScript goldmine
If you take one advanced idea from this guide, make it this: old JavaScript files are among the richest things in the archive.
Modern web apps put a lot of logic in JavaScript that runs in the browser, and those files are full of references: API endpoints the app calls, parameter names, internal paths, occasionally even keys or tokens a developer left in by mistake. When a site is redesigned, the old JavaScript files are frequently left on the server, and each one describes an entire version of the application that no longer officially exists but may still partly work.
Pull the JavaScript files out of your archived URLs:
grep -E "\.js" urls.txtThen read them. Search each one for anything that looks like a path or an endpoint: strings starting with /api, /admin, or /internal, and parameter names being assigned values. An old script often hands you a list of endpoints to test that you would never have found any other way, because they were only ever referenced from code, never from a link a crawler could follow. This single technique sits behind a surprising number of published bug bounty findings.
Widen the net, then automate
waybackurls reads one main source, but it is not the only archive, and other tools pull from others. gau (short for “get all URLs”) queries several archive providers at once, and katana actively crawls the live site to complement the historical view. Running two or three of these and merging the results gives noticeably fuller coverage than any one alone. The sorting and de-duplicating skills from the command-line guide are exactly what you use to fold them into a single clean list:
waybackurls target.com | sort -u > all-urls.txtOnce you are doing this across several targets, you will want to package the whole flow (gather, filter for parameters and interesting extensions, de-duplicate) into a small script, so one command turns a domain into a shortlist. That is the natural payoff of the automation habit, and it is where recon stops being a chore and becomes a repeatable process.
A worked example
To make it concrete, here is the shape of how this plays out on a real, authorised target. You run waybackurls and get four thousand URLs. You filter for parameters and spot /legacy/report.php?id=1044, a path that appears nowhere in the current site’s navigation. You request it live, half expecting a 404, and it still responds. You send it to Burp Suite, change the id to a different number, and someone else’s report loads on the screen. You have just found a broken access control flaw on a page the company believed it had retired years ago.
Nothing in that chain was clever. The archive remembered a forgotten page, and the forgotten page carried a flaw the current site had long since fixed. That story repeats across real targets, which is why archived-URL recon belongs in a serious hunter’s routine.
Where it sits in a recon workflow
waybackurls is one instrument, and it plays best in a small ensemble. A sensible recon flow layers it with the others:
- Map the breadth first: find the target’s subdomains (see the enumeration guide and the Subdomain Finder tool), because you will want to run waybackurls against the interesting ones, not just the main domain.
- Pull the history with waybackurls on each promising host to surface forgotten paths.
- Brute-force the gaps with ffuf to find paths the archives never recorded. waybackurls gives you known-real old URLs; brute-forcing guesses new ones. Together they cover far more than either alone.
- Test what survives through Burp and manual analysis.
Each tool finds what the others miss. waybackurls’ unique contribution is time: it is the only one that looks into the target’s past instead of its present.
Passive to gather, authorised to test
One clear line runs through all of this. Gathering archived URLs is passive and low-risk, because you are only ever querying public archives; you never touch the target. That part you can do freely.
But the moment you take those URLs and start testing them, requesting them against the live site, probing their parameters, downloading their files, you are doing active testing, and that requires authorisation. A bug bounty programme’s scope or a signed penetration testing agreement is what makes it lawful. Finding an old endpoint in an archive is not permission to attack it; the scope is.
So the rule is the familiar one: gather freely and quietly, but only act against targets you are authorised to test. Discovering a forgotten page does not change whose it is.
The takeaway
Websites are living things that shed old skin constantly, and that discarded skin (the replaced endpoints, the deprecated parameters, the “deleted” files) piles up in the archives, still reachable, still running old and weaker code. waybackurls is how you read that pile. It is one small command that hands you a target’s forgotten history, and history is where neglected vulnerabilities survive.
Once you have the list, httpx will tell you which of those old URLs are still alive, and nuclei can sweep the survivors for known issues. The tool is one of several small, composable recon utilities from the same author that reward being chained together.
Add it to your recon alongside subdomain enumeration, ffuf and Burp Suite, keep your testing strictly inside scope, and you will find the doors everyone else walked straight past. If you want to learn this kind of recon methodology properly, with guided practice, that is exactly what our training is built around.
