Can I Forecast the Vulnerability Surge?

Research & Analysis | Working Paper 01 | Working version 1 | 31 October 2026

As I mentioned in my Black October article, October is my favourite month. It started off like the recent months, actually. But then, it became alarmingly unhinged. The number of vulnerabilities, as well as incidents, kept rising. And for the first time in history, CVE counts hit 6 digits. That is when I got the idea for this research item. I wanted to see whether I could predict the rise in CVEs and how it might change in the future.

As a cybersecurity practitioner, I follow the vulnerabilities and the known exploits quite assiduously. I even wrote an aggregator app for tracking threat intelligence. You can check it out yourself at medulus.elytrasecurity.com. It has never been a consistent rise month-on-month. It has had its ups and downs. And sometimes, it gets real ugly real fast. October 2026 is one of those crazy months.

But when I looked at it in a little more detail, I found that it is something even more than the regular crazy. By the end of September 2026, the number of CVEs had crossed 71,000. All of 2025 had only produced around 48,000. Just September 2026 had produced 15,000. How weird is that, I asked myself. I wanted to find out whether this was a temporary surge or whether something had changed in vulnerability discovery. At first, the obvious culprit was the rise of AI assistance in both offensive and defensive cases. At least, that is what I presumed.

Frontier models were being used by cybersecurity researchers to find vulnerabilities, and some of them were from decades ago. They were also used by cyber defenders to build agentic pen testing applications. Some of them were shared on GitHub. Now, while I am not against sharing such software, one has to remember that the tools used by the threat actors and defenders are the same. I have often said the outcome depends only on the user’s intent.

2026 also saw the open-weight models increasingly come close to the frontier models. We also read reports of how models were trying to escape the safeguards to achieve their goals in a lab setting. Some reports also mentioned how these models were used for offensive goals by some threat actors. At the same time, defensive cybersecurity tools are increasingly using agentic workflows.

All of these supported my thesis that AI definitely had something to do with the CVE surge. I wanted to use my theory to forecast future vulnerability discovery. This article follows my efforts in doing so and the order in which it happened. Some of my assumptions held up. Many of them were wrong in various degrees. I examined each assumption, tested it, and either adjusted it or discarded it over the course of developing this thesis.

The first problem was deciding what to count

With a number as high as 100,000, it was definitely a challenge. Published numbers were slightly lower. For those who are not in the know, the year in a CVE identifier reflects when it was reserved or assigned, not when the vulnerability became public. Some reserved identifiers never become public records. So 100,000 might result in fewer public records.

I chose the CVE publication statistics maintained by CRACI, a cybersecurity company that derives its vulnerability data from the official CVE Program repository. For purposes of forecasting, I decided to count CVEs by publication date. Public datasets also differ slightly. BlackTree reports 48,151 published CVEs for 2025 while CRACI reports 47,802, because of differences in collection, record status handling and later revisions. Mixing historical figures from one provider with current-month figures from another would add other errors and complications, so I used the CRACI series for the statistical work in my research.

The 40% jump in 2024 over 2023 did puzzle me at first. I wondered whether it was an early sign of AI-assisted discovery. It was not, or not mainly. In February 2024, kernel.org became a CVE Numbering Authority for Linux kernel vulnerabilities, which changed how many kernel vulnerabilities entered the public system.

CVE volumes depend on how many vulnerabilities are found, and also on reporting practice, on who assigns identifiers, and on how existing vulnerabilities are handled. I decided to keep these three measurements apart: published CVEs, known exploitation and remediation. CISA’s Known Exploited Vulnerabilities catalogue records vulnerabilities with established exploitation. Its entries do not necessarily relate to CVEs published in the same month, and they are not a count of attacks.

A published CVE does not tell me whether a fix exists or has been deployed.

First hypothesis: historical patterns give a reasonable baseline

I started with conventional time-series forecasting. I set myself a target of an annual total within 10% absolute error, updated each quarter. I used the Theta method on monthly observations from January 2020. For each historical year, I rebuilt the forecast using only the months before the forecast date and compared it with the actual count.

