0xMarcio/cve: An Automated Index of Proof-of-Concept CVE Repositories

What 0xMarcio/cve Indexes and Who Uses It

The repository functions as a continuously refreshed watch list for security researchers, penetration testers, and defenders who need to know which CVEs have moved from paper description to functional exploit code. Rather than storing exploit payloads itself, it links to individual GitHub repositories where researchers have published working PoC implementations.

The homepage at cve.codepwn.win (and the companion pocindex.io domain referenced in the README badges) presents the same data as the repository's README: a "Just landed" table of the most recently added entries and "Trending" tables grouped by year, currently showing 2026 and 2025. Each row names the PoC repository, gives its description, shows how many stars the PoC repo has accumulated, and records how recently it was last pushed.

The intended audience falls into three groups. Defenders need to know quickly whether a vulnerability in their stack has public exploit code so they can prioritize patching. Penetration testers use it to locate PoC tooling for authorized engagements. Security researchers track what the community is actively publishing to understand where attention is focused in the current threat landscape.

The GitHub Actions Pipeline Behind the Updates

The README carries a GitHub Actions status badge that links to a workflow named hot_cves.yml. This workflow drives the automated data collection and index rebuilding. The repository's top-level layout confirms the tooling behind it: a scripts/ directory handles the aggregation and processing logic, an index/ directory stores the generated index data, a cves/ directory holds the raw CVE entry data, a docs/ directory contains documentation, and a tests/ directory covers the pipeline itself.

The badge also links to a commits stream showing frequent pushes to the main branch, consistent with a pipeline that runs on a schedule rather than only on manual commits. The README does not document the specific schedule interval, the exact source APIs the scraper calls, or the filtering logic that determines which PoC repositories appear in the tables. Those details live in the scripts/ directory, which the README does not document.

The effect of this automation is that the README and the live website at cve.codepwn.win stay aligned without manual curation of each entry.

Reading the Just Landed and Trending Tables

The "Just landed" table shows the most recently added repositories in reverse chronological order. The entries visible in the README range from hours to a few days old and cover CVEs in products such as GitLab, WordPress plugins, Linux kernel components, Joomla extensions, and Windows Netlogon.

The "Trending" tables are grouped by calendar year and sorted by star count on the linked PoC repository. High-star entries in the 2026 trending table include CVEs for Citrix NetScaler, CUPS, Craft CMS, WordPress Core, and macOS SMB. These tables give a year-level view of which disclosed vulnerabilities attracted the most community interest in terms of PoC development activity.

Browsing the live website at cve.codepwn.win avoids cloning the repository entirely, which is the practical path for researchers who want a quick lookup rather than a local copy of the data. The README does not document a search interface, a programmatic API, or filtering by product category or CVSS score range on either the site or within the repository structure itself.

What the Index Does Not Tell You

The tables show community star counts and recency, but not CVSS severity scores, affected software versions, patch availability, or vendor confirmation status. A four-star entry and a zero-star entry could be equally severe depending on how widely the affected software is deployed in a given environment; the index gives no way to make that distinction from within its own data.

The README also does not document how entries are discovered, whether they are manually reviewed for accuracy, or what the process is for removing entries when a CVE is disputed or a PoC repository is found to be mislabeled. Repository descriptions in the index are taken from the linked PoC repo's own description, and individual contributors can write whatever they choose. A check of the listed entries shows several where the description is a brief one-line summary of the vulnerability, while others include more detail about affected versions.

For researchers who need to confirm that a CVE is real and that the listed PoC accurately implements it, the index is a signal to investigate, not a final answer. MITRE's official entry and the affected vendor's advisory remain the authoritative sources for vulnerability details.

0xMarcio/cve vs. NVD and Exploit-DB

The National Vulnerability Database maintained by NIST covers every CVE with CVSS scores, affected software ranges, references to vendor patches, and cross-links to related identifiers. It does not aggregate community PoC code or give any signal on whether working exploit code exists in public repositories.

0xMarcio/cve fills that specific gap. It tells you that a PoC repository exists and that the community has found it noteworthy enough to star, but it does not tell you anything about the severity, the affected versions, or whether a patch is available. Used alongside NVD, it answers a question NVD cannot: is there public exploit code for this CVE, and how recent is it?

Exploit-DB, operated by Offensive Security, is a structured archive that stores actual exploit code alongside verified metadata and CVE cross-references. It is more curated than 0xMarcio/cve but its update cadence depends on manual submission and review. 0xMarcio/cve updates automatically from GitHub activity, so it surfaces very recent PoC repositories faster than Exploit-DB typically does, at the cost of lower curation and no stored exploit code of its own.

License and Activity Status

The repository is licensed under MIT, which permits use, modification, and redistribution with minimal conditions. The last push to the main branch was on 2026-09-25, and the GitHub Actions status badge linked from the README reflects ongoing automated runs. The repository has no tagged GitHub releases, consistent with a continuously updated data project rather than a versioned software release.

The README does not document a contribution process for adding PoC repositories, suggesting that entries arrive through the automated pipeline rather than manual pull requests. The docs/ directory is present but its contents are not exposed in the README, so the depth of operational documentation is not visible without cloning the repository.

Editorial conclusion

Security researchers and defenders who need a fast daily signal on which CVEs have working public exploit code will find this index useful as a first-pass triage tool. Teams that need CVSS severity scores, affected software versions, or patch guidance must pair it with NVD or vendor advisories, since the index carries none of that metadata. Before treating a linked repository as a confirmed exploit, verify it against MITRE's own CVE entry: the index depends on community-published PoC repos, and repository descriptions can misattribute CVE identifiers.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository