The About box, the meta description, the og and twitter tags and the JSON-LD all
ended in a tacked-on list of features: "Updated hourly", "Free JSON API, no
signup", "Plain JSON, no key". None of it describes what the thing is, and the
meta description ran past where a result gets truncated anyway.
Four strings collapse to two so they cannot drift apart again. SUBTITLE is the
line under the wordmark and the social description; DESCRIPTION is the meta
description, the JSON-LD description and the GitHub About box. Both say what the
site is and stop.
82,000 CVEs sat behind one URL. Each of them is a query somebody types, and the
pages answering those queries belonged to other people: searching
"CVE-2026-72898 poc" returns SentinelOne, Horizon3, Wiz and BishopFox, all of
them serving one page per CVE.
Pages are flat files at /CVE-2026-72898. No /cve/ prefix, no extension, no
trailing slash. GitHub Pages resolves an extensionless request to the .html
beside it, checked against the live site rather than assumed.
Each page carries what the index already knows and nothing invented: every CVSS
assessment with its vector, EPSS with percentile, KEV date and ransomware flag,
Nuclei severity and CWE, and the PoC links grouped by source with stars and last
push. 94% of them carry three or more of those signals.
Discovery works two ways. sitemap.xml is now an index over one shard per year,
which fits the 50,000 URL cap on the split the data already has and lets a
crawler refetch only the year that moved. Search results link to the CVE page
instead of straight out to NVD, which moves to a chip beside CVE.ORG, and each
page links six related CVEs picked by shared PoC author.
Rendering all of them takes 20s and adds nothing to the repository: the payloads
they read are already gitignored and built in CI, so the pages go into the Pages
artifact and git never sees them.
The slug moved to 0xMarcio/pocindex, so the raw.githubusercontent URLs in the
README banner were riding a redirect. SLUG now lives in brand.py with the rest
of the identity and getTrending imports it.
The About description lost "with CVSS, KEV and EPSS. Free JSON API, no signup."
GitHub truncates listings near 150 characters, so that tail rarely rendered and
read as a feature list rather than a description. 142 characters now.
The MITRE disclaimer comes out of the footer. The brand carries no MITRE mark,
which was the reason for picking it, and referring to CVE identifiers by name is
ordinary descriptive use. NVD, Tenable and Rapid7 all do it without a notice.
_urltest.html is temporary and comes out in the next commit.
The site called itself three different things: CVE PoC Hub in the title, CVE
Radar in the h1 and the social metadata, and cve on GitHub. Google had no
consistent site name to settle on, so none of the mentions compounded. CVE
Radar was taken anyway, by SOCRadar's free tool and by cveradar.com.
Every user-facing name and URL now comes from scripts/brand.py, so the next
move is one edit rather than a sweep through the tree.
Also repairs the parts of the site a crawler could not use:
- robots.txt and sitemap.xml were both 404. scripts/build_seo.py writes them,
wired into the Pages job. trending_poc.json, kev.json and stats.json stay
crawlable because the first paint needs them; the five bulk payloads are
disallowed, which is 13.2 MB per crawl spent on data no crawler queries.
- Search state lives in ?q= now. Results were unlinkable, so nobody could cite
one and there was no route for a SearchAction to declare. replaceState
rather than pushState, so typing does not bury the back button.
- A WebSite JSON-LD block carries the name Google prints as the site name.
- The footer carries the MITRE trademark notice.
Moving the data files into index/ left three references behind in .github,
and the hourly job has been failing to stage its own output since. The
README has been advertising 104,016 CVEs with PoCs while the site served
89,125, and every KEV marker had dropped out of its table because the
catalogue was being read from a path that no longer exists.
Figures come from the same count build_site publishes, so the badges, the
hero card and the site cannot disagree again.
Discovery asks GitHub for repositories pushed in the last three days, so a
proof of concept written for a 2019 CVE in 2021 is unreachable however long
the job runs. nomi-sec/PoC-in-GitHub has collected them daily since 1999.
It collects without filtering, which is how this index inherited its junk
the first time, so nothing arrives trusted: every candidate goes through
qualifying_repo_cves, the same gate a repository found by search must pass.
Of 6,945 candidates the gate rejected 4,110 and accepted 2,835, adding
links to 1,528 entries that had none or had fewer.
Vulhub joins the curated archives beside ExploitDB and Metasploit. It is
241 entries, and each one is a docker-compose file and reproduction steps
rather than a description of a flaw.
Candidates are judged again every week rather than remembered as rejected:
an empty shell in March is often a working exploit by June.
Discovery only looked at the current year and the one before it, so a PoC
published this week for a 2023 CVE was never found. Exploits for older
vulnerabilities keep appearing, and the daily run has budget to spare: the
window is still three days, so the cost is five sets of search terms instead
of two against the same short window.
Twenty-eight year folders sat above the README, so anyone opening the
repository scrolled past 1999 through 2026 before reaching a word about what
it is. The entries move to cves/ and the files the pipeline reads and writes
move to index/, which leaves the root at README, LICENSE and five
directories.
Nothing about the data changes. Every script takes its two roots from the
same place, and all five syncs report zero writes against the moved tree,
which is what a correct repoint looks like.
An Oracle Critical Patch Update page, an Ubuntu Security Notice and a CERT
vulnerability note all say the same thing: a fix exists. None of them shows
anyone how the flaw works, so none belongs in a list of proofs of concept.
26,070 of them were in there, inherited from a workflow that kept every
reference a CVE record carried.
advisory_hosts.txt names the destinations, matched as host plus leading
path, and update_cves consults it so nothing of the shape returns.
securityfocus.com/bid joins them for a different reason: the service is
retired and every deep link now lands on a search box.
The list is deliberately short. Packet Storm, Full Disclosure, openwall,
bugzilla, hackerone and the exploit archives all carry working code often
enough that a host-wide rule would delete real proofs of concept, so they
stay and are judged link by link.
Wordfence templates do not exploit anything. They fetch a plugin's
readme.txt, read the version string and report that a vulnerable release is
installed: 80,706 of their 81,526 templates are that and nothing else, and
not one sends a payload. Yesterday's widening filed 35,383 of them as proofs
of concept, which is a claim the files do not support.
Judge the template rather than the repository it came from. A template whose
every request reads readme.txt, style.css or a changelog, and which never
sends a body or a payload, is a version probe and is skipped wherever it
comes from. That keeps the 382 real templates Wordfence does publish and
drops the same shape out of the community sets, which were re-hosting them.
39,973 templated CVEs becomes 4,929 and 19,504 entries give up a nuclei
section they should never have been given. The index returns to 104,184
CVEs with PoCs from an inflated 117,373.
ProjectDiscovery templates what the whole industry cares about, which leaves
most of the WordPress plugin CVEs that dominate this index with no runnable
check at all. Wordfence publishes one for nearly all of them and updates
daily; a second community set fills a further gap.
The filename pattern was the barrier. ProjectDiscovery names a template for
its CVE and nothing else, so an exact match worked; Wordfence appends the
plugin slug and an advisory uuid, and all 36,529 of its templates were being
skipped by a regex anchored to the end of the name.
4,420 CVEs templated becomes 39,973, of which 19,945 land on entries this
index carries. Ratings follow the links, so CVEs carrying a severity and
CVSS go from 3,952 to 23,897. ProjectDiscovery keeps precedence where it has
a template; the rest are read only for CVEs it does not cover.
The design asked for published and modified in the result column and the
frontend has been rendering them since the reskin, against a field nothing
supplied. Seeded from the CVE Program's daily release: 154,160 of 154,166
CVEs, so coverage on the indexed set is total.
The 590 MB archive is a one-off. Every record the delta log hands the daily
sync afterwards already carries its own dates, so update_cves keeps the file
current from work it was doing anyway.
Costs 0.86 MB gzipped on the index.
A module's CVE list comes from its own declared references, so an exploit
that chains two flaws should be linked under both. A scanner is different:
"SSL/TLS Version Detection" cites BEAST, RC4, POODLE and Logjam because it
reports on them, and CVE-2014-3566 was carrying it as exploit code. So were
"SSH Username Enumeration" and "JBoss Vulnerability Scanner".
Keep auxiliary and post modules only where they name a single CVE, which is
the shape of an auxiliary module that is itself the exploit; exploit modules
keep every CVE they declare. 3,542 links become 3,339, 86 entries lose a
Metasploit section entirely and 51 lose part of one.
Metasploit also ships CVE-1012-5358 for CVE-2012-5358. The regex accepted
it; an impossible year is now rejected before it can invent a 1012/
directory.
The first one never worked. It selected CVE-2026-75604, an id lifted from a
trending repository name without checking the CVE was in the index, and it is
not, so the command downloaded 48 MB to print nothing. The repo_meta example
was worse: it returned null every time, because those keys are lowercased and
the example was not.
Every command in the README has now been run against the deployed files, and
the block is regenerated from the same source, so what is printed is what was
tested. The examples also answer questions worth asking rather than restating
the schema: what the index knows about one CVE across all four sources, how
bad it is and how likely it is to be used, and what CISA says is being
exploited that also has a PoC here, ranked by exploitation probability.
The endpoint table gains the two new files and notes the size of the big one
and the key casing that caused this. A sources table replaces guessing where
any of it came from.
Five rows on the last run were an empty cell. The landed lane already fell
back to the CVE's own summary; these CVEs are older and always in the index,
so the same lookup costs nothing and no row ships blank now.
The just landed lane still ran the language filter, and a repository published
this morning does not have one: GitHub has not classified it yet. Measured on
a three day window, filtering on language dropped 17 of 47 CVE-2026 repositories,
and the ones it dropped were the newest. Both filters are gone from this lane.
Dropping them lets through what they were incidentally keeping out, so the
check is now direct: every candidate has its root tree read, and a repository
holding nothing but a README and a licence is rejected as a write-up rather
than an exploit. Three were turned away on this run, and the lane went from
ten rows to seventeen candidates carrying real code.
Rows also stop shipping blank. A repository a day old often has no description,
so the CVE's own summary stands in, taken from the index or, for a CVE too new
to have been synced yet, from NVD directly. Every row on this run has one,
where four were empty before.
CVE-BOT