The Vulnerability Backlog Doubled. The Exploited Set Didn’t. ‘Patch Faster’ Is the Wrong Answer.
Rapid7 counted 8,539 new high- and critical-severity vulnerabilities in the second quarter of 2026, twice the 4,268 recorded a year earlier. The number newly observed in exploitation did not double. It held close to 40.
That gap is the most useful finding in Rapid7’s Q2 2026 Quarterly Threat Landscape Report. It shows why a larger vulnerability backlog does not automatically justify a larger version of the same patching process.
The wrong response is to tell already saturated teams to patch everything faster. The better response is to identify the small set of weaknesses that combine attacker activity, external reachability, missing authentication, valuable assets and a credible path to impact.
Volume is a workload problem. Exposure is a security problem.
The disclosure curve and the exploitation curve separated
Rapid7 limited its headline comparison to vulnerabilities with CVSS scores from 7.0 to 10.0. That group grew from 4,268 disclosures in Q2 2025 to 8,539 in Q2 2026, an increase of about 100 per cent.
Newly exploited vulnerabilities increased by 8 per cent to 40. The exploited set therefore remained tiny compared with the disclosure set, even as the number of serious disclosures doubled.
This does not mean the other vulnerabilities are harmless. Some will be exploited later, some will matter only in particular configurations, and some can be chained with other weaknesses. It means that disclosure count alone is a poor ordering mechanism for urgent work.
Every high score can create a ticket. Only a subset creates a practical attack path in a particular organisation.
That distinction matters because many patch programmes still inherit priority from a severity field and a calendar. A critical item receives a short service-level target, a high item receives a longer one, and the queue grows until testing, maintenance windows and application ownership catch up.
When the input doubles, the model does not become twice as secure. It becomes twice as noisy.
Twenty-five vulnerabilities required no victim
The size of the exploited set was relatively stable, but its composition was hostile to slow decision-making.
Rapid7 says 25 of the 40 newly exploited vulnerabilities, or 62 per cent, were remotely exploitable without authentication or user interaction. The report calls these “holy grail” vulnerabilities because an attacker does not need a stolen account, a phishing click or an established foothold before attempting them.
The share was 53 per cent in Q2 2025. The increase matters more operationally than the raw count because it concentrates risk in systems that can be reached and attacked directly.
The broader disclosure pool moved in the same direction. Missing-authentication weaknesses classified as CWE-306 increased from 45 to 156 year over year, a rise of 247 per cent. Public proof-of-concept availability rose 12 per cent from the previous quarter and 76 per cent from Q2 2025.
These are different measurements. A proof of concept is not proof of criminal exploitation, and a missing-authentication weakness is not automatically internet-accessible. Together, however, they describe a growing supply of flaws that are easier to test, adapt and use against reachable services.
A score cannot tell you whether the attacker has a path
CVSS is useful for describing technical severity. It does not know whether the affected service is exposed to the internet, whether a vulnerable feature is enabled, whether a compensating control blocks the route, or whether the system holds a privileged identity and a path into production.
That missing context is why two identical software findings can deserve very different response times.
A vulnerable component on an isolated test host with no sensitive data may be a controlled maintenance task. The same component on a public management interface, connected to privileged credentials and an operational network, may require immediate isolation before a patch has completed testing.
The ticket needs more than a score. It needs an attack-path decision.
At minimum, teams should add five questions to urgent vulnerability triage:
- Is exploitation confirmed or strongly evidenced? Use vendor advisories, CISA’s Known Exploited Vulnerabilities catalogue, credible incident-response reporting and internal detection data.
- Can an attacker reach the vulnerable function? Confirm internet exposure, network paths, enabled features, cloud security rules, reverse proxies and third-party access.
- Does exploitation require an account or a person? No-authentication and no-interaction paths should move ahead of flaws that require a highly privileged local position.
- What can the affected asset reach? Include identities, management planes, data stores, hypervisors, backup systems and trust relationships.
- Is there a reliable mitigation while the patch is tested? Disabling a feature, restricting ingress, removing public exposure or placing a control in front of the service can reduce immediate risk.
The answers can justify both acceleration and deferral. A defensible vulnerability programme must be able to do both.
“Patch faster” hides the ownership problem
Most patch delays are not caused by an administrator refusing to click an update button. They come from incomplete asset inventories, unclear service ownership, fragile applications, unavailable test environments, vendor dependencies and maintenance windows tied to business operations.
An instruction to patch faster does not resolve those conditions. It transfers risk to the team performing the change and leaves the prioritisation question unanswered.
The Q2 figures support a different operating model:
- Maintain continuous visibility of software and public services instead of reconstructing the inventory after a disclosure.
- Assign owners before an emergency and give them tested isolation and rollback procedures.
- Route exploited, externally reachable and unauthenticated weaknesses into a separate emergency workflow.
- Use network controls and feature disablement when immediate patching would create unacceptable operational risk.
- Re-scan or otherwise validate the running service after remediation. A closed ticket is not evidence that the vulnerable process changed.
- Preserve a time-limited exception record for findings that remain exposed, including the compensating control and accountable owner.
This is not an argument against patching. Patching removes vulnerable code and remains the preferred durable fix. It is an argument against treating every disclosure as if it creates the same attack opportunity.
Measure exposure half-life, not ticket throughput
Patch programmes often report how many findings were closed and what percentage met a severity-based service target. Those measures can improve while the most dangerous route remains open.
A better executive view asks how long exploitable exposure survives.
Useful measures include:
- time from credible exploitation evidence to an exposure decision;
- time to isolate an internet-facing vulnerable service;
- percentage of known-exploited findings with a verified owner;
- percentage of public services requiring neither authentication nor user interaction;
- time from patch deployment to technical validation; and
- age of exceptions that still present a reachable attack path.
These measures reward the removal of opportunity, not the movement of tickets.
Keep the limits of the report visible
Rapid7’s report combines its vulnerability intelligence, managed detection and response work, and threat-research telemetry. It is a substantial data source, but it is not a census of every vulnerability or intrusion worldwide.
Rapid7 also links the disclosure surge and faster weaponisation to automation and AI-assisted tooling. That is a plausible and important assessment. The public figures do not by themselves prove how much of the increase was caused by AI rather than changes in research capacity, disclosure practice, software production or data coverage.
The operational conclusion does not require a precise attribution.
Serious disclosure volume doubled. The newly exploited set remained close to 40. Most of that set needed no user action or authentication. Public exploit material grew quickly.
The queue is not the risk model. The reachable path is.
