Cybersecurity

45,601 Flaws This Year. 171 Are Being Used.

We counted both feeds on 28 July: 45,601 vulnerabilities published this year, 171 added to CISA's exploited list. The two curves have separated, and your patching policy is indexed to the wrong one.

CybersecurityBy Servola Tech Desk2026-07-285 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

45,601 Flaws This Year. 171 Are Being Used.

Key takeaways

45,601 vulnerabilities were published to the US National Vulnerability Database between 1 January and 28 July 2026, and 171 entered CISA's known-exploited catalogue in the same period. That is 0.37 percent, so scaling your patching effort with the CVE count now buys you almost nothing.
The line being repeated this week, that 2026 is on pace to double 2025, does not survive the arithmetic. The run rate is about 79,600 for the full year against 49,972 in all of 2025. That is roughly 1.6 times, and it is still the steepest rise on record.
Disclosure grew 63 percent year on year. Confirmed exploitation grew about a fifth: 171 additions so far against 245 in the whole of 2025. The two numbers stopped moving together.
NIS2 requires risk-based vulnerability handling and names no severity score anywhere. A standard that says remediate everything rated 7.0 and above is a cost you chose, not a rule you were given.
Before this quarter closes, rewrite the standard so evidence of exploitation sets the clock and the severity score only orders the queue behind it.

Two feeds, counted on the same morning

At seven in the evening on 27 July, CISA published version 2026.07.27 of its Known Exploited Vulnerabilities catalogue. Two entries went in: a Fortinet FortiOS flaw and a command injection bug in Arista's VeloCloud Orchestrator. That took the catalogue to 1,655 entries, which is everything the agency has been able to confirm as attacked since the list opened in 2021.

The next morning we queried the other feed. The US National Vulnerability Database, run by NIST, will tell you how many vulnerabilities carry a publication date inside any window you ask for. For 1 January to 28 July 2026 the answer is 45,601. For the identical window in 2025 it is 28,032. For 2024 it is 23,486.

Both numbers are public, both are free, and almost nobody puts them next to each other. Set side by side they say something the coverage this week has missed entirely.

It is not doubling

Start with the claim that has travelled furthest. The figure circulating since Monday is that the database has logged around 45,000 flaws and is on pace to double last year's total. The first half is right. The second half is not.

209 days of 2026 have produced 45,601 published vulnerabilities. Carried at the same rate to 31 December that lands near 79,600. The full 2025 count was 49,972. That is a multiple of about 1.6, not 2.

The distinction is not pedantry, because the smaller number is still extraordinary. A 60 percent rise in a single year is the steepest the record contains, and 2026 has already passed 91 percent of everything 2025 produced with five months still to run. The reason to insist on the accurate figure is that the inflated one invites the wrong response. Doubling sounds like an emergency that justifies doubling a team. 1.6 times sounds like what it is: a structural change in supply that no amount of headcount will absorb.

The exploited curve did not follow

Here is the number that should govern the decision. Of the 45,601 vulnerabilities published this year, 171 have been added to the known-exploited catalogue. One hundred of the catalogue's entries carry a 2026 identifier at all.

Run the same arithmetic on the exploited side. 171 additions in 209 days is a pace of roughly 299 for the year. CISA added 245 in the whole of 2025. So while disclosure rose 63 percent, confirmed exploitation rose about a fifth.

The two curves have separated, and the gap is widening every month. Whatever is driving the disclosure surge, and the vendors are fairly open that automated discovery is a large part of it, it is producing findings faster than anyone is turning them into attacks. The published count has stopped being a proxy for the work in front of you. It is now a measure of how much research the industry can run, which is a different question with a different answer.

One honest caveat, because it changes the instruction rather than weakening it. Absence from the catalogue is not proof that nobody is exploiting something. The list records what a government agency can confirm, and confirmation lags. That is an argument for treating exploitation evidence as the strongest available signal, not for treating its absence as clearance.

What the regulation actually asks of you