The mean absolute percentage error (MAPE) was 9.13%. MAPE is the average of the yearly absolute errors, each expressed as a percentage of the actual count. Three of the four years were within my target. 2024 was almost 20% low. Once I updated the annual forecast after each completed quarter, matters improved slightly, as I expected, because a forecast made after nine months already contains three quarters of actual data.

2026 was the real test for this hypothesis. The model returned about 54,103 CVEs for the whole year, when I ignored what had actually happened and forecasted assuming it was January 2026. The actual count passed that figure well before the end of September.

Forecasting 2026 one quarter at a time gave the numbers above. The combined weighted absolute percentage error (WAPE) was 29.82%. WAPE is the total absolute error divided by the total actual count. The model underestimated every quarter, and the gap widened as the year progressed.

Measuring the acceleration

The daily publication rate went from about 162 in Q1 to 223 in Q2 and 402 in Q3. That is roughly 37% growth from Q1 to Q2 and 80% from Q2 to Q3. The rate of growth was itself changing, and my model was not designed to measure that.

I tried growth formulations based on exponentially weighted changes in the logarithm of the publication rate. One produced a 2026 year-end estimate near 130,500. To see how such a method behaves, I ran an illustrative test on November and December 2025, using the BlackTree counts:

The two-month total was only about 1.6% above actual, which looked respectable. But November was overestimated by almost 40%, and December underestimated by 19%, and the errors cancelled at the end. This test also used a different series from the CRACI back-tests, so I did not combine its result with them.

Although I kept annual forecasting as the primary objective, I decided to further examine how the model behaves when there are changes within the year.

Back to the AI hypothesis

I still believed that the growth in the use of AI deserved attention. Capability was improving, an increasing number of researchers and organisations were using it, and some of the tools could run longer sequences of tasks without human intervention. Offensive researchers had access to the same systems. I treated model capability, defensive adoption and offensive adoption as three variables.

There was some evidence to work with. METR has published rapidly increasing AI task-completion horizons for software work. The 2026 SANS survey reports active AI use in cybersecurity rising from 50% in 2025 to 78% in 2026, and AI use in authorised red-team work rising from 33% to 61%.

A separate review of public finder credits counts 34 AI-credited CVE records between January and 23 October 2025 and 769 in the same period of 2026. That last increase is disturbingly large, but those credited records are under 1% of the 2026 CVE volume. Many AI-assisted discoveries are never credited, and the credit terminology is inconsistent. I treat it as evidence of increasing disclosed AI involvement, not an estimate of AI’s real share of discovery.

Three questions followed.

1. Could better AI capability and defensive adoption increase vulnerability discovery?
2. Could offensive capability affect how many vulnerabilities are discovered or exploited?
3. Could those effects accumulate over time instead of showing up immediately in the published count?

That third question eventually led to an integral formulation. But first, I wanted to know whether the available AI variables could improve the forecast at all.

Early AI-adjusted results looked better than they deserved

I built four model structures, M0 to M3: a conventional baseline, then added defensive AI capability and adoption, then offensive AI activity, then both. Some proxy-based versions showed quarterly errors near 5% in parts of 2026, far better than Theta.

The problem was method. The AI variables were retrospective proxies, not independent monthly measurements available at each forecast date, and some adjustments were informed by the 2026 behaviour they were meant to predict. A model that uses information from the period it is predicting can explain what happened, but its accuracy is misleading. I discarded the claimed accuracy improvements. While the hypothesis made some sense, I still had no reliable estimate of how AI adoption related to the publication rate.

Testing a nonlinear relationship

Perhaps better AI does not raise research productivity in proportion. A model that can review a code fragment helps. A model that can navigate a large codebase, find a flaw, build a reproducible test and validate the result makes much more feasible. There may be thresholds. I started from a simple relationship:

AI research capacity = Capability × Adoption × Research effort

I later considered accessibility and operational autonomy as extra factors. I tried logarithmic, square-root and linear transformations of effective capacity, using approximate measurements. I also made a deliberately generous assumption (some might call it naive) that the whole shortfall in a historical baseline forecast was attributed to AI, and then scaled by the estimated rise in AI capacity.

