nomi-sec/PoC-in-GitHub: a year-by-year index of public CVE proof-of-concept repos

What the year folders actually contain

The top-level tree is a set of directories named 1999 through 2026, plus LICENSE and README.md. Each directory corresponds to a CVE year. Inside, the README shows entries keyed by CVE identifier, each with an optional publication date and, for many entries, a short verbatim description followed by one or more links to GitHub repositories. CVE-2026-0073 has fifteen linked repositories; CVE-2026-0006 has one. That unevenness is the first thing a reader notices, and it reflects reality rather than curation: popular or easy-to-reproduce bugs attract many independent reimplementations, while others attract none.

The audience is narrow and specific. It is for people who already know a CVE identifier and want to find existing code for it, for vulnerability researchers checking whether a bug they are working on has already been published, and for anyone doing coverage analysis of a vendor's advisory stream. It is not for someone who wants to scan their own systems, because nothing in the repository performs detection. The README's own framing is blunt: the project describes itself as an automatic collection and adds a malware warning, which sets the expectation that the linked code is unvetted third-party material.

How the collection is assembled and served

The repository itself is a build output. The commit history is not visible in the repository listing, but the structure tells you the shape of the pipeline: something queries GitHub for repositories whose names or descriptions match CVE patterns, groups the results by the year embedded in the identifier, and writes them into the matching folder. The README is then regenerated from that data, since it contains the same links in the same order as the folders imply.

There is a separate web front end at poc-in-github.motikan2010.net, listed as the homepage. That matters for how you consume the data. Cloning the repository gives you a static snapshot of the index at the time of the last push, which was 2026-09-21. The website is the more convenient path if you only want to look up one identifier, and it avoids pulling a large tree. The trade-off is the usual one for generated indexes: there is no per-entry confidence signal, no deduplication of near-identical reimplementations, and no indication of whether a linked repository contains a working exploit, a write-up, a patch, or nothing at all. The link is the unit of information here.

Reading the index without installing anything

The README does not give installation instructions, because there is nothing to install. The data is the repository, so the way in is the project's own web front end at poc-in-github.motikan2010.net, which is listed as the homepage. That path avoids pulling the full year tree when you only want to check one identifier.

The other path is the repository tree itself. The top-level entries are the year folders 1999 through 2026, LICENSE and README.md, and the README is a flat document that repeats the same links the folders hold. Opening the year folder that matches the CVE identifier you care about, or finding the identifier in the README, gives you the advisory text and the list of linked repositories for that CVE. If the identifier is absent, the collection process did not find a matching repository at the time the index was generated. That is a negative result about public code, not a statement about the vulnerability itself.

The malware warning is not boilerplate

The README states plainly that the collection is automatic and that readers should be careful of malware. Treat that as the project's own description of its quality bar, because it is. Every link points to a repository written by someone else, with no review step described anywhere in the README. A proof-of-concept for a remote code execution bug is, by construction, code that executes something on a target. Repositories in this index have names that include words like exploit and bypass, and some are labelled as research rather than working code. Nothing in the index distinguishes the two.

The practical consequence is that this is the wrong tool for anyone who needs vetted, attributable exploit code, and it is the wrong tool for automated ingestion. If you build a pipeline that clones every linked repository and runs a build or a test against it, you are executing arbitrary third-party code chosen by a name-matching heuristic. The index is safe to read and unsafe to trust. The second limitation is coverage. The collection depends on how repositories are named and described on GitHub, so a proof-of-concept published under an unrelated name, or hosted outside GitHub, will not appear. Absence from this index is weak evidence of absence.

How it differs from a CVE feed with exploit references

The obvious comparison is a vulnerability database that carries an exploit-availability field, such as the reference sections maintained alongside CVE records or the exploit references attached to entries in a national vulnerability database. Those sources are curated at the record level: an analyst or a submission process decides that a given reference is relevant to that CVE, and the record is versioned and citable. The difference in approach is the direction of the join. A CVE record starts from the vulnerability and attaches references. PoC-in-GitHub starts from GitHub and attaches repositories to identifiers it recognises in their names.

That inversion is the source of both its value and its noise. It catches the long tail of independent reimplementations that a curated record would never list, which is exactly what makes the fifteen links under CVE-2026-0073 interesting. It also means the index has no notion of whether a link is authoritative, and no mechanism described in the README for removing a bad one. If you need a citable, analyst-reviewed statement that exploit code exists, use a database record. If you want to see how much code the community has published around an identifier, this index answers that question faster.

Licence, maintenance and the cost of staying current

The repository is licensed CC0-1.0, which places the index itself in the public domain. That covers the listing, the folder structure and the README as published. It does not and cannot cover the linked repositories, each of which carries its own licence or none at all. Copying a link from this index into your own tooling is unproblematic; copying the code behind it is a separate question you have to answer per repository. Nothing here is legal advice, and the licence of a linked proof-of-concept is the thing to check before you redistribute anything.

Maintenance cost is low in one direction and non-zero in another. The last push was on 2026-09-21, and the repository is not archived, so the generated index is being refreshed. Consuming it costs a browser tab or a clone and nothing more. The cost sits on the other side: the index is a snapshot, so any local copy drifts as new proof-of-concepts are published. There are no releases in the repository, so there is no versioned artefact to pin against. If you mirror the tree, you own the refresh schedule yourself, and the only way to know how stale a local copy is, is to compare it against the upstream repository.

Editorial conclusion

Use it when you already have a CVE identifier and want to know whether anyone published proof-of-concept code for it, or when you are tracking how much public exploit code exists around a vendor's advisories. Do not use it as a scanner, a patch source or a substitute for a vulnerability database: it holds links, not detection logic, and the README itself warns about malware. Before relying on an entry, open the linked repository and check who wrote it and what the code actually does. The first thing to verify for any CVE you care about is whether the year folder for that CVE exists in the tree at all, because the index only covers what the collection process found.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. nomi-sec/PoC-in-GitHub on GitHub
4. Project website
5. README