Every morning the CVE Explorer we run at UK Cyber Defence pulls four feeds and joins them up: the National Vulnerability Database for what has been published and how severe it is, FIRST's EPSS model for how likely each flaw is to be exploited, CISA's Known Exploited Vulnerabilities catalogue for what is being exploited, and Exploit-DB for what now has a public exploit. On 22 September I asked it for the year to date and turned the answer into a seven-page report, generated at 07:52 UTC. This piece walks through what it found, adds what CISA's own feed says about deadlines and products, and ends with the rule I would give any team that has to decide what to patch on Monday.
The short version is this. Between 1 January and 22 September, 70,686 vulnerabilities were published. 8,060 of them are rated critical. 161 of them, a fifth of one per cent, are known to be exploited. The volume is enormous, the part that needs an emergency change is small, and the data is good enough to tell you which is which, provided you ask it the right question. The right question is not "how severe is it?".
The year in numbers
The headline figures first, all from the report. 70,686 CVEs published this year, 14,081 of them in the last thirty days and 4,328 in the last seven. 8,060 rated critical and 28,376 high. 233 entries added to CISA's catalogue of exploited vulnerabilities this year, taking it to 1,717 since it began in 2021. 172 CVEs that gained their first public exploit in Exploit-DB this year, against 25,049 with an Exploit-DB entry in all. 316 new CVEs that EPSS gives at least a one-in-ten chance of exploitation in the next thirty days. Behind all of it sit 395,963 records going back to 1999.
If you add together this year's CVEs that are in CISA's catalogue, the ones with a public exploit, and the ones EPSS rates at ten per cent or more, you get 464. That is about one in every 150 vulnerabilities published this year. The other 149 are real, and most of them will need patching eventually, but none of them is telling you to stop what you are doing.
Volume: the year more than doubled its pace
Here is every CVE published this year by month and by the severity recorded against it, straight from page two of the report. September runs to the 22nd.
Jan Feb Mar Apr May Jun Jul Aug Sep
Critical 446 443 663 568 695 967 1,356 1,821 1,101
High 1,621 1,623 2,586 2,228 2,839 3,358 4,174 5,268 4,679
Medium 1,898 2,041 2,477 2,469 2,829 3,090 3,483 3,757 3,454
Low 276 443 506 545 569 523 596 715 663
Not scored 902 258 72 75 53 63 310 1,158 1,025
All 5,143 4,808 6,304 5,885 6,985 8,001 9,919 12,719 10,922January saw 5,143 new CVEs. August saw 12,719, nearly two and a half times as many. September had reached 10,922 by the 22nd, which is close to 500 a day, and the busiest single week of the year so far, in September, carried 4,862. This is not a blip in one vendor's disclosure schedule. NIST, which runs the National Vulnerability Database, said in April that CVE submissions increased 263 per cent between 2020 and 2025 and that the first three months of 2026 were running nearly a third higher than the same period of 2025. The report's monthly figures show the pace still rising, from about 180 a day in the first quarter to about 400 a day since the start of July.
The practical consequence is not new, but the numbers make it hard to argue with. If your patching process depends on a person reading each advisory and deciding what it means for you, it stopped working some time ago. Nobody reads 500 advisories a day. The only question that scales is a filter: which of these affect software I actually run, and which of those are being used against someone.
The mix has shifted too. In January, 40 per cent of the month's CVEs were rated critical or high; by August it was 56 per cent. I would not read too much into that. Since April, NIST no longer routinely adds its own severity score where the organisation that reported a flaw has supplied one, so a growing share of the severities in the database are the reporting organisation's own assessment, and a change in the mix may say as much about who is doing the reporting as about what is being found. I come back to that in the section on where the data is weak.
Severity is not likelihood
This is the table that matters most, and the reason for the title. Page two of the report places every one of this year's CVEs once, by severity and by the strongest evidence that anyone is exploiting it. The columns run from most serious to least: in CISA's catalogue of known exploited vulnerabilities, a public exploit in Exploit-DB, an EPSS score of ten per cent or more, EPSS between one and ten per cent, and everything else. Each CVE sits in the leftmost column it qualifies for. The bottom row is my own addition.
In KEV Public EPSS EPSS EPSS <1% Total
exploit 10%+ 1-10% or none
Critical 85 36 81 696 7,162 8,060
High 61 46 73 1,219 26,977 28,376
Medium 15 20 18 260 25,185 25,498
Low · 3 26 255 4,552 4,836
Not scored · · · 1 3,915 3,916
All 161 105 198 2,431 67,791 70,686Read the critical row first, because it is the one most organisations patch by. Of 8,060 critical CVEs published this year, 85 are known to be exploited and 36 more have a public exploit, which is 121 between them, or one and a half per cent. 7,162, or 88.9 per cent, have no sign of exploitation, no public exploit, and an EPSS score below one per cent or no score at all. They are severe in the sense that they would do real damage if someone used them. There is no public evidence, so far, that anyone is trying.
Now read the medium row. Fifteen medium-severity CVEs published this year are in CISA's catalogue and twenty more have a public exploit. A patch queue sorted by severity puts those 35 behind 36,436 critical and high findings, the great majority of which show no sign of exploitation. Severity describes how bad a flaw would be if it were used. It says nothing about whether it is being used, and that is the question that decides whether you are having an ordinary week or an incident.
The right-hand column is the good news, and it is the part of this report I most want boards to see. 67,791 of this year's CVEs, 95.9 per cent, sit in the calm majority: not known to be exploited, no public exploit, low predicted likelihood. They belong in a normal patch cycle, done well and on time. They do not belong in an emergency change, a board paper or a late night.
Three days is the new normal
The report lists the 25 most recent additions to CISA's catalogue, back to 2 September, with CISA's remediation deadline next to each. Eighteen of the 25 are due three days after they were added. The other seven are due in fourteen. Those deadlines bind US federal agencies, not you, but they are the closest thing the industry has to a free, public, expert judgement of how quickly a given exploited flaw needs closing, and they have got much shorter this year.
To see how much, I went to CISA's own feed and looked at every addition between 1 January and 21 September, the same 233 entries the report counts. In January and February, the normal deadline was 21 days. The last 21-day deadline was set on an entry added on 5 March, and from then until June, fourteen days was the norm. Since CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, on 10 June, 77 of the 100 entries added have carried a three-day deadline and the other 23 fourteen days.
According to the Cloud Security Alliance's summary, the directive replaces the two that governed federal patching before it, BOD 19-02 and BOD 22-01. The three-day tier covers the most dangerous combinations of four factors: being in the catalogue, being reachable from the internet, being automatable, and being capable of giving an attacker full control of the system. Catalogue entries that give full control also come with a requirement to check for compromise. Other catalogue entries get fourteen days, lower-risk combinations get longer, and some can wait for the next scheduled upgrade. That shape, a very short lane for the small set of flaws that are exploited, exposed and serious, and a proportionate one for everything else, is the right one, and it is available to anyone who wants to borrow it.
In the UK, the floor is Cyber Essentials. Its requirements, in version 3.3 from April this year, say that updates fixing vulnerabilities rated critical or high risk, which the scheme defines as a CVSS v3 base score of 7 or above, or as the vendor's own critical or high label, must be installed within 14 days of release. It explains the number in a sentence I agree with: "14 days is considered a reasonable period to be able to implement this requirement. Any longer would constitute a serious security risk while a shorter period may not be practical." On this year's figures, that rule reaches at least half of everything published, 36,436 critical and high CVEs, wherever a vendor has shipped a fix for software you run. That is the right floor for the calm majority. The exploited list is the lane above it, where fourteen days is too long and three is the benchmark.
Old flaws, new entries
233 entries were added to CISA's catalogue this year, but only 161 of this year's CVEs are in it. The other 72, nearly a third of the year's additions, are vulnerabilities first published before 2026.
Some of that is the catalogue catching up with history. In a single batch on 20 May, CISA added CVE-2008-4250, the Windows Server service flaw better known as MS08-067, which the Conficker worm later spread through, and CVE-2010-0249, the Internet Explorer flaw used in the Operation Aurora attacks disclosed in January 2010. Both were exploited in the wild long before the catalogue existed.
Some of it is not history. On 18 September CISA added two Linux kernel flaws, CVE-2025-39682 and CVE-2025-39964, published in September and October 2025, each with a three-day deadline. If your kernel patching slowed down after the initial advisory a year ago, those servers went from "patch in the normal cycle" to "patch by Monday" overnight. The lesson is the one I keep coming back to: a vulnerability management programme is only as good as its inventory, and an inventory that only tracks this year's software will miss the thing that bites.
What is actually being exploited
The report's recent additions read like a list of the parts of an estate that nobody thinks of as a computer until it is too late. Cisco's Firewall Management Center, Identity Services Engine and Secure Email Gateway. Citrix NetScaler. Fortinet. Two MikroTik RouterOS flaws on the same day. A Zyxel switch. CVE-2026-20079, the Cisco Firewall Management Center authentication bypass, has the highest EPSS score in that list at 75.8 per cent. I wrote in July, when FortiSandbox was on fire, that the equipment sold to defend the perimeter has become the softest part of it. The year's data agrees. Across all 233 of this year's catalogue entries, Cisco has seventeen, eight of them in its SD-WAN family, and Fortinet, SonicWall, Ivanti, Citrix and Palo Alto Networks all appear more than once.
The second group is the management plane: the tools that manage everything else. ConnectWise ScreenConnect and N-able N-central both appear in September, alongside Acronis Backup. Across the year, N-central and SimpleHelp have three entries each, ScreenConnect two, and BeyondTrust's remote support products, Quest KACE, Microsoft Configuration Manager and VMware vCenter one or more. An attacker who owns your remote support tool or your backup console does not need an exploit for anything else. Those systems should be patched first, reachable from as few places as possible, and never from the open internet.
The third group is newer, and it is the one I would put in front of any board that has approved an AI project this year. By my count, eleven of this year's catalogue entries are AI and machine-learning tools: five for Langflow, one of them listed under IBM's name, three for BerriAI's LiteLLM, and one each for MLflow, Ray and marimo. CVE-2026-39987, in the marimo Python notebook, is a terminal endpoint that did not check who was connecting. It was published in April, is in CISA's catalogue, has an EPSS score of 99.6 per cent, and gained a public exploit in Exploit-DB on 2 September. Tools like these are easy to stand up quickly, often by data teams working outside the normal change process, and they usually hold credentials to the data they were built to analyse. Metabase is the same story from the analytics side: CVE-2026-72898, the SQL injection behind the City Relay breach, went into CISA's catalogue on 11 August, and a different Metabase flaw, CVE-2026-59827, gained a public exploit on 3 September.
The fourth group is the developer toolchain. JFrog Artifactory has four entries this year, two of them added on 11 September. GitLab has three, JetBrains TeamCity two, and Gitea and Gogs one each. More striking is a kind of entry that used to be rare: software that was deliberately poisoned. CISA's catalogue calls these "embedded malicious code" vulnerabilities, which is its way of saying that the software itself was the attack. There were four in the whole of 2024 and 2025, two of them GitHub Actions. There have been four already this year: the eslint-config-prettier package, Aqua Security's Trivy scanner, the Nx Console extension and the Daemon Tools Lite installer. I wrote about attackers living off GitHub in July; this is the same threat arriving through the build.
One more figure from CISA's feed belongs here. Of the 233 entries added this year, 27 are flagged as known to have been used in ransomware campaigns, among them both TeamCity entries, the Nx Console package, and flaws in SimpleHelp, ScreenConnect, SmarterMail and PaperCut. The list mixes the same kinds of software as everything above: edge devices, remote management tools, developer tooling and mail servers.
EPSS: a good second opinion, a poor alarm
EPSS, in FIRST's words, is "a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days." It is updated daily for every CVE, it is free, and it is the best tool available for ordering a long list. The report's fourth page shows why it should never be the only tool.
The beeswarm chart places every CVE published this year that is in CISA's catalogue or has a public exploit, 266 of them, along the EPSS axis. The report's own figures let you count the two sides of the ten per cent line: 316 of this year's CVEs score ten per cent or more, 198 of those are neither in CISA's catalogue nor publicly exploitable, so 118 are, which leaves 148 of the 266, more than half, scoring below ten per cent. Counting the points on the chart, those 148 are 61 of the 161 CVEs in CISA's catalogue and 87 of the 105 that have a public exploit but are not in it. For more than a third of this year's catalogue entries, that means known exploitation and a low model score. The recent additions make the same point. Of the 25 most recent additions the report lists, only four had an EPSS score of ten per cent or more on the day the report ran, and ten were below one per cent.
Now look at the other end. The fifteen CVEs published this year with the highest EPSS scores, all between 95.5 and 99.9 per cent, are every one of them in CISA's catalogue: three Ivanti flaws, a Linux kernel flaw, Progress LoadMaster, marimo, Apache Tomcat and ActiveMQ, cPanel, GNU InetUtils, WordPress, Splunk, SmarterMail, Langflow and Oracle PeopleSoft. My reading of the two ends of the chart is that EPSS gets there, but mostly after exploitation has begun and the evidence has built up, which is the point at which you needed to have acted already.
So use it for what it is good at. EPSS is excellent at sorting the 67,791 CVEs in the calm majority into a sensible order, and at picking out the 198 this year that score ten per cent or more without being in CISA's catalogue or having a public exploit, which is a manageable list for the next change window. It is not an early warning, and a low score should never be the reason a catalogue entry waits.
A mitigation is not a patch
The report was generated on 22 September. Four days later, BleepingComputer reported that the ShinyHunters extortion group had found a URL-encoding trick that gets past the web application firewall rules organisations were using to protect Oracle PeopleSoft against CVE-2026-35273, and had resumed exploiting it widely.
The history of that flaw is worth setting out. According to Help Net Security's report of Oracle's alert, ShinyHunters were exploiting it as a zero-day between 27 May and 9 June. Oracle published an out-of-band security alert and fix on 10 June. Among the mitigations for those who could not patch at once was blocking external access to two paths at the perimeter. CISA added the flaw to its catalogue on 12 June with a three-day deadline, and in the report it sits in the top fifteen by EPSS at 95.5 per cent. More than three months later, there were evidently still servers relying on those rules rather than on the fix.
A firewall rule matches a pattern, and an attacker who wants in will change the pattern; a patch removes the flaw. Mitigations are the right answer for the first few days, while a change is tested and scheduled. They are the wrong answer for three months. The same is true of the WordPress core flaw I wrote about in July, CVE-2026-63030, which sits in the same top fifteen at 97.3 per cent.
Where the data is weak
Every figure in the report is only as good as its sources, and it is worth being plain about where those sources are thin, because they are thinner this year than they used to be.
The first weakness is scoring. 3,916 of this year's CVEs had no severity score at all when the report ran. Most of those are recent, because scores lag publication by days or weeks, but 1,158 of August's CVEs were still unscored three weeks after the month ended, and 902 from January still have no score. A patch policy keyed to CVSS scores silently skips all of them.
The second is enrichment. On 15 April, NIST changed how it runs the National Vulnerability Database. It now prioritises for enrichment, meaning product data and its own analysis, the CVEs in CISA's catalogue, CVEs in software the US federal government uses, and "critical software" as defined by Executive Order 14028. Everything else is listed as "Lowest Priority - not scheduled for immediate enrichment", the backlog published before 1 March was moved to "Not Scheduled", and NIST no longer routinely provides a separate severity score where the reporting organisation has already supplied one.
That change explains the oddest page of the report. The report counts only 81 vendors with a CVE this year, and its treemap gives the largest of them, Oracle, just 104 CVEs, against 70,686 published. That is because vendor names come from NVD's product data, and NVD now adds product data first to the records it prioritises. It also explains why Cisco shows fifteen CVEs, all fifteen in CISA's catalogue, and Fortinet seven out of seven: exploited flaws are enriched first. The treemap is a fair picture of what NIST has had time to look at. It is not a picture of which vendors are publishing the most vulnerabilities, and nobody should draw vendor league tables from it, including me.
The third is coverage. A public exploit in this report means an entry in Exploit-DB, which is one source among several; proof-of-concept code on GitHub or in commercial frameworks does not count, so the true figure is higher. CISA's catalogue lists what it has reliable evidence of, with a US government lens, and absence from it is not proof that nobody is exploiting a flaw. EPSS is a forecast. None of that changes the conclusion. All of it argues for the same habit: match the feeds against your own inventory, rather than reading someone else's league table and hoping.
What to do with it
The rule I would give any team fits on one line. If it is in CISA's catalogue or has a public exploit, and you run it, it is an emergency change. If EPSS gives it ten per cent or more, it goes into the next change window. Everything else goes through the normal cycle, in CVSS order, inside the fourteen days that Cyber Essentials sets for critical and high.
Three things make that rule work in practice. The first is an inventory you trust, because every step of the rule starts with "and you run it". The second is a check for compromise whenever you patch an exploited flaw on something that was exposed before you got to it: CISA now requires that of federal agencies for catalogue entries that give an attacker full control, and the reason is simple enough, because patching closes the door without telling you whether anyone came through it. The third is to take management planes and security appliances off the open internet, which protects you against next month's flaw as well as this one.
For anyone who makes software rather than just running it, there is now a legal reason to watch the same list. Since 11 September, manufacturers selling into the EU have had 24 hours from becoming aware of an actively exploited vulnerability in their product to send an early warning under the Cyber Resilience Act. "Exploited" has become a regulatory trigger, not just an operational one.
The data behind the report is free on this site. The CVE Explorer carries every record with a plain-English verdict on patch priority. The CVE Watchlist narrows all of this to the products you list and can tell you when something on your list moves. The KEV calendar puts CISA's deadlines into any calendar that takes a subscription. The same explorer runs at UK Cyber Defence, and if you would rather someone else did the matching every morning, that is what our managed SOC does for clients.
For boards
Of the vulnerabilities CISA added to its exploited list this year, how many did we run, and how long did each take us to fix against CISA's deadline?
Which of our systems manage other systems, such as remote support, backup, firewall management and identity, and can any of them be reached from the internet?
When we patch an exploited flaw on a system that was exposed before we got to it, who decides whether to look for signs of compromise, and how quickly does that happen?
The closing observation
The volume will keep rising. Since the start of July, CVEs have been published at an average of 400 a day, more than twice January's rate, NIST's own figures show five years of growth, and nothing in the data suggests the curve is about to flatten. It would be easy to write that up as a crisis, and plenty of people will.
I read it the other way. Of 70,686 vulnerabilities published this year, 67,791 are in the calm majority, and a well-run patch cycle deals with them without anyone at board level needing to know their names. The part that needs speed and attention is a few hundred flaws, most of them in the same few kinds of software, published on a free list by people with better visibility than any of us. A vulnerability programme's job is to make almost every morning a boring one, so that the few that are not get everything they need. This year's data says that is achievable, and most of the hard part is knowing what you own.
A note on sources and method
The report was generated by the UK Cyber Defence CVE Explorer at 07:52 UTC on 22 September 2026 from NVD, FIRST EPSS, the CISA Known Exploited Vulnerabilities catalogue and Exploit-DB, all refreshed daily, and it is free to share with attribution. "Published this year" means an NVD publication date between 1 January and 22 September 2026. Severity is the CVSS v3 or v4 base severity held in NVD at generation time. The figures on deadlines, ransomware flags and the kinds of product in CISA's catalogue come from CISA's own JSON feed, catalogue version 2026.09.25, restricted to the 233 entries added between 1 January and 21 September so that they match the report; four more were added later on 22 September, after the report ran. The grouping of those entries into edge devices, management tools, AI tools and developer tooling is my own. EPSS scores are those held when the report was generated, and they change daily. The summary of BOD 26-04's tiers relies on the Cloud Security Alliance's research note, because CISA's own pages refused automated access when I checked them. CVE links go to the record in this site's CVE Explorer, where the underlying references are listed.