The trickest/cve repository aggregates almost every publicly available CVE proof-of-concept, generated automatically for defenders and authorized testers tracking exploit availability.

trickest/cve is one of those repositories that quietly became infrastructure for the entire vulnerability-management world. Its pitch is blunt: almost every publicly available CVE proof-of-concept, collected, deduplicated, and rendered into readable markdown files organized by year and CVE identifier. At the time of writing it sits at roughly 8074 stars, is written primarily in HTML (the generated output format), and is released under the MIT license, which matters here because it means the entire dataset can be forked, mirrored, and integrated into internal tooling without licensing friction. The repo is maintained by the Trickest team, and it doubles as a demonstration of their workflow-automation platform, but the data itself stands on its own as a public resource.

What makes the repository interesting from an engineering perspective is not the dataset but the pipeline that produces it. The README documents the full workflow architecture. It starts by collecting CVE details from CVEProject/cvelist, the official CVE Program repository of CVE records, which gives it a canonical, continuously updated source of identifiers, descriptions, affected versions, and references. From there the workflow splits CVEs by year — hence the 2022/CVE-2022-1388.md style paths — and begins the actual PoC discovery phase using two independent techniques.

The first technique is reference mining. For each CVE, the pipeline gathers its References from the CVE record and checks whether any of them point to a proof-of-concept. The clever part is that this is done with ffuf, a tool most operators associate with content discovery and fuzzing, here repurposed as a batch URL-checking engine running against a keyword-matching regex: (?i)[^a-z0-9]+(poc|proof of concept|proof[-_]of[-_]concept)[^a-z0-9]+. The README credits joohoi for the regex and explicitly notes that ffuf is useful for far more than directory brute-forcing — a nice piece of tradecraft worth remembering for anyone building similar automation. The pipeline also pulls HackerOne-disclosed report references from zeroc00I/AllVideoPocsFromHackerOne.

The second technique is GitHub search, executed with trickest/find-gh-poc, a companion tool that searches GitHub for repositories mentioning a given CVE ID. This catches the large class of PoCs that never make it into the official CVE references — the drop-a-exploit.py-in-a-repo pattern that dominates how offensive tooling actually gets published. Running both techniques in parallel means the dataset captures both formally referenced PoCs and the long tail of independently published ones, which is precisely the gap most commercial vulnerability feeds handle poorly.

After collection, the pipeline merges fresh results without overwriting manually committed data — an important design decision, since it means human corrections persist across automated runs. False positives are filtered with a blacklist.txt file, which the README identifies as the mechanism for keeping noise out of the merged PoC list. The final steps are cosmetic but practical: shields.io badges are generated for each affected software version, and everything is written into the markdown files that populate the repository. The maintainers note that almost everything in the repository is generated automatically, and that they continue to refine the workflow for accuracy — a fair caveat, since automated PoC classification will never be perfect.

For an authorized operator, the use cases the README lists map cleanly onto real workflow. The most obvious one is searching for a specific product and version to enumerate all public exploits affecting it — the kind of task that precedes any credible vulnerability assessment or patch-prioritization exercise. Less obviously, the README suggests Watching the repository to receive GitHub notifications as new PoCs go public, effectively turning it into a free exploit-availability feed. It also points at the commit atom feed for monitoring a specific product over time, which is a lightweight way to detect when something in your estate suddenly gains a public exploit.

There is also a self-hosted search angle: the summary_html directory contains a template and script for building a searchable HTML table from the data, with a public example credited to AndrewMohawk. That makes the repository more than a browsing destination — it is a dataset you can load into your own tooling, index, and query alongside internal asset inventories. Combined with the MIT license, this is arguably the strongest defensive application: joining CVE-has-public-PoC data against your own asset list is one of the highest-signal prioritization inputs available, because exploit availability is a far better predictor of real-world risk than CVSS severity alone.

The README's front page also maintains a "current hottest CVEs" table, with a full history available in hot_cves.csv. Treat this as a trend indicator rather than an operational target list: it reflects which CVEs are attracting the most attention in a given window, which is useful context for threat briefing and for understanding attacker-side interest. The defanged example entries in the README, such as CVE-2022-1388 (an F5 BIG-IP iControl REST issue from a heavily exploited era), illustrate the grade of vulnerability the collection covers — the ones with real, weaponizable public tooling that defenders cannot afford to ignore.

A few caveats worth stating plainly. First, this is an index of links to PoCs, not a vetted exploit library — the blacklist filters obvious junk, but following any linked PoC means handling untrusted code from third parties, and anything you pull from it should be treated as hostile until proven otherwise and run only in isolated lab environments you own. Second, the repository doubles as marketing for the Trickest platform, with sign-up banners throughout the README; that is a fair trade for a free, continuously updated dataset, but be aware the upstream pipeline is proprietary even though the output is open. Third, because the data is auto-generated, coverage will lag or drift on edge cases, so verify against the official CVEProject/cvelist record before acting on anything consequential.

Where this fits in the broader tooling landscape is worth a paragraph of its own. Feeds like CISA's KEV catalog tell you what is being exploited; exploit databases like this one tell you what is exploitable with public tooling. Those are different questions, and mature vulnerability-management programs answer both. trickest/cve occupies the second niche with unusual breadth and a fully transparent methodology, which is more than can be said for most aggregators. For authorized penetration testers, it is a pre-engagement reconnaissance shortcut for checking exploit availability against scope. For defenders, it is a patch-prioritization signal. For researchers, it is a corpus for studying how PoCs propagate after disclosure. Few repositories serve all three audiences this well, and the automated, merge-safe pipeline behind it is a genuinely instructive piece of engineering even if you never run a single exploit from it.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• dj for mapping dynamically loaded JavaScript during authorized web reconnaissance


• reconFTW for automating attack-surface reconnaissance on authorized targets


• Flowsint for visual OSINT graph investigations