By 28th of October 2026, the CRACI count had already reached 87,545. All three full-year estimates were below the year-to-date total, so these formulations failed. The measurements were approximate, and the calibration was artificial. I could not justify choosing a more aggressive nonlinear function just because it landed nearer the observed 2026 figure. That would be incorrectly trying to fit the answer to the model, or the model to the real number. I wanted the model to arrive at a number close to the actual number.

Testing acceleration directly

Next I went back to the publication data. If the rate of change is rising, a model that projects the acceleration of the logarithmic rate might forecast the next quarter well. I used the daily rate for each completed quarter and the change in its logarithm across three quarters:

ln λ̂(n+1) = 3 ln λ(n) − 3 ln λ(n−1) + ln λ(n−2)

The model assumes constant log-acceleration. For Q1 to Q3 of 2026 the WAPE was about 9.0%, a big improvement on the conventional baseline. Then I tested it on earlier years:

In 2024 the model projected that the rapid Q2 increase would continue into Q3. Publications fell instead. It reacts to momentum but cannot tell when acceleration will continue and when it will reverse. It worked in the unusual conditions of 2026 and failed in several earlier years, so I do not consider it suitable for general forecasting.

This is where I became stricter about process. Every proposed change now needs a historical test before I adopt it, and if a variable has no independent measurements, I say so.

I was looking at the wrong end of the process

Until then I had concentrated on discovery and tried to connect it directly to publication volumes. But several steps separate the two. A researcher finds a flaw, reproduces it, establishes its security impact and reports it. The maintainer or vendor validates it, considers a fix and coordinates disclosure. A CVE identifier may be assigned during that process, and the public record may appear weeks or months later. Some confirmed vulnerabilities are fixed without a CVE. Others wait in queues alongside thousands of reports.

GitHub gave the most useful evidence. In June 2026, it reported private vulnerability reports rising from about 550 a week in January to more than 3,000 a week through much of May. Repository advisories and CVE requests rose sharply too, and CNA requests approached 4,000 in May, nearly ten times the previous year’s volume. Published CVEs did not rise in proportion to incoming reports. GitHub acknowledged that processing times were growing, with some reviews stretching from about a week to several weeks. Findings were arriving faster than validation and publication could handle them, which means discovery capacity and publication capacity can change at very different rates.

Anthropic’s coordinated disclosure data shows another side. As of 2nd October, the company reported 6,157 vulnerabilities disclosed to maintainers across 591 open-source projects, of which 516 were known to be patched upstream. The ledger records 219 CVE identifiers and 365 GitHub Security Advisories, with possible overlap. These numbers describe different stages and cannot be added into one count of new vulnerabilities. The gap between findings, validated vulnerabilities, patches and public identifiers was becoming central to my work. I began to suspect that the missing variable was the capacity of the disclosure pipeline itself.

CVE Numbering Authorities

The next thing I looked at was who was actually publishing all these records. CVE Numbering Authorities, or CNAs, are the organisations authorised to assign CVE identifiers and publish records for their own scope. Comparing January to September 2025 with the same period of 2026, GitHub, VulnCheck, Linux, Microsoft and Oracle account for about 62.7% of the net increase in published records. My first calculation actually gave 77.4%, which would have made a much more dramatic story. But I had mixed an increase measured through October with an overall increase measured through September. Once I fixed the observation windows, the number came down. I have kept the correction in the record, because it is exactly the kind of mistake that quietly distorts a model.

Growth is also uneven across CNAs. Some expanded their publication dramatically while others hardly changed. What this means is that a change in one organisation’s publication practice can move the total CVE count without any change in the underlying security of its products. I find that uncomfortable, because the headline number then says more about publishing practice than about the software.

