Never Emitted

GitHub asks security researchers for credit, requires them to accept it, and displays it on the advisory page. It does not put that credit into the machine-readable record anything else actually reads.

Every CVE record has a field for it: credits, a container naming whoever found or reported the vulnerability. GitHub is one of the highest-volume CVE assigners in the world. Its advisory system asks reporters for credit, requires the credited account to accept before it displays, and shows it right there on the advisory page. That data exists, inside GitHub's own system, before the CVE record is ever written.

It never makes it into the record.

The first check

I pulled 238 GitHub-assigned CVE records where the linked advisory publicly credits a named reporter. Zero of the 238 carry that credit in the actual CVE record. To make sure this wasn't a quirk of which records I happened to check, I ran the other two optional fields the same schema defines, metrics and problemTypes. Both are present on all 238. GitHub fills in the optional fields it wants to fill in. Credit isn't one of them, not once, in 238 tries.

The full census

A 238-record sample could be an artifact of how I built it. So I stopped sampling and counted every CVE record published in a fixed window, June 1 to August 14, 2026, 4,889 records total, no filtering by reporter, no cherry-picking. Across every assigner, 46.9% of records carry a populated credit. GitHub's share of those 570 records: zero.

This isn't universal to CVE assigners, and it isn't a binary either. Some organizations get it right on every record using the exact same free, public tooling:

Red Hat and Apache land in the middle, real partial adoption, not just an on/off switch by organization. It's an achievable field to populate at real scale. GitHub, the busiest assigner in the sample, populates it on none of its 570.

Even when credit survives, it has nowhere to go

The second failure is structural. I traced all 43 credit-bearing records from the first check into the NVD, the database most security tooling actually queries, not the original CVE record. None retained the credit. The NVD's own schema has no field for it at all.

One example: CVE-2024-56512, an Apache NiFi vulnerability. The source record names the finder, Matt Gilman, directly:

"credits": [{"lang":"en","type":"finder","value":"Matt Gilman"}]

The NVD's copy of that same record carries no credits field, and the name "Gilman" does not appear anywhere in it. The record is marked fully processed, not stuck in a backlog.

This has been flagged before

None of this is a secret internally. A developer opened an issue against GitHub's advisory export in January 2023 pointing out that credit shown on the advisory page was missing from the machine-readable file. A GitHub staff member replied that March:

"Due to technical reasons, displaying credit information in the JSON files would have made this epic 2-3x as much work, so we cut that part for now."

Three years and seven months later, it's still cut. The issue is technically about GitHub's separate OSV export file, not the CVE record directly, so I checked both surfaces independently. Same result on each: 0 of 302 OSV export files carry a credit either.

Data and methods

Every API response behind these numbers is archived and public. Scripts, the full record list, and raw responses from GitHub's advisories API, its OSV export, CVE Services, and the NVD API are at doi.org/10.5281/zenodo.22119153 (CC0), mirrored at github.com/SyedAnas01/cve-credits-attribution. A short version of this work is under submission to MSR 2027's Data and Tool Showcase track.

Why I went looking

I'm an independent security researcher based in Chicago, not attached to a company or a lab. I run Cognivators, a small AI-automation shop, and I do vulnerability research on my own time, on my own dime. This year that work has turned into roughly 280 reports sent to maintainers and vendors, with confirmed fixes credited to me by name at Google, GitHub, Red Hat, Apache, and several others, including CVE-2026-14540, an SSRF in Google's own MCP Toolbox for Databases.

That's the part that made me go check this specific thing. When you don't have an employer's name on your CVE record, the record itself is close to the only durable proof the work happened. So I started asking a narrower question than "is my work getting fixed": is the credit itself actually making it into the systems that are supposed to carry it forward. It wasn't, for me or for the 237 other people in that first sample. The census made it clear this isn't a personal grievance, it's a real, measurable pipeline defect that happens to land hardest on exactly the kind of independent, unaffiliated researcher I am.

I'm glad to talk through how I found this, the methodology, or the broader disclosure work, not just hand over a link. Reach out any time.