We are not near the end of software. We are near the end of trusting it.

The CVE chart is alarming. For years, published records stayed in the hundreds per month, rose into the low thousands, and then climbed nearly vertically in 2026. On October 22, CVE Tracker showed 12,688 records published in October already, a projected 17,350 for the month, and a projection of roughly 103,854 for the year. That would be more than twice the 48,244 records published in 2025.

Many readers will take that line as proof that software suddenly became far less secure. The data supports a narrower claim. Finding vulnerabilities, exploiting a selected few, stealing identities and impersonating legitimate people can all now happen at machine speed. Much of the work of fixing software, verifying humans and recovering control still runs at human speed.

Published CVE records per month from about 1999 to October 2026. The dotted section is the projection for the rest of October. Source: CVE Tracker.

The mismatch is real. It suggests the end of one era of computing, when software was a static artifact that you shipped, patched periodically, protected with a password, and then largely trusted.

The spike is real, but it is easy to misread

The CVE Program’s own metrics count 28,961 published records in 2023, 40,077 in 2024 and 48,244 in 2025. That is roughly 38% growth in 2024 and another 20% in 2025.

Then 2026 accelerated: the program reported 15,176 records in the first quarter and 20,709 in the second, a 36.46% quarter-over-quarter increase. That puts 35,885 records in the first half of 2026 alone, about 74% of everything published during all of 2025.

A CVE count measures disclosure, and Linux shows why that matters. The kernel team explains in its CVE documentation that almost any kernel bug might have security implications because of where the kernel sits in a system. The team assigns identifiers broadly, and the documentation says that policy accounts for the seemingly large number of kernel CVEs. It also notes that many of those CVEs will not matter to a given installation, because that installation uses only a small part of the kernel.

Reporting policy changes the numerator, and AI changes it again. Anthropic’s first Project Glasswing update in May said roughly 50 organizations using the model had found more than 10,000 high or critical severity vulnerabilities. Of 1,752 AI-discovered candidates that had been independently reviewed at that point, 90.6% were judged true positives. Anthropic said maintainers were increasingly limited by the work of triaging, disclosing and fixing bugs.

By October, Anthropic reported that Glasswing participants had found at least 129,000 verified vulnerabilities between April and July 2026, more than 33,000 of them rated high or critical. That is a vendor-reported lower bound drawn from partial data from 33 partners, not an independent economy-wide statistic, but the scale shows what happens when vulnerability discovery becomes automatable.

OpenAI described a similar defensive capability in its Patch the Planet work. GPT-5.5-Cyber examined more than 30 million lines of Linux kernel code and automatically produced proof-of-concept code for eight information leaks and 24 local privilege-escalation cases from the issues it found.

The CVE curve mixes several things: more software, more attack surface, more bugs being named, broader assignment practices, better security research, and machines that can look for bugs at extraordinary scale. A world that gets dramatically better at finding vulnerabilities can temporarily look, by CVE count, like a world that is getting dramatically worse at writing software. Dismissing the spike as measurement noise would be a mistake too.

The dangerous change is in the defender’s clock

Verizon’s 2026 Data Breach Investigations Report found that exploitation of vulnerabilities became the most common known initial access vector, at 31% of breaches, while credential abuse fell to 13%. Among vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog, organizations fully remediated only 26% during 2025, down from 38% the year before. Median time to full resolution rose from 32 days to 43.

Forty-three days is long next to the attacker’s timeline. Mandiant’s M-Trends 2026 estimates a mean time to exploit of minus seven days, meaning exploitation was occurring on average before a public patch existed in the incidents behind that measure. Mandiant singles out edge and core network devices, which often lack the endpoint telemetry available on ordinary workstations.

Microsoft’s 2026 Digital Defense Report adds another measure of automated pressure: publicly exposed cloud workloads were attacked after an average of 5.3 hours. An attack attempt does not mean a successful compromise, but discoverable infrastructure draws hostile activity quickly.

The old model was roughly: bug discovered, disclosure, patch released, administrator eventually patches, attacker eventually notices. Now it looks more like: machine finds weakness, machines scan the internet, exploit appears, exposed systems are attacked, and the change-management ticket is still waiting for Tuesday.

AI is appearing on the offensive side too. In May 2026, Google’s Threat Intelligence Group reported a criminal actor holding a zero-day exploit it believed had been developed with AI and intended for mass exploitation. Google says its intervention may have prevented that campaign from running. The same research described attackers using AI for vulnerability research, exploit development and increasingly autonomous workflows.

The finding deserves attention, but there is no evidence yet that autonomous systems are producing millions of successful zero-day attacks. One of the strongest arguments against the collapse story comes from Google’s own zero-day tracking: GTIG counted 90 vulnerabilities exploited as zero-days during 2025, against 78 in its updated 2024 comparison and 100 in 2023. Google describes that range of roughly 60 to 100 per year as stabilizing, not exponential.

