# GhostTroops/TOP: a yearly, machine regenerated index of public CVE research

> GhostTroops/TOP is not a scanner and not a toolkit. It is a set of Markdown tables that list public CVE proof of concept repositories, thirty entries per year, each with a star count, a timestamp, a URL and a one line description. The interesting engineering is in how the list is regenerated rather than in anything the list contains.

**GhostTroops/TOP** — TOP All bugbounty pentesting CVE-2023- POC Exp  RCE example payload  Things

- Repository: https://github.com/GhostTroops/TOP
- Website: https://exploit-poc.com
- Stars: 731 · Forks: 126
- Language: Shell
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/ghosttroops-top

## What the repository actually contains: tables, not code

GhostTroops/TOP is described as an index of bug bounty and pentesting write-ups, with the repository description tagline covering CVE-2023 and the README heading covering CVE-2022, stating that it lists all bug bounty pentesting CVE proof of concept and exploit related items.

Look at the top level listing and the shape becomes clear. There is a README.md, two top level list files, Top.md and Top_Codeql.md, a cve_poc directory, a.run.sh script, a.gitmodules file, and three files with short names, ed.md, he.md and hecdql.md. The primary language is recorded as Shell, which fits a repository whose own code is a generation script rather than an application.

So this is a data product with a generator. The lists are the output, and the script plus the submodules are the machinery that produces them. That is a different thing from a collection of exploits, and a different thing again from a scanner or a toolkit, because the repository executes nothing against a target.

The homepage for the project is exploit-poc.com, and the README links to it as all Top and to a separate CodeQL list as Top Top_Codeql. The CodeQL companion is the more interesting of the two from a tooling perspective, because CodeQL is a static analysis engine and a list organised around it points at a different research methodology than a list of exploit repositories.

The audience is a reader doing reconnaissance on the CVE ecosystem itself: which vulnerabilities had public proof of concept code published this year, where that code lives, and how much attention it attracted.

## Thirty entries per year, and a schema you can read like a CSV

The table of contents in the README is organised by year, from 2026 back to 2020, and each year claims a total of 30 entries. The repository description mentions CVE-2023 specifically, and the yearly sections cover 2026, 2025, 2024, 2023, 2022, 2021 and 2020.

The table schema is the interesting part, because it is fixed and minimal. The header row reads star, updated_at, name, url, des, and every row follows it.

```
|star|updated_at|name|url|des|
|---|---|---|---|---|
```

So each entry carries a star count, a timestamp of when the entry was last updated, the repository name, the URL, and a description. That is the whole contract, and it has two consequences.

The first is that the list is sortable and filterable in a way a prose list is not. Since every row has the same shape and the same field names, a script can parse it, sort by stars to find what the ecosystem is looking at, or sort by updated_at to find what moved most recently. The star count in particular is a rough measure of how much attention a proof of concept has drawn, and the timestamp is a rough measure of when it was last touched, which is not the same as when the vulnerability was disclosed.

The second consequence is that the list is a search index, not a curated set. There is no field for a severity rating, a vendor advisory reference, a proof of concept quality score, or a licence. A reader has to click through to the linked repository to get any of that, and the README does not claim otherwise.

The entries themselves show the range. For 2026 there is a Linux kernel local privilege escalation nine years old, a WordPress unauthenticated remote code execution chain with two separate CVEs, a one-tap execution application for a kernel vulnerability, a Next.js collection covering a dozen CVEs, a research set on vulnerable driver discovery and reverse engineering, a cPanel and WHM authentication bypass, a Windows kernel arbitrary write that escapes a browser sandbox, an Android exploit chain combining two CVEs, and several jailbreak and rooting installers for specific device families.

The 2025 section shows the same pattern with a React server components and Next.js remote code execution, a Windows archive extraction code execution from a 2018 advisory, and an NTLM reflection flaw.

## A generation script and submodules explain how the list stays current

The repository root contains a .run.sh script, a .gitmodules file and a cve_poc directory, and those three together explain the maintenance model without needing to guess at it.

A .gitmodules file means the repository pulls in other repositories as submodules. A cve_poc directory alongside it means the proof of concept repositories themselves are mounted into the tree. So the data the tables describe lives in other people's repositories, and this one references them.

The .run.sh script is the generation step. Combined with the primary language being Shell, the reasonable reading is that the script walks the submodules, reads their metadata, and rewrites the Markdown tables. The .github directory at the root is where the scheduled or push triggered workflow that runs it would live.

