leaky-paths: a short wordlist of paths worth asking for

What the list is and who it is written for

The repository holds one artefact, a file called leaky-paths.txt, and a README explaining the idea:

leaky-paths.txt

The list contains paths associated with major web frameworks and infrastructure projects, with known juicy APIs and known misconfigurations mixed in, and the stated purpose is web content discovery, described as the fastest way to find quick wins. The README names three audiences: a penetration tester running an assessment, a security engineer including it in external attack surface scanning, and a bug bounty hunter working through a large number of subdomains or hosts looking for high-signal responses. The distinction from a generic wordlist is the point. A general list asks whether a path exists. This one asks whether the path returns something interesting when it does.

Why the list is kept short on purpose

The README is unusually direct about the trade-off it makes. The wordlist is intentionally kept short in order to focus only on high-quality endpoints, and the author states plainly that it is not comprehensive enough for active scanning. That sentence reframes how the file should be used. A list of tens of thousands of entries is a blunt instrument that produces a large response set, and the noise has to be filtered afterwards. A short list with a good hit rate costs almost nothing to run and needs no filtering, which is why a short list can be run against thousands of hosts in a scan where a large one cannot. The repository is also positioned as a contribution project rather than a finished product, with the author opening it for pull requests from anyone who has an endpoint worth adding.

Where the list fits in a recon workflow

The repository topics place it in the standard tooling family: it sits alongside dirbuster, dirsearch, ffuf and the wider fuzzing category, and next to the reconnaissance tools subfinder and the Wayback machine, and the other tools named in its topics. The realistic sequence is that a team first maps its surface with subdomain enumeration, then runs a broad content discovery pass with one of the large general purpose lists, and then runs a much smaller pass of paths like these against the hosts that looked worth attention. The value of the short list at that point is that it can be applied everywhere, including to a large set of hosts, because each request is cheap and the response count stays small enough for a human to read.

The shift away from CVE-shaped paths

The README says the direction of the wordlist is shifting away from CVEs and towards infrastructure and web-related paths from modern technology stacks, and gives the reason: those paths often yield better returns. That is a statement about economics rather than about severity. A path tied to a named CVE is only interesting on a specific version of a specific product, it ages badly, and a scan against a mixed estate produces almost nothing from it. A path that belongs to a framework or to a platform component tends to be present wherever that framework was deployed, so the same entry pays off across many hosts, and it tends to return verbose output, which is what makes a response worth reading. The direction also means the list ages differently, following deployment trends rather than patch cycles.

What the repository does not give you

The project is thin in ways that matter for anything beyond a quick pass. There is no licence file, so the terms for reusing or redistributing the list are not stated in the repository, which is a question to settle with the author before you build it into a scanner distribution. There are no releases, so there is no versioned artefact to pin, and the list itself is a single file whose contents change whenever someone merges a contribution. The last push was on 2026-04-03, and the repository holds no CI configuration, no tests and no tooling beyond the file, so nothing verifies that a path in it still returns what it used to. A framework that renames or removes an endpoint leaves a stale entry behind, and a stale entry in a short list costs little in time but does cost credibility when it is quoted in a report.

leaky-paths next to the large general purpose lists

The README points at two larger sources for anyone who needs coverage rather than signal: the Assetnote wordlists and the Web-Content collection in SecLists. The difference in approach is size and intent. Those lists aim at completeness for a directory brute force, they are large enough that the response set needs filtering, and they will find the boring paths that a short list omits. This list aims at yield, it runs against any number of hosts cheaply, and it finds the endpoints that return configuration, server data or a hidden API. The practical pairing is to use both, in that order, because a short high-yield pass first tells you which hosts deserve the expensive pass. Using either alone is a mistake in one direction or the other, since a scanner that only tries a short list will miss the ordinary administrative pages, and one that only tries a large list will bury the interesting responses.

Editorial conclusion

leaky-paths fits a security engineer or bug bounty hunter who already has a large wordlist and needs a small set of paths with a high hit rate, and it fits as a quick-win pass before a full content discovery run. It does not fit a scan that needs coverage, since the README says the list is intentionally short and not comprehensive enough for active scanning, and the repository offers no licence, no releases and no test of its own, so it should be read as one contributor's curated snapshot rather than a maintained asset. Before using it, confirm you are authorised to probe the target, check the last commit date against the framework versions in scope, and keep the large lists from Assetnote and SecLists for the exhaustive pass.

Frequently asked questions

Official sources

1. ayoubfathi/leaky-paths on GitHub
2. Issues
3. README