AI Changed the Exposure Problem. Validation Needs to Change With It.

The core security problem of 2026 is not that AI writes better exploits. It is that vulnerability discovery has scaled far past any organisation's ability to act on the results.

In the first half of 2026, 35,853 CVEs were published — roughly 49 percent more than the same period a year earlier. Of those, 495 were catalogued as exploited in the wild. And 116 were already under attack on the day they became public.

That last number is the one that reframes everything.

The Discovery Gap

Anthropic's own coordinated disclosure ledger illustrates the scale shift. Mythos-class models surfaced 26,153 vulnerability candidates in open-source software. Only 421 of those got patched upstream.

Read that ratio carefully, because it cuts both ways. It shows AI finding vulnerabilities at a rate no human research team could match. It also shows that the overwhelming majority of what gets found never turns into a fix — because the finding is not reproducible, not reachable, not worth the maintainer's time, or simply lost in the volume.

Discovery has been automated. Triage, patching and remediation have not.

Why Severity Scores Stopped Working

The practical consequence is that treating every High or Critical CVSS rating as an emergency is not just impossible — it is the wrong model entirely.

The same CVE can affect hundreds of assets in one environment, and the impact is rarely identical across them. Some instances are unreachable from anywhere an attacker could stand. Some sit behind controls that break the specific technique required for exploitation. Others sit on business-critical systems where prevention fails and detection never fires.

CVSS gives a common severity baseline. It cannot give you the context that determines what a vulnerability actually means inside your organisation.

With 495 exploited out of nearly 36,000 published, the question defenders need answered is not how bad a vulnerability is in the abstract. It is which exposures, on which assets, require action now.

The Limits of Automated Pentesting

Automated and agentic pentesting is the strongest evidence most teams can gather. It runs real exploits, proves exploitability in your specific environment, chains vulnerabilities and misconfigurations into attack paths, and shows how far an attacker could progress.

Coverage is the problem. Omdia research found that while 95 percent of organisations rank pentesting as a top or high priority, only 32 percent of the average attack surface gets tested in a year.

There are also structural constraints that more automation does not remove. Running a live exploit requires that a working exploit exists — which rules out newly disclosed CVEs during exactly the window when they are most dangerous. It also requires that the target is safe to test, which rules out a great deal of production, restricted and air-gapped infrastructure.

Those exposures still need an exploitability verdict. There is just nothing an automated pentest can safely run against them.

The Three-Part Argument

The framework being proposed splits validation into three functions that answer different questions under different conditions.

Exploitability validation determines whether an exposure is exploitable in your environment, including CVEs with no working exploit yet and assets live testing cannot safely reach.

Security control validation tests whether your prevention and detection controls actually block, catch, or miss a given attack.

Agentic pentesting safely runs real exploits and chains exposures to show how far an attacker progresses through your specific environment.

The argument is not that every exposure needs all three. It is that each method fits different circumstances, and that the evidence from all three should feed one decision process rather than three disconnected workflows.

The operational benefit claimed is continuity: a finding triggers whichever validation step it actually needs, new evidence changes remediation priority, and fixes get re-validated instead of vanishing into a closed ticket.

Gartner's May research note points in a similar direction — validated attack paths, decision-driven response, and exposure reduction integrated into operational workflows.

Where This Comes From

Worth being clear about the source. The piece is a contributed article written by Sila Ozeren Hacioglu, Security Research Engineer at Picus Security, and it maps the three validation capabilities directly onto three Picus product lines.

That does not make the data wrong. The CVE counts, the exploitation figures and the Omdia coverage research are independently sourced and independently checkable. It does mean the three-part framework is a product architecture as much as a methodology, and readers should evaluate it on that basis.

The vendor is running a Validation Summit on October 14 and 15, with Mikko Hyppönen opening, Picus CTO Volkan Ertürk on validation under AI-powered attacks, a live walkthrough of a newly disclosed vulnerability from pre-patch through re-validation, and security leaders from Chanel, Atlassian and the NFL discussing implementation.

The Part That Holds Regardless

Strip out the product mapping and a defensible argument remains.

Vulnerability volume is growing roughly 50 percent year on year while the exploited subset stays small. The window between disclosure and exploitation is narrowing, with a meaningful fraction of CVEs attacked on day zero of public knowledge. Severity scores cannot distinguish between an exposure on an unreachable test box and the same exposure on a payment system.

The organisations that handle this well over the next two years will not be the ones patching fastest. They will be the ones that can answer, with evidence from their own environment, which of the 36,000 findings actually matter to them.