This design has a clear upside. The list does not copy code, so it does not have to track content changes, and updating the index means re-running a script rather than editing thirty rows by hand. The timestamps in the updated_at column are then a by-product of the regeneration rather than something anyone typed.

It also has a clear limitation, and it is the same limitation as any federated index. The index is only as good as the sources it pulls from, and the sources are third party repositories that appear and disappear. A row pointing at a repository that has been taken down is a broken link that only surfaces when someone clicks it, because there is no liveness field in the schema.

The three short-named files, ed.md, he.md and hecdql.md, look like additional generated outputs or per-category lists alongside the two main ones. The naming is not expanded anywhere in the visible documentation, so treat them as separate list files rather than guessing at their scope.

What the project is not is a scanner. Nothing here probes a host, and nothing here produces a working exploit. It is a map to where the public work is, and the distance between that map and an exploit is exactly the distance between a link and a repository you have read, understood and are authorised to run.

## Where TOP is the wrong tool

The first wrong-tool case is anyone looking for a ready to use exploit. The repository does not ship payloads, and it does not run them. The linked repositories do, and each of them carries its own judgement about what it is for, its own stability, and in some cases its own prerequisites such as a specific device, a specific kernel build, or a specific vendor advisory. Treating an entry here as a working exploit is a category error that ends badly.

The second case is anyone who needs a filtered, verified corpus. There is no severity field, no advisory field, no state field such as disputed or rejected, and no licence field. A researcher who needs to know which of a year's public proofs of concept are for vulnerabilities that were later disputed, or that were for issues the vendor never confirmed, has to check each one individually.

The third case is a compliance or legal review. The repository carries no classified licence, and the licence field is reported as unknown. The list links to code written by other people under their own terms, and the relationship between an index and the work it points at is exactly the kind of question a legal team will ask. The fact that the index does not copy the code does not settle it.

The fourth case is a production detection use case. A table sorted by stars is a popularity signal, not a coverage guarantee. It will miss proofs of concept published in a repository the script does not traverse, and it will not tell you whether the vulnerability in a given row was ever exploitable in the wild or only ever demonstrated in a lab.

There is one more practical point about the data shape. Thirty entries per year is a curation decision, and a curated top list of thirty is by construction not exhaustive. A year with several hundred public proofs of concept has thirty slots, which means the selection criteria matter a great deal to how you read the list, and the criteria are not stated in the visible documentation.

The last push to the repository was on 2026-10-20, so the list is current rather than abandoned, and that is the most favourable thing you can say about its reliability: someone is regenerating it.

## Conclusion

GhostTroops/TOP suits a security researcher who wants a fast, dated map of where public proof of concept code is appearing for a given year, and who is willing to treat the table as a pointer rather than a verdict. It does not suit anyone who wants a scanner, a payload set, or a curated and verified corpus, because nothing in it is verified on your behalf, and it does not suit a reader who needs a licence position on the linked code, since the repository itself carries no classified licence and the code it points at is written by other people. Before relying on it, read the column definitions in the table header rather than the star counts, and evaluate each linked repository on its own terms, since an entry being listed says only that it was indexed.

## FAQ

### What is GhostTroops/TOP?

It is a repository of yearly Markdown tables indexing public CVE proof of concept and exploit repositories, with a table of contents covering 2020 through 2026 and thirty entries listed per year. The project also has a companion CodeQL list and a homepage at exploit-poc.com.

### What do the columns in the GhostTroops/TOP tables mean?

The header row is star, updated_at, name, url, des, so every entry carries a star count, a last updated timestamp, the repository name, its URL and a one line description. There is no severity, advisory or licence field in the schema.

### Does GhostTroops/TOP contain exploits or a scanner?

No. The repository holds Markdown tables, a shell script for generating them, a cve_poc directory mounted through git submodules, and list files. It executes nothing against a target; the exploit code lives in the third party repositories it points at.

### How is the GhostTroops/TOP list kept up to date?

The repository root contains a .run.sh script and a .gitmodules file, and the primary language is recorded as Shell, so the tables are regenerated from the submodules rather than edited by hand. The updated_at column in each row is a by-product of that regeneration.

### What license is GhostTroops/TOP released under?

The project licence is reported as unknown and GitHub cannot classify it. The linked proof of concept repositories are licensed by their own authors, which is a separate question from the licence on this index.

## Sources

- [GhostTroops/TOP on GitHub](https://github.com/GhostTroops/TOP)
- [Issues](https://github.com/GhostTroops/TOP/issues)
- [Project website](https://exploit-poc.com)
- [README](https://github.com/GhostTroops/TOP/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ghosttroops-top