Why this exists
Put crudely: a feed says the bug exists, an advisory says what to install, and this says what has actually happened and to whose configuration.
One question, asked the same way every time
What is actually happening to real systems, and how well is it evidenced?
That's the whole scope. How bad it could be belongs to CVSS, and which versions are affected belongs to the CNA. Both already have owners. This one didn't.
During PHP2Shell in October 2026, a WordPress security vendor reported active exploitation incidents at 07:34Z. A CDN said early attacks were emerging nine minutes later. The next day a cloud provider called it broadly exploited in the wild and added that the success rate was unknown. By the 23rd the consensus had moved to no confirmed successful attacks.
Every one of those was defensible. Together they were useless. Each org applied its own evidence bar, so "exploited" did six different jobs in one week.
Meanwhile the person who actually had to decide something was a hosting support lead with a few thousand customers on an EOL branch, reading six vendor blogs at 2am and trying to work out whether to start taking sites offline. Nothing on the internet told them whether the thing worked against *their* setup, which was the only question they had.
The gap was never a missing feed. It was a missing evidence bar, and somebody willing to apply it to everyone's reports the same way, including the reports they don't like.
What this is not
| Alternative | What it does | What this does instead |
|---|---|---|
| A vulnerability feed (CVE, NVD, a CNA record) | Tells you a flaw exists, which versions carry it, and how severe it could be | Records what has been observed happening and how strong the observation is. Severity is a prediction of consequence. This is a record of behavior. A 9.8 nobody has ever touched and a 6.1 under daily attack are different operational facts, and only one of those is in a feed |
| A known-exploited list (KEV and the catalogs modelled on it) | Answers exploited yes or no, under one government owner, through a nomination process | Grades on five tiers, splits by deployment configuration, and shows the evidence behind every grade. A binary column cannot hold "the proof of concept works against mod_php and only crashes php-fpm", and it cannot hold "every in-the-wild claim graded to attempts and none met the bar for confirmed". Both were true of PHP2Shell and both mattered |
| A misconfiguration database (benchmarks, posture tooling) | Describes how a system ought to be configured, derived from policy | Describes what attackers did to configurations that actually exist, derived from observation. One is normative and tells you what to change. This one is empirical and tells you what happened. It never recommends a setting |
| A threat intelligence feed or a vendor write-up | Reports what one vendor's sensors saw, to that vendor's own evidence bar, with that vendor's incentives | Applies one published rubric to every report, from every source, and records who reported what. A vendor claim is input here, not output. "We blocked two million requests" is a real and useful observation that grades to attempts, because blocks are not compromises |
| An exploit database | Hosts proof-of-concept code so you can run it | Never stores a payload, a fragment or a working exploit, and rejects submissions that contain one. Hashes, header names, path patterns and rule references only |
| An advisory | Tells you what is affected and what to install | Grades observation and routes you to guidance based on your configuration. It does not write mitigations and does not rank them |
Why the grade belongs to a configuration
A tier attaches to a deployment fingerprint, not to a CVE. This is the part with no equivalent anywhere else.
For PHP2Shell the proof of concept got code execution against PHP as an Apache module. The same code crashed PHP-FPM on nginx without executing. Same CVE, two different facts, and an operator only cares about one of them.
A fingerprint that fails gets recorded too, and this is the bit people find counterintuitive. "The proof of concept does not achieve execution against php-fpm" lowers nothing. It is also the most useful line on the page, because it tells a very large group of people to stand down before they start pulling production sites offline on a Saturday.
The reason this is rare is boring rather than mysterious. Reproducing an exploit is interesting work and gets written up. Reproducing it and watching it fail is a negative result, and there has never been anywhere to put one.
Why it stands neutral
Datadog hosts this and pays for it. That goes first, because a registry that grades vendor claims should be plain about which vendor is writing the cheque.
Sponsorship buys hosting. It does not buy a grade.
The interesting question was never whether there's a logo in the footer. It's whether a sponsor's own report gets graded softer than a competitor's. So the answer has to be mechanical:
- Datadog's sightings go through the same rubric as everyone else's, and get downgraded the same way when the evidence is thin. There is no house exemption for "we blocked two million requests".
- Maintainers recuse from grading their own employer's submissions, Datadog's included, and every recusal is logged in public.
- No more than two core maintainers from one employer. That cap counts the sponsor like anybody else.
- Sources are curated on what they contribute, not on who published them. A competitor's research that explains an incident better belongs in the list, and goes in it.
- The rubric is published before the first contested entry, not written afterward to justify a call.
- Nothing is deleted. Disputes, dissents and downgrades stay in the log permanently.
None of that rests on anyone's good intentions, which is the point. Every line is checkable from the repo, and the easiest one to check is the sources list: go and look at whose work is in it. If it only ever cited one vendor you would be right to stop reading here.
Why it depends on the community
The core team adjudicates. It does not report. If the core ends up writing most of the sightings, this has quietly turned into a vendor feed with extra governance, and that failure is easy to walk into: chasing contributors is slow and writing it up yourself takes an afternoon.
Nobody saw enough of PHP2Shell to grade it alone. A cloud provider's honeypot caught the first attempt four days before disclosure and had no idea what configuration it hit. A lab had the first clean reproduction and no traffic. The hosting providers had the configuration detail, and hosting support teams are the least likely people in this industry to file anything on GitHub.
That last one is the real design constraint, so the mechanics bend toward contribution:
- Anyone can submit. Sign the record, file a pull request, or use a form that opens one for you.
- Anonymous reports are accepted, capped at the attempts tier, because a sensor operator who cannot attach their employer's name still saw something real.
- Negative results are wanted, and there is nowhere else to put them. "We tried it against this configuration and it did not work" is unpublishable almost everywhere and is load-bearing here.
- Disagreement is recorded, not resolved away. A disputed entry carries the flag publicly, the tier holds while it is argued, and the resolution and the dissent both go into a log where nothing is ever edited or deleted.
- Changing the rules is a pull request. The rubric and the schema move by majority with a comment window, in the open.
What it will never do
No severity scores. No ruling on affected-version disputes, which are a CNA problem and a genuinely miserable one. No threat actor attribution. No ranking mitigations, and no exploit code, ever.
Every one of those is somebody else's job, and most of them are jobs that quietly eat the project doing them. Scope creep here doesn't look like scope creep. It looks like being helpful.
Holding the line is what keeps the one question answerable.