Published vulnerability counts are exploding, while known zero-day exploitation has stayed in a fairly stable range. The ratio between a CVE being issued and a vulnerability being weaponized against real organizations is enormous.

Attackers do not need to exploit everything

Of Google’s 90 tracked zero-days in 2025, 43, or 48%, affected enterprise technologies, and 21 hit security or networking products. Those are attractive because one compromised VPN, management appliance, identity system or network device can expose far more than one compromised end-user application. Browser vulnerabilities made up less than 10% of the zero-days Google observed, which GTIG reads as a sign that years of browser hardening have worked.

Attackers therefore concentrate on the systems where one compromise buys the most trust.

This is also why raw CVE volume is a poor guide to what to fix first. The PHP2Shell disclosure is a useful recent example: two critical bugs in a runtime that sits under WordPress, Drupal and a large share of the web, where the useful question is whether a specific internet-facing runtime can be reached and updated before someone uses it.

People are part of the attack surface

Software flaws are one half of the risk. The other half is communication, and much of what travels through modern channels can be synthesized cheaply.

Verizon still found a human element in 62% of breaches, with social engineering at 16%. In its phishing simulations, mobile-centric channels such as voice and text produced click rates 40% higher than email.

Microsoft’s telemetry points the same way: 93% of observed voice-phishing calls kept victims on the line long enough for social engineering to begin, and it detected more than 46 million business-contact impersonation attacks over twelve months. Between 89% and 95% of the email phishing attachments it observed led toward an attempt to steal credentials.

The FBI now warns explicitly that impersonation scams use AI-generated video, live video calls purporting to show executives or law enforcement, and caller ID spoofing. Social engineering itself has not changed much. The scam still relies on urgency, authority, fear and a story that fits. What AI changes is the cost of manufacturing the cues people use to decide that someone is real.

FBI IC3 recorded 1,008,597 complaints and $20.877 billion in reported losses for 2025, up from $16.6 billion in 2024. Those figures cover many kinds of internet-enabled crime, not hacking alone, but they show how much money can be extracted once digital trust is broken.

The effective attack often starts with an employee who believes they are talking to IT, and no cryptographic break is required. Mandiant documented exactly that with UNC6692, combining email flooding with Microsoft Teams impersonation to persuade targets to run what looked like legitimate support activity.

In practice, people have become part of the API surface. We spent decades building programmatic interfaces around valuable operations such as password resets, device enrollment, payments and account recovery. Next to each one sits a human-operated interface called support, finance, administrator or simply employee. If a criminal can make that person produce the same privileged state change as the software API, attacking the software is optional.

Cheap attention is what makes this scale. AI makes research that used to be expensive nearly free. A scammer used to pick which 100 people were worth researching. Software can research 100,000.

Digital property is becoming conditional

Legal ownership has not changed. Operationally, the meaning of possession has been shifting for years.

For a physical object, possession and exclusion are tightly coupled. If someone steals your bicycle, you no longer have the bicycle. For a digital asset, practical control looks more like a question: who does the identity system currently believe you are? Your data can still exist while somebody copies it. Your SaaS account can still work while an attacker uses the same session. Your source code can stay in Git while somebody compromises a dependency or an update channel.

Verizon found third-party involvement in 48% of breaches in its 2026 dataset, a 60% increase from the prior year. It also found weak remediation of cloud-account controls among third parties, with only 23% of identified missing or improperly secured MFA exposures fully remediated. Google describes a related pattern as a SaaS domino effect, where service accounts, OAuth tokens and integrations let a compromise of one trusted relationship spread into others. GTIG says the most consequential supply-chain compromises through 2025 and the first half of 2026 increasingly involved code repositories, dependencies and developer tools.

As a result, digital exclusivity has become conditional. Operational control of an important asset now depends on a long list of things remaining intact at once: your identity provider, your account recovery process, your endpoint, your browser session, your cloud provider, your administrator accounts, your dependencies, your update infrastructure, your vendors, and sometimes the judgment of a support employee answering the phone.

A failure anywhere in that chain can transfer effective control without transferring formal ownership. A stolen laptop and a stolen SaaS administrator token feel different for that reason. The laptop has a location. The credential is a delegation of authority, and copying it can create two apparent owners at once. Increasingly, the attacker’s goal is to become indistinguishable from someone the castle already trusts.

Security engineering still works

Some defenses show measurable results, which suggests insecurity can be reduced. Google’s Android team reported in late 2025 that memory-safety vulnerabilities fell below 20% of Android’s vulnerabilities for the first time. In the same post, Google said its Rust code showed more than 1,000 times lower memory-safety vulnerability density than its historical C and C++ code, with roughly four times fewer rollbacks and about 25% less time in code review for comparable changes. These are Google’s own production measurements and do not amount to a universal language benchmark. They do show that removing a bug class can happen without slowing engineering down.

