CVE increase in 2026 contrasts with limited real holdings

In the first six months of 2026 the risk area has moved faster than ever: 35,853 CVE, a declared increase of 49% over the same period of the previous year, was made public; however, of all these entries only 495 were listed as exploited in nature and 116 were under attack on the same day of its publication. These numbers - taken from the aggregate data from vulnerability divulges - show a key tension that many organizations still do not manage well: the volume of findings grows at a speed that traditional response practices cannot follow, but most vulnerabilities never become exploited in the real world. The operational question is no longer how many vulnerabilities there are, but which of them are exploitable and are worth the cost of immediate intervention in your environment.

In addition to CVE avalanche, IA models aimed at code detection and analysis have accelerated the identification of possible failures. According to Anthropic's own disclosures, models of the Mythos family generated 26,153 vulnerable candidates in open source projects, of which only 421 were parched in the upstream repositories. This relationship between "findings" and "applied patches" highlights another technical reality: automatic detectors produce a lot of noise that needs to be filtered by contextual evidence to decide on action. These figures confirm two facts: the scale discovery and actual corrections remain relatively few.

It is important to separate the confirmed from the estimated. Confirmed: the increase in the volume of CVE and the observed relationship between published findings and exploits. Estimated: that the gap between dissemination and exploitation will continue to narrow as more automated tools and generative models facilitate the development of concept and exploits tests. Uncertainty: to what extent this acceleration will affect specific sectors or specific vectors in the next 12 months; this will depend on the pace of adoption of these models and the public availability of explosives.

From a technical point of view, the problem lies in the distinction between severity and exploitation. The CVSS score gives a reference to gravity, but does not incorporate operational context: it does not consider whether the vulnerable service is exposed, whether the network segments it, whether there are controls that break the operating chain or whether the asset in question is essential to the business. The same CVE can affect hundreds of instances within a company and its actual impact will vary according to the configuration, privileges and controls around each instance.

Therefore, the approach that gains traction between mature security equipment combines three complementary validation types. First, the validation of the operation, which responds if vulnerability can really be abused in your environment: it includes static / dynamic analysis, testing in safe environments and verdicts when there is not yet a public explosion. Second, the validation of safety controls which proves whether the current defenses (WAFs, EDR, IPS, segmentation, access policies) block, detect or fail in the face of an attempt to exploit. Third, agentated or automated pentesting, which links vulnerabilities, credentials and bad configurations to demonstrate real attack routes and how far an attacker can go.

Each one provides different evidence: the automated pentest is the most conclusive when it can run real exploits, because it shows practical impact; the validation of controls shows whether defensive investments work; and the exploitability covers gaps where it is not safe to run offensive code in production or there is still no public explosion. None on its own closes the problem: for example, pentest cannot test air-gapped systems or critical production applications that do not support destructive tests; validation of controls requires well-modeled scenarios; and exploitation without network verification can remain in conjectures.

What does this mean for the teams and for you as a technical manager? First: to adopt a priority based on real impact, not only on the severity of the EQO. This requires a precise inventory of assets, exposure mapping (which services are public- facing), and knowledge of service criticality for business. Second: enrich the vulnerable workflows with internal evidence. It is not enough to mark a ticket as "High" and wait; a label has to be added to collect if the vulnerability was validated as exploitable, if the controls detect it and what attack routes it allows. Third: integrate systematic revalidation: after applying patches or mitigations, revalidate to avoid closed tickets without actual check.

In practice, this implies concrete operational changes. Reinforce asset inventory and network visibility; enable secure credentials for authenticated scanning; create isolated test environments to run exploits when necessary; apply microsegmentation techniques to limit laterality and reduce "exploitable surface" even if a failure exists. Ensure that your detection tools (EDR / IDS / SIEM) are configured to generate actionable signals and that there is a playbook that translates exploitative evidence into priority remediation orders. If a CVE cannot be tested in production, it requires exploitative reports based on code analysis and replicated tests in safe environments before deciding not to patch.

There is also a governance dimension: not all findings deserve the same chain of command. It defines thresholds that activate urgent response (e.g., assets exposed in production without mitigation, explosion evidence in the wild) and delegates low priority remediations to regular parking cycles. It automates the reallocation of priorities when new evidence appears: if a low priority vulnerability is shown to be exploitable against critical systems, it automatically goes up to emergency and fires appropriate communications.

Practical limitations and residual risks must be accepted: there will not always be an explosion available to test and, in many cases, to test exploits in production is illegal or dangerous. In addition, the incorporation of automated pentesting agents and agentiva models poses risks of false positive and need for human monitoring. The implementation of these practices therefore requires skills in safety analysis, evidence infrastructure and clear processes to coordinate development, operations and security teams.

Finally, some useful references for those who want to deepen: the CVE repository and the vulnerability databases keep the formal disclosure record ( MITRE CVE and NVD - NIST), and the providers specialized in validation and simulation offer platforms to combine the three above-mentioned capabilities (e.g., suppliers such as Picus describe "security validation" models that integrate validation of controls and penalizing; see Picus Security).

In short, the emergency is not in the CVE number but in the ability of each organization to filter and validate which vulnerabilities are actually exploitable and dangerous to its critical assets. Prioritize according to evidence of the exploitation and effectiveness of controls, automate the re- prioritisation when the evidence changes and revalidate after correcting, is the practical route not to be lost in the tide of findings and to concentrate resources where they really matter.