I then tested whether quarterly publication volumes of GitHub, VulnCheck, Linux and Microsoft could predict the overall count, as a momentum indicator. Across three selected quarterly tests the weighted error was about 17.0%, against 28.2% for a naive baseline that simply repeats the previous quarter. That looked like an improvement. But the model did worse than the naive baseline in both 2025 tests and far better only in the rapid 2026 expansion, and three observations on a separate CNA-level series cannot establish a stable relationship. So I keep CNA publication activity as an explanatory variable, and I do not adopt the publisher-momentum model.

A better question for AI

I was uncomfortable representing AI with one capability score or one adoption percentage. During 2026, frontier developers added stronger cybersecurity capabilities, sometimes through restricted programmes first. Researchers produced impressive discoveries, and also showed weaknesses in model safeguards. Open-weight models narrowed the gap on some cybersecurity evaluations. Agentic security-research tools grew as well, covering reconnaissance, testing, validation and reporting with limited human intervention. And as I said earlier, the same class of capability serves authorised defence and potentially malicious use.

Anthropic’s Project Glasswing began with about 50 partners in April and later widened access. It showed that highly capable models can find large numbers of serious vulnerabilities, but that human validation and remediation then limit how fast those findings move. Microsoft’s FORGE programme reported 140 Windows CVEs addressed between May and September 2026, with rising numbers in successive monthly servicing cohorts. There is no doubt in my mind that AI-assisted vulnerability research is producing meaningful results at scale.

Capability alone does not tell me how much research is actually happening. I also need to know who has access, how widely it is deployed, how much autonomous work each deployment does, and how often that work yields valid, unique findings. That is how I arrived at the idea of effective AI-enabled vulnerability-discovery capacity, and it brought me back to the integral formulation.

My current hypothesis

My working hypothesis treats CVE publication as two connected processes. The first generates vulnerability findings. The second validates, coordinates and publishes a subset of them, with delays that vary a great deal.

For discovery, I define an effective defensive AI research-capacity function:

η(t) = f[κ(t), α(t), ξ(t), ε(t)]

• η(t): effective defensive AI research capacity.
• κ(t): model capability.
• α(t): adoption in vulnerability research.
• ξ(t): accessibility and operational autonomy.
• ε(t): effective research effort, including human supervision and computing resources.

The function f is deliberately unspecified. I have tried several simple transformations and found them inadequate, and I do not have the independent observations to estimate a better one. Newly validated, CVE-eligible findings are then:

Δ(t) = Δ₀(t) + γ[η(t)]

This is a hypothesis about discovery throughput, and I have not estimated γ. The next step is the time between discovery and publication, expressed as a finite distributed lag:

π(t) = Σ φ(t,τ) × Δ(t−τ) + ρ(t)     (sum over τ = 0 to Λ)

The model must not count the same finding twice. I also want the backlog explicit:

β(t+1) = β(t) + Δ(t) − π(t) − ω(t)

Together these separate discoveries entering the system from records leaving it. Discovery capacity could rise quickly while publication responds slowly. If validation capacity then expands or an older backlog clears, publication could jump. That might explain some of the uneven behaviour in 2024 and 2026.

I have not established the coefficients linking AI capacity to validated discoveries. I do not have a reliable historical distribution of discovery-to-publication delays, and I have not quantified the effective backlog across the major CNAs. The model can only be tested once those variables are measured.

I will keep offensive AI capability as a separate factor. It may contribute to discovery, but its effect is more likely to show in exploitation activity, exploit-development time and how quickly vulnerabilities are weaponised. I will examine CISA’s Known Exploited Vulnerabilities catalogue separately, taking care to distinguish the date of known exploitation, where available, from the date of catalogue addition. Remediation also needs its own analysis. A vulnerability that is disclosed, one that has a fix, and one whose fix is deployed are three different stages. I do not want those lost in a single headline number.

My results after the tests

The evidence increasingly supports the view that AI-assisted discovery, reporting activity and disclosure capacity are changing. I have not yet shown that the proposed mathematical relationships can forecast those changes. That remains the research problem. I call the framework AI-Conditioned Vulnerability Dynamics, or ACVD. For now it describes the research direction, and Theta remains the tested numerical baseline.

Early November 2026 is the real test

