What was published, beside what a catalogue listed as exploited. Two counts, never one ratio.
Every published CVE record, by CVE Project publication date.
One row per vulnerability, dated when a catalogue first listed it, not when exploitation began.
How to read it. Two separate counts, run cumulatively through each year so a part-finished year is only ever compared with previous years at the same point in the year. Left: records published. Right: listings a catalogue made.
Democratisation of CVE numbering had an effect on the left panel, not the right. The CVE Program widened who may issue an identifier, so published records grew partly because more organisations can file them. Catalogue listings did not grow for that reason. That is a large part of why these two counts are never divided into each other. Why that matters.
The 100 most-probed CVEs of each month, weighted by attempts and split by how old each one was at the end of that month.
How to read it. Each ribbon is the share of honeypot attempts aimed at CVEs of that age, measured at the end of each month. The stack height is traffic against that month’s hundred most-probed CVEs, not all traffic — it covers 70% to 88% of it. The easy misreading is the total: it moves with how many sensors reported, not only with how much scanning happened, which is why Share sits beside it and the two disagree in direction. An attempt is somebody aiming an exploit at a sensor; it is not a compromise, and it is not a victim.
Bars are what landed in your vulnerability management queue. Lines are catalogued exploitations requiring emergency mitigations.
How to read it. Bars are everything disclosed. The two lines are the part somebody has seen being exploited, and the part that was already being exploited on the day it went public. The bars and the lines are on different scales — left for bars, right for lines — because published runs to 40k a half year and listings to 500. Compare each series with its own past. A line crossing the top of a bar means nothing. What it means. In 2026H1 there were 35,853 vulnerabilities published, 485 newly named as exploited, and 134 of those were already being exploited when they went public.
Quarterly year on year (YoY) change across the three metrics that matter most.
New CVE records published this quarter, against the same quarter last year
270%YoYDouble or more
30k new vulnerabilities in 3 months, against 11k in the same three months last year.
Traffic for Top100 Honeypot-CVEs this quarter, against the same last year
42%YoYDown on last year
212k scanning attempts in 3 months, against 500k in the same three months last year.
CVEs exploited (KEV) when they went public, against the same quarter last year
79%YoYDown on last year
94 exploited on disclosure in 3 months, against 119 in the same three months last year.
How to read it. Every number is what happened in the last three complete months divided by what happened in the same three months one year earlier. One division, nothing fitted and nothing predicted, so 100% means only that this quarter matched last year. 100% is not the same as normal. These streams grow, so an ordinary quarter reads above 100%: the typical reading is 118% on vulnerability pressure, so the honest question is whether a reading is unusual FOR THAT STREAM, not whether it clears 100%. Vulnerability pressure counts every CVE record published in the window. Scanning pressure sums the daily honeypot connection counts of the hundred busiest vulnerabilities, re-picked each month. Zero Day Exploitation pressure counts CVEs whose first KEV listing is dated on or before their own publication day, meaning defenders had no advance warning. It does not mean no patch existed: where this site holds a vendor fix date for one of them, 88% were patched on or before disclosure. Each stream is compared only with its own past, never with the other two, because the three share no unit.
Every bubble is one vulnerability that honeypot sensors saw someone try over the last 7 days, placed left to right by the year its CVE was published and stacked by how much traffic it drew.
observed to 2026-09-09
How to read it. One mark per vulnerability the honeypots saw this week, placed at its publication date. Height is observations on a log scale, so each gridline is ten times the one below. Circle size is the CVSS score, not a quantity. Example: a mark far LEFT and high up is the one worth a second look: an old vulnerability everybody assumes is long patched, still being hunted daily. Red marks are accelerating week on week — worth crossing against anything you expose to the internet. The empty space is not safe space. These are internet-facing honeypots: they have ever seen a quarter of the KEV catalogue — 45% of network devices but 2% of operating-system flaws, and nothing at all from Apple. A vulnerability missing here was not observed, which is not the same as not attacked. Use this to find what is being actively hunted, never to rank down what is absent from it.
Attacked within 90 days of publication, per 10,000 published, by CVSS band.
publication cohorts 2016 to 2026
How to read it. One line per CVSS band, every cohort measured over an identical 90 days of life, so an old year and a recent one are compared fairly. Example: critical-rated vulnerabilities are attacked at 272 per 10,000 against 93 for high, so the score does separate. Switch to Count and the picture flips: 61% of everything actually attacked was rated below critical, because there are far more High vulnerabilities than Critical ones.
Annual KEV totals by technology domain. The categories sum to the same yearly totals as the KEV chart above; switch units for rates or shares.
How to read it. Annual counts every vulnerability once, in the year a catalogue first listed it as exploited. Each band is one technology domain, and the number above the stack is the same annual KEV total shown in the charts above. Monthly divides those same counts by the months covered; Share shows each domain as a percentage of that year’s total. Tap or hover a year for the category values. What it means. Web publishing and plugins went from 6.1 to 25.8 a month while operating systems barely moved, 6.9 to 7.3. Nothing moved away from the operating system — the other categories grew around it, so a smaller share of a bigger total is not a fall. The series starts in 2021 because earlier catalogue coverage is not comparable. About 84% of 2026’s listings name the technology outright; the remainder use the advisory text or a stated prior, so treat the smallest bands as indicative.
Published CVEs per technology domain, as a running total through each year.
How to read it. One panel per technology domain, one line per year, each a running total through the calendar, so a part-finished year is only ever compared with previous years at the same point in the year. Example: if the 2026 line sits above the 2025 line at Aug, that domain has disclosed more this year than last by the same date. These are counts of published records: disclosure, not exploitation.
Democratisation of CVE numbering had an effect on these counts. The CVE Program has widened who may issue an identifier, and many vendors now file records for their own products as a matter of routine. So a rising line is partly more software being examined and partly more organisations able to write it down. This data cannot separate the two. Why that matters.