2025 closed with roughly 48,000 published CVE records. By the end of August 2026, the NVD snapshot referenced in the recent analysis had already crossed 57,000, meaning that in just eight months, vulnerability disclosures had already moved beyond the volume seen across the whole of 2025.
The exact number will continue to move as CVE records are published, modified and reconciled. The CVE Program’s own reporting, for example, records 48,244 published CVE records for 2025.
But the precise number is not really the story.
The volume is.
We are entering a period where vulnerability discovery is scaling faster than the traditional processes organizations use to assess and remediate those vulnerabilities.
And that should force us to rethink how we patch.
The problem is no longer finding vulnerabilities
For many years, vulnerability management was built around a fairly predictable rhythm.
- Scan the environment.
- Receive the vulnerability findings.
- Check the severity.
- Create tickets.
- Wait for the patch cycle.
- Test.
- Deploy.
It worked because the volume was manageable.
Today, an enterprise can have thousands of applications, millions of software components, multiple cloud environments, third-party dependencies, APIs, containers, endpoints, network devices and embedded systems.
At the same time, the number of vulnerabilities being disclosed continues to increase.
NIST itself has acknowledged the scale of the problem. CVE submissions increased 263% between 2020 and 2025, and NIST said submissions in the first quarter of 2026 were already nearly one-third higher than the same period in 2025.
NIST has consequently moved toward a more risk-based approach to NVD enrichment, prioritizing vulnerabilities such as those in CISA’s Known Exploited Vulnerabilities catalog and other high-value categories rather than attempting to treat every CVE equally.
That is an important signal for every security organization.
If vulnerability intelligence itself needs prioritization, vulnerability remediation certainly does too.
We should stop treating every CVE the same
One of the biggest mistakes organizations can make is to turn vulnerability management into a race to reduce a number on a dashboard.
A backlog of 20,000 vulnerabilities looks alarming.
But 20,000 vulnerabilities are not necessarily 20,000 equivalent risks.
One vulnerability may be sitting on an isolated development system.
Another may be actively exploited against an internet-facing application supporting a critical business process.
Treating both the same because they happen to have a CVE identifier is not risk management.
CVSS remains valuable, but it should not become the patching queue by itself.
The organization needs to understand the context:
Is the vulnerability actually present?
Is the asset exposed?
Is exploitation practical?
Is it being actively exploited?
Does it affect a critical business service?
Is the vulnerable component reachable?
Is there a compensating control?
Is a reliable fix available?
Once those questions are answered, the remediation priority becomes much clearer.
AI is about to make this problem even more interesting
There is another force changing the equation: AI-assisted vulnerability discovery.
AI does not magically create vulnerable software. But it can make vulnerability research faster, broader and potentially much cheaper.
That is why the development around Mythos is particularly interesting.
Anthropic’s Mythos work has demonstrated that AI can operate at a scale that would be difficult to reproduce through traditional manual vulnerability research alone. Anthropic reported thousands of findings through its coordinated vulnerability-disclosure work, including vulnerabilities subsequently disclosed across hundreds of open-source projects.
Project Glasswing has also expanded its participation significantly, bringing more organizations into AI-assisted vulnerability research.
The important point isn’t whether every AI-generated finding eventually becomes a CVE.
Many won’t.
Some will turn out to be false positives.
Some will be duplicates.
Some will require deeper validation.
Some will be fixed without a public CVE.
The important point is that the cost and speed of discovering weaknesses is changing.
And that creates a new imbalance.
AI can make discovery faster.
But the organization still needs people and engineering capacity to fix what has been discovered.
That brings us to what I believe is the next major challenge.
AI-assisted remediation matters just as much as AI-assisted discovery
There is a lot of discussion about using AI to find vulnerabilities.
There should be equally serious discussion about using AI to remediate them.
Finding a vulnerability is only the beginning.
The real workflow is:
Discover → validate → determine exposure → prioritize → identify the fix → test → deploy → verify.
AI can potentially help across that entire chain.
It can correlate a CVE with the organization’s actual assets.
It can identify affected software versions.
It can analyse SBOMs and dependencies.
It can determine whether the vulnerable component is actually reachable.
It can help assess application dependencies.
It can prepare remediation recommendations.
It can assist with test-case generation.
It can analyse deployment results.
It can help determine whether the vulnerability was actually removed after remediation.
The objective should not be to hand production patching blindly over to an AI system.
The objective should be to remove unnecessary manual effort from the remediation process while retaining appropriate human governance and change control.
Because if AI discovers vulnerabilities at machine speed while humans remediate them at yesterday’s speed, the backlog will simply grow faster.
Organizations need to rethink the patching window
This is where the traditional patching cycle needs to change.
I don’t believe organizations should abandon maintenance windows.
They should abandon the idea that one patching window is sufficient for everything.
A much more practical model is to operate with two remediation lanes.
The first should be a dedicated priority remediation window.
This window is for vulnerabilities that represent material and immediate risk—actively exploited vulnerabilities, critical exposed systems, vulnerabilities affecting crown-jewel applications, or vulnerabilities where the threat intelligence indicates that waiting creates unacceptable exposure.
These vulnerabilities should not automatically wait for the next monthly cycle.
Then there is the normal remediation window.
The remaining vulnerabilities can continue through the organization’s standard maintenance process, based on severity, business criticality, exposure and operational priorities.
This creates a simple principle:
Not every vulnerability needs emergency treatment, but the vulnerabilities that matter most should never be trapped inside a routine patch cycle.
That is a much more sustainable model.
The remediation team needs to scale too
There is another reality that organizations need to acknowledge.
If vulnerability discovery continues to increase, simply asking the existing remediation team to work harder is not a strategy.
The remediation capability itself needs to scale.
That does not necessarily mean adding people endlessly.
It means combining:
people + automation + AI + better processes + better architecture.
Security teams need to work closely with infrastructure, application engineering, DevOps, SRE, cloud teams and product owners.
Security should identify and prioritize the risk.
Engineering should have the capability to fix it.
Operations should have the capability to deploy it safely.
And the organization should have the capacity to do this repeatedly.
The worst possible outcome is an organization with an excellent vulnerability-discovery capability and an undersized remediation capability.
That organization is essentially building a larger backlog faster.
Critical systems should not automatically become “untouchable”
One of the biggest mindset changes I would like to see is around availability.
We often hear:
“This is a critical system, so we cannot patch it.”
I understand the concern.
Availability is important.
But if a system is truly critical to the business, the answer should increasingly be resilience, not permanent patch avoidance.
If a critical application is deployed across multiple nodes in a high-availability architecture, remediation should be designed around that architecture.
Take one node out.
Patch it.
Validate it.
Return it to service.
Move to the next node.
Where appropriate, use rolling maintenance, controlled failover and health validation.
The service remains available while individual components are remediated.
And where rolling remediation isn’t technically possible, the organization should have a defined maintenance window specifically for critical remediation.
The key point is this:
Criticality should drive better engineering, not perpetual vulnerability exceptions.
Availability concerns need a different mindset
Patching itself is not always the difficult part.
The bigger challenge is often the organizational mindset around availability.
We have built many applications around the assumption that maintenance means downtime.
Then, when a security patch arrives, everyone asks:
“When can we afford to take the application down?”
Perhaps the better question is:
“Why was the application designed so that a security update requires the whole service to go down?”
Modern resilient architectures can provide alternatives.
Redundancy.
Failover.
Load balancing.
Rolling deployments.
Canary deployments.
Blue-green deployments.
Automated rollback.
Service isolation.
Replication.
These are normally discussed as availability and engineering practices.
They should also be considered security-enabling capabilities.
A resilient application is easier to secure because it is easier to change.
The same expectation should apply to OEMs
The responsibility does not sit entirely with customers.
OEMs and software vendors also need to think differently about security updates.
If a vendor expects customers to remain secure, the vendor should make security updates as operationally consumable as possible.
A security patch that requires a customer to shut down a critical environment for several hours is technically a fix—but operationally, it may be difficult to consume.
And when patches are difficult to consume, customers delay them.
That creates the gap between:
Patch available
and
Patch deployed.
That gap is where risk lives.
OEMs should therefore increasingly design products for non-intrusive security updates.
Where technically feasible, updates should support background download, pre-validation, staged deployment, rolling updates, health checks and reliable rollback.
The customer should not have to choose between security and availability every time a vulnerability is discovered.
The product should have been engineered to support both.
Security updates should become part of product architecture
This is especially important as more technology becomes software-defined.
Vehicles are increasingly software platforms.
Industrial equipment increasingly depends on software.
Network infrastructure is software-driven.
Enterprise appliances contain increasingly complex software stacks.
And cloud-native applications can consist of hundreds or thousands of individual components.
Security updates therefore cannot remain an afterthought.
They need to be considered during product architecture.
Can the product be updated remotely?
Can it be updated in stages?
Can one component be updated while another continues operating?
Can the system validate the update before activation?
Can it automatically roll back?
Can the vendor determine which versions are deployed?
Can the customer understand the security impact of not applying the update?
These questions should become part of product security engineering.
The real objective should be exposure reduction
This brings us back to the CVE numbers.
We cannot control how many vulnerabilities researchers discover.
We cannot control how quickly vendors disclose them.
And increasingly, we cannot assume that vulnerability discovery will remain human-speed.
What we can control is how quickly we understand our exposure and how effectively we remove it.
That means the most meaningful security metrics may eventually be less about:
“How many vulnerabilities did we patch?”
and more about:
“How much exploitable exposure did we remove?”
That is a very different measure.
An organization that patches 10,000 low-risk findings while leaving an actively exploited vulnerability on an exposed critical system has not necessarily achieved a strong security outcome.
An organization that identifies that critical exposure within hours and removes it safely may have reduced substantially more risk—even if its overall vulnerability count remains high.
The CVE explosion should force a strategic reset
The jump from approximately 48,000 CVEs in 2025 to more than 57,000 in the August 2026 NVD snapshot should therefore not trigger another discussion about how to make the monthly patch cycle slightly faster.
It should trigger a much bigger discussion.
Do we have the right vulnerability-management operating model for the environment we are entering?
AI is accelerating discovery.
Vulnerability disclosure is increasing.
Software supply chains are becoming more complex.
The number of components that organizations depend on continues to grow.
The answer cannot simply be to create a bigger spreadsheet of vulnerabilities.
Organizations need to move toward continuous, risk-based remediation.
Have a dedicated window for the vulnerabilities that genuinely demand priority.
Keep a normal remediation window for the remaining hygiene work.
Use AI not only to discover vulnerabilities but also to accelerate analysis and remediation.
Scale the remediation capability alongside discovery.
Use HA architectures properly.
Design applications to tolerate change.
And expect OEMs to deliver secure, reliable and increasingly non-intrusive update mechanisms.
Because the future of vulnerability management is not about eliminating the CVE backlog.
There will always be another vulnerability.
Another advisory.
Another dependency.
Another zero-day.
Another software update.
The organizations that are going to manage this environment successfully will be the ones that stop asking:
“How do we patch everything?”
and start asking:
“How do we remove the most important exposure quickly, safely and continuously?”
That is the real shift.
AI may eventually allow vulnerability discovery to happen at machine speed.
Our remediation capability now needs to catch up.
And perhaps the biggest change of all is accepting that availability and security should not be competing objectives.
If an application is truly critical, engineer it to remain available while it is secured.
If a product is truly important, design it to receive security updates without unnecessary disruption.
If a vulnerability is truly dangerous, don’t let a calendar determine when you respond.
Risk should determine the clock.
That is the vulnerability-management mindset organizations need for the next phase of cybersecurity.
