trickest/cve: a generated GitHub CVE list with proof-of-concept links

What trickest/cve actually is, and who it is for

The repository is a directory tree of markdown files, one per CVE, grouped by year. The top-level entries run from 1999/ through 2026/, alongside blacklist.txt, hot_cves.csv, references.txt, config-template.yaml, summary_html/ and the workflow diagram. Each file is meant to be read by a person deciding whether a proof of concept exists for a given CVE and where it lives.

The intended readers are named in the README's use cases: people doing penetration testing and red team work who want to "browse around, find a nice PoC, and test away", and anyone who needs to search a product or version for public exploits. It is also a monitoring feed. The README suggests watching the repository for notifications when new PoCs go public, or monitoring the commits atom feed to track a specific product.

That framing matters. The project does not claim to assess severity, exploitability, or whether a PoC works. It claims to find almost every publicly available CVE proof of concept and to keep that list current. The gap between a link that mentions a CVE ID and code that exploits the CVE is where most of the practical judgement sits, and the README does not close it.

How the workflow builds each CVE file

The README gives a compressed architecture. CVE details are collected from the CVE Project's cvelist repository, then split by year. From there, two techniques run in parallel to find proof-of-concept material.

The first is reference inspection. The workflow gathers each CVE's References field and checks whether any reference points to a PoC, using ffuf with a keyword list. The README documents this regex:

(?i)[^a-z0-9]+(poc|proof of concept|proof[-_]of[-_]concept)[^a-z0-9]+

That pattern is deliberately loose. It matches "poc" or "proof of concept" surrounded by non-alphanumeric characters, case-insensitively. A reference URL or description containing those tokens is treated as a candidate. The README credits the regex to @joohoi and notes that ffuf is useful beyond content discovery. The same section mentions that CVEs referenced in HackerOne reports are picked up through AllVideoPocsFromHackerOne.

The second technique is GitHub search. The workflow uses trickest/find-gh-poc to search GitHub for repositories that mention the CVE ID.

After that, results are merged into the repository without overwriting data committed by hand, false positives are filtered through blacklist.txt, all found PoCs are merged, badges for affected software versions are generated with shields.io, and everything is written into markdown files. The README's own summary is blunt: "almost everything in this repository is generated automatically." The manual-merge step is the one place where a human contribution survives an automated run, which tells you the maintainers expect the generator to be imperfect.

Cloning trickest/cve and reading a single CVE file

There is no package to install and the README documents no build step. The primary language listed for the repository is HTML, which reflects the optional summary page rather than the data itself. The data is plain markdown, so the first real use is a clone and a read.

The README's hottest-CVE table points at paths such as /trickest/cve/blob/main/2022/CVE-2022-1388.md, so that is the file to open first if you want to see the shape of a generated entry. It contains identifying details plus links to the PoCs the workflow found, not an exploit write-up.

Browsing the repository in GitHub's web interface is enough for that. Cloning gives you the whole tree locally, including the year directories, LICENSE, README.md, blacklist.txt, config-template.yaml, github.txt, hot_cves.csv, references.txt and summary_html/:

git clone https://github.com/trickest/cve.git

For monitoring rather than browsing, the README points at the commits atom feed at https://github.com/trickest/cve/commits/main.atom, which is what you would poll to detect newly added PoC links for a product you care about. For a browsable view, the README describes a template and script in summary_html/ that produce a searchable HTML table, with a live example linked from the README.

Where the generated index misleads you

Regex-based reference matching is the weakest link. A CVE reference whose text happens to contain "proof of concept" gets flagged, even if the link is a vendor advisory, a blog post explaining the bug, or a dead page. The blacklist exists precisely because the workflow produces false positives, and a blacklist is a manual, reactive control: it removes what someone already noticed, not what nobody has looked at yet.

GitHub search has the mirror-image problem. trickest/find-gh-poc looks for repositories mentioning a CVE ID, and a repository can mention an ID in a README, a changelog, a scanner signature list, or a collection of unrelated notes. The link is real; the proof of concept may not be.

There is also no versioning of trust. A CVE file does not record when a link was checked, whether it still resolves, or whether the PoC targets the vulnerable version you run. The README says the workflow is designed and continuously developed "to ensure the results are as accurate as possible", which is a statement about effort, not a guarantee about any individual file.

Finally, the repository is the wrong tool for anyone who needs to know whether they are affected. It contains no scanner, no version detection, and no patch data. It answers one narrow question: does a public PoC link appear to exist for this CVE, and where.

trickest/cve against the NVD and Exploit-DB

The closest alternative in kind is the National Vulnerability Database, which is the authoritative CVE record source with structured fields, CVSS scoring and vendor references. trickest/cve consumes CVE data rather than producing it, and its value-add is the PoC discovery pass plus the per-CVE markdown layout. If you need scoring, CPE matching, or a stable API, the NVD is the right source and this repository is a convenience layer on top of the same identifiers.

Exploit-DB takes the opposite approach to the same goal. It is curated: entries are reviewed and carry an exploit ID, and the collection is smaller and more deliberate. trickest/cve is generated and wider, which is exactly why it needs a blacklist. The trade is recall against precision. If you want a small set of vetted exploits, Exploit-DB's model fits better. If you want to know whether any public PoC link exists for an obscure CVE, the automated sweep is more likely to have something.

A third comparison is running the pieces yourself. The README names the components: cvelist for data, ffuf for reference matching, find-gh-poc for GitHub search, shields.io for badges. Anyone can assemble that pipeline, and the README even invites it by pointing to Trickest for custom workflows. Using the repository is choosing to consume someone else's run of that pipeline instead of operating your own.

Maintenance, licence and the cost of keeping it current

The repository is not archived and the last push was on 2026-09-21, so it is being updated. That matters more here than for a typical library, because the entire product is freshness. A stale CVE index is just a worse copy of the NVD.

The upgrade cost is near zero for consumers. There is no version to pin and no API to migrate against; you pull the branch or open a file. The cost sits on the other side, in the workflow: ffuf keyword matching, find-gh-poc searches, blacklist maintenance and the merge that preserves manual commits all have to keep running for the files to stay useful. The README asks for contributions through GitHub issues, which suggests the blacklist and manual entries are community-maintained edges around an automated core.

The licence is MIT. In practical terms that permits reuse and redistribution with the licence text preserved, but it says nothing about the licensing of the linked proof-of-concept code, which lives in other repositories under their own terms. Treating an MIT licence on the index as a licence to the exploits it points at would be a mistake, and the repository does not make that claim. For legal questions about using a specific PoC, the source repository of that PoC is the place to look.

Editorial conclusion

Adopt trickest/cve if you want a browsable, per-year index of public CVE proof-of-concept links and you accept that the content is generated by a workflow and filtered by a blacklist rather than curated by hand. Do not adopt it as a vulnerability scanner, a patch-management source, or an authoritative record of exploitability; the README describes link discovery, not verification. Before relying on it, open a CVE file for a product you know, check whether the linked PoC is the real thing, and read blacklist.txt to see what the workflow deliberately excludes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. trickest/cve on GitHub