Most vulnerability standards written in Europe in the past three years contain a sentence of the following shape: everything rated 7.0 and above is remediated within thirty days. Anyone who wrote that sentence in 2023 signed up to a workload that has since grown by two thirds without their agreement.

It is worth checking where the sentence came from, because it was not the regulator. NIS2 puts vulnerability handling and disclosure among the risk-management measures an in-scope entity has to run, and it frames the whole obligation as proportionate to the risk the entity actually faces. It names no scoring system and sets no threshold. DORA does the same for financial entities: prioritise remediation by the criticality of what is affected, with no fixed score written anywhere in the text.

So the threshold was a local invention, adopted because it was auditable. It remains auditable. It has simply stopped being affordable, and it was never what either instrument asked for.

Rewrite the standard, not the headcount

The practical change is small and it can be made this quarter. Put confirmed exploitation at the top of the queue with a clock attached, measured in days. Everything else keeps a severity ordering but loses its automatic deadline, and gets handled in the normal maintenance rhythm against the systems that actually matter to you.

Two supporting moves make that defensible to an auditor. Write down which external evidence source you treat as authoritative and why, so the prioritisation is a documented method rather than a judgement call. And record the exposure decision for the systems you defer, because the thing a regulator asks after an incident is whether you had a reasoned process, not whether you hit a number.

The teams that will struggle over the next eighteen months are the ones whose policy is arithmetically impossible and whose auditors have not noticed yet. The count is going to keep climbing. The set of things actually being used against you is not climbing at anything like the same rate, and it is published every week for nothing.

Frequently asked questions

Where do these numbers come from?

Both are first-party feeds. The vulnerability counts come from NIST's National Vulnerability Database interface, queried for publication dates between 1 January and 28 July of each year. The exploitation counts come from CISA's Known Exploited Vulnerabilities catalogue, version 2026.07.27, counted by the date each entry was added. We ran both counts on 28 July 2026.

Does this mean we can stop patching most vulnerabilities?

No. It means the deadline attached to them should not be automatic. A vulnerability with no evidence of exploitation still gets fixed in the ordinary maintenance cycle, ordered by severity and by how exposed the affected system is. What changes is that it no longer competes for emergency capacity with something that is being used against organisations today.

Is a severity score still useful?

As an ordering device, yes. As a deadline trigger, it has become expensive and imprecise. A score describes how bad a flaw would be if someone used it, which is a different question from whether anyone is using it. Both questions matter, and only one of them has a public answer updated every week.

Does NIS2 or DORA require a specific severity threshold?

Neither text contains one. NIS2 sets out vulnerability handling as a required risk-management measure and expects it to be proportionate to the risk faced. DORA requires financial entities to prioritise remediation by criticality. The thirty-day rule for anything rated 7.0 and above is a convention the market adopted, not an obligation either instrument imposes.

The count will keep rising, and the honest reading of it is not that the danger grew by 63 percent this year. It is that measurement got cheaper and attack did not. An organisation that indexes its security effort to the first number will spend the next two years busy and no safer. The list of what is actually being used against European companies is short, public, and updated most weeks, and it is the only one of the two that should carry a deadline.

CVENVDCISA KEVNIS2DORAvulnerability managementpatching

A Bricked Building Costs More Than a Ransom

On 15 July 2026 CISA added CVE-2023-4346 to its KEV catalog. The KNX flaw has no patch. The fix is a commissioning setting, and the buildings are European.

5 min read

Cybersecurity

Your MFA Seeds Left Before You Patched

CVE-2026-15409 and CVE-2026-15410 chain into root on SonicWall SMA1000. Stolen TOTP seeds survive the patch, which is why Germany's BSI orders Assume Breach.

5 min read

Law & Regulation

The EA Buyout Now Hinges on Brussels

The largest take-private in history has cleared EA shareholders and US antitrust. The last real gate is the EU - and not classic merger review, but the Foreign Subsidies Regulation, facing its first blockbuster test.

3 min read

← All articles