CISA has pushed manufacturers toward memory-safety roadmaps for the same reason, arguing that the most promising path to eliminating memory-safety vulnerabilities is migrating to memory-safe languages, which removes the bug class instead of patching each instance.

Browsers show the same pattern. Browser zero-days fell below 10% of the 2025 total, and attackers shifted toward enterprise applications and network appliances.

Cybersecurity cannot promise the absence of bugs. The realistic goal is to make common routes expensive, contained or recoverable enough that attackers cannot turn every mistake into a catastrophe.

AI can strengthen that, at least in principle. Discovery can become orders of magnitude faster, and automated validation can sort real defects from noise. But the bottleneck moves. When a machine can find thousands of defects, a human queue labeled “security backlog” cannot keep up. The pipeline has to look more like software delivery itself: continuous discovery, automatic validation, risk-based prioritization, generated fixes, automated tests, rapid deployment and continuous verification.

Regulation is moving in the same direction. The EU’s Cyber Resilience Act applies to broad categories of hardware and software placed on the EU market and sets lifecycle security and vulnerability-handling requirements. Its reporting obligations for actively exploited vulnerabilities and severe incidents began applying on September 11, 2026. The main product requirements apply from December 11, 2027.

The philosophy is changing. Security is moving away from “we sold you some code, securing it is now your problem” toward “the manufacturer remains responsible for meaningful security properties and vulnerability handling across a support lifecycle.”

What is actually ending

The CVE inbox stops working as a security strategy. If publication can plausibly cross six figures a year, “patch all vulnerabilities” stops being a meaningful instruction. Prioritization has to follow exploitation, exposure, asset importance and compensating controls.

Passwords have become weak evidence of ownership. Attackers steal sessions, tokens and valid accounts, or persuade authorized people to hand over access. Identity and social engineering remain central even as software exploitation rises.

Users cannot serve as the security boundary. A person cannot reliably evaluate an endless stream of realistic emails, texts, calls and support requests. Systems have to be designed so that a convincing conversation alone cannot authorize a catastrophic action.

“Ship first, patch forever” is losing its justification. Patching stays necessary, but the Android results show why removing a vulnerability class beats generating an infinite stream of patches for the same recurring defect.

Software now behaves as a network of relationships. It is code plus dependencies plus identities plus cloud services plus build systems plus update channels plus operators. Security is a property of the whole network, so it has to be designed and checked at that level.

The largest assumption is that software trusted yesterday can be trusted today. The likely response is software that is more continuously verified, more automatically repaired, written in languages that make whole classes of defects hard or impossible, protected by stronger identity, isolated more aggressively, updated much faster, and designed on the assumption that some components will eventually fail.

Three questions instead of one

The CVE total says nothing about how bad a compromise would be.

How quickly can a dangerous vulnerability become exploitable? Exploitation is already the leading initial access vector in Verizon’s data, and the window between disclosure and exploitation has compressed to the point where it can precede the patch.

How much authority does one successful compromise buy? Enterprise appliances, identity systems and third-party integrations concentrate that authority.

How quickly can a system recover when trust turns out to have been misplaced? This is where continuous verification, fast rollback, strong segmentation and readable logs matter more than a perfect patch record.

There is reason for concern on all three, and also reason not to be fatalistic. Zero-day counts have not followed the CVE curve, browser hardening changed attacker behavior, and memory-safe engineering is removing entire defect classes. AI can find vulnerabilities for defenders before criminals find them, and regulation is pushing obligations upstream toward manufacturers.

The work ahead is redesigning how much trust a single message, credential or vendor relationship can carry.

Sources

1. CVE Tracker, checked October 22, 2026. Monthly and annual projections are the tracker’s own.
2. CVE Program metrics for 2023 through 2025 published record counts.
3. CVE Program report for Q1 2026 and report for Q2 2026.
4. Linux kernel CVE documentation, on broad CVE assignment and why many kernel CVEs do not affect a given installation.
5. Anthropic: Project Glasswing, an initial update, May 22, 2026.
6. Anthropic: Expanding the Cyber Verification Program, October 6, 2026. The 129,000 figure is a vendor-reported lower bound based on partial data from 33 partners.
7. OpenAI: Patch the Planet, June 22, 2026.
8. Verizon 2026 Data Breach Investigations Report, covering incidents from November 1, 2024 to October 31, 2025. The 26% figure refers to KEV-listed vulnerabilities, and the 40% mobile phishing figure comes from simulations.
9. Mandiant: M-Trends 2026.
10. Microsoft Digital Defense Report 2026.
11. Google Threat Intelligence Group: 2025 zero-day review.
12. Google Threat Intelligence Group: AI and vulnerability exploitation in initial access.
13. Mandiant: UNC6692 social engineering and custom malware.
14. FBI IC3 2025 Internet Crime Report.
15. Google: Rust in Android, move fast and fix things, November 13, 2025.
16. CISA: The case for memory safe roadmaps.
17. European Commission: Cyber Resilience Act summary and CRA reporting obligations.