I wanted to record a forecast before October ends. The first prediction is a reconstructed Theta forecast using monthly observations through 30 September 2026. It gives 14,967 CVEs for October. I rebuilt it after October had begun, so it is a historical-cutoff back-test and not a prediction published in advance.

The second prediction uses the latest information. The CRACI snapshot dated 29 October UTC shows 15,701 CVEs published in the first 28 days of October. I scaled the daily rate to the full month:

October forecast = 15,701 × 31 ÷ 28 = 17,383

That is a calendar-rate nowcast. It assumes the next three days run at the average rate of the first 28, and it has no AI adjustment. I then updated the Theta model with the projected October total to get provisional November and December forecasts.

These figures are frozen as of 30 October 2026. The full-year estimate is provisional and depends heavily on November and December. The quarterly back-tests show the conventional model can substantially underestimate rapid change. Forecasting a whole month ahead and estimating its total after 28 days are different exercises. If the nowcast proves accurate, that shows short-range extrapolation worked on this occasion. It validates nothing about the AI-conditioned coefficients.

In the first week of November I will compare both October estimates with the first completed-month CRACI count, calculate the absolute percentage error for each, and record the observation date. Public CVE records can be revised or backfilled, so later snapshots may differ slightly. I will not revise today’s forecasts after seeing the result.

What next?

I began with a strong intuition that advancing AI capability and adoption were driving growth in vulnerability discovery. I still think that is credible. There is evidence of better AI cybersecurity capability, wider access, rising adoption in the security sector, and large research output from individual programmes.

The experiments have made me more cautious about turning that into one numerical multiplier. The publication system itself is changing. CNA practices, reporting volumes, validation capacity and remediation processes all affect when discoveries become public records, and they can move CVE counts suddenly even when discovery changes gradually. Models that look impressive during an acceleration can fail when the rate changes direction, as the constant log-acceleration test showed.

So I am collecting better historical measurements of what connects discovery to disclosure: validated findings entering disclosure programmes, time to publication, how backlogs build, and how all of that has changed as AI-assisted research has grown. I also want to find which changes improve accuracy when tested against information that was genuinely available at the forecast date. The difference between retrospective explanation and prospective prediction is now central to how I run this work.

For now I have a tested conventional baseline, several rejected alternatives, a more detailed hypothesis about the disclosure process, and a forecast that can be checked in two days. I will report how the October prediction performs in November and continue refining this method.

Research methodology and disclosure

Research assistance: I used a frontier large language model to assist with parts of the data analysis, statistical calculations and exploration of alternative mathematical formulations. The hypotheses, interpretation of results and conclusions remain mine.

Primary dataset: CRACI CVE Publication Trends, derived from the CVE Program’s public records. The series begins in January 2020. Records are counted by publication date and rejected records are excluded.

Statistical implementation: Historical Theta forecasts used Python statsmodels 0.14.6, with ThetaModel, a 12-month period and seasonal adjustment disabled. Each forecast used only observations before the stated cutoff. The source archive is a retrospective snapshot, so historical results may be affected by later record revisions.

Accuracy measurement: Absolute percentage error for single forecasts, mean absolute percentage error for annual comparisons, and weighted absolute percentage error for pooled quarterly results.

Forecast freeze: The forecasts in this paper were recorded on 30 October 2026 using the CRACI snapshot covering records through 28 October. The first completed-October evaluation is planned for the first week of November 2026. The forecast table stays unchanged, and later evaluations will be added with their dates.

References

CVE Program: kernel.org added as a CNA, February 2024 · FIRST: Mid-Year Vulnerability Forecast, June 2026 · METR: Task-Completion Time Horizons · SANS: AI in Cybersecurity, 2026 · GitHub: Inside the Advisory Database · Microsoft: Three Lessons from Frontier AI Vulnerability Research · Anthropic: Coordinated Vulnerability Disclosure Dashboard · CyberHire: AI-Attributed CVE Discovery Data · BlackTree: Historical CVE and KEV Statistics · Vulnpocalypse 2026: CNA Publication Comparison · CISA: Known Exploited Vulnerabilities Catalogue

Index of acronyms