The July 2026 Patch Tuesday will go down in the record books: 622 vulnerabilities patched by Microsoft in a single monthly release. A month earlier, June had already set a record with 206. July tripled that number.

Key points

  • The problem is not the volume of vulnerabilities, but the collapse of the reaction window.
  • Only a small minority of vulnerabilities are ever actually exploited: those are the ones that matter.
  • Less than 72 hours can separate a patch release from mass exploitation.
  • A quarterly update cycle mathematically leaves weeks of exposure.

What happened in July 2026?

Microsoft patched 622 vulnerabilities in a single release, including 59 rated critical and three flaws disclosed publicly before patches were available. Two were being actively exploited, including a SharePoint Server privilege escalation flaw that was immediately added to CISA’s Known Exploited Vulnerabilities catalog.

This is not a statistical anomaly, it is an underlying trend. Vulnerability discovery is industrializing, driven in part by AI-assisted analysis tools used by researchers and attackers alike.

While Microsoft was releasing its 622 patches, the rest of the month kept the same pace: the critical wp2shell flaw in WordPress on July 17, exploited at scale within 72 hours; Fortinet and Arista vulnerabilities added to the KEV catalog on July 27; a hardcoded password in Cisco Secure Firewall Management Center on July 29; then the N-able N-central flaw on August 3.

For a business owner, the conclusion is unavoidable: the ad hoc approach to patching, “we’ll patch when we have time,” is no longer mathematically defensible.

Is volume really the problem?

No, and that is the costliest misunderstanding. No one, not even large enterprises, patches 622 flaws in a week. The real issue lies in two numbers: the fraction that is genuinely dangerous, and the speed at which it becomes exploitable.

1. The genuinely dangerous fraction. Of the hundreds of vulnerabilities published every month, only a small minority will ever be exploited. CISA’s KEV catalog, which tracks flaws with confirmed active exploitation, lists a few hundred in total, against more than 40,000 published annually. The useful work, then, is not fixing everything, but identifying and acting quickly on what matters.

2. The speed of exploitation. This is where things have gotten worse. The wp2shell episode proved it: less than 72 hours between the patch release and mass exploitation, public exploit code included. For the N-central flaw, CISA cut the remediation deadline imposed on federal agencies to three days, a clear signal of the pace now expected.

An organization that applies updates quarterly is therefore exposed, on average, for several weeks per critical flaw. Multiply that by the number of critical flaws released each year, and the result is near-constant exposure.

The strategic question, then, is not “have we applied all the updates?” but “how long does an actively exploited flaw stay open in our environment, and do we know?”

What does “managing vulnerabilities” actually mean?

A continuous five-step cycle, not simply turning on automatic updates. Take inventory of what you own, detect, prioritize by actual risk rather than by score, remediate within defined timelines, then verify and report.

1. Take inventory. You cannot protect what you don’t know you have. Workstations and servers, of course, but also network equipment, websites and applications, cloud services, connected printers, forgotten test environments. Discovering unknown assets is the first outcome of any serious exercise, and often the most uncomfortable.

2. Detect. Regular scans, at minimum monthly and ideally continuous, across both your internet-facing perimeter and internal network, supplemented by monitoring advisories relevant to your technologies.

3. Prioritize by risk, not by score. This is the step that separates effective programs from cosmetic ones. Three criteria combine: is the flaw actively exploited, is the asset exposed to the internet, is the asset critical to the business. A medium-severity flaw on your exposed remote access system outweighs a critical flaw on an isolated workstation.

4. Remediate within defined timelines. Realistic targets for an SMB: actively exploited flaws on exposed assets, 72 hours; critical flaws, 7 to 14 days; high-severity flaws, 30 days. What matters is not perfect numbers but their existence: a defined deadline can be measured, audited, and defended.

5. Verify and report. Confirm that the patch was actually applied (silent failures are common), then produce a simple indicator for management: number of open critical flaws, average age, trend.

Why has this become a governance issue?

Because three external forces are converging to turn it into a measurable business requirement: regulation, insurers, and your own clients. None of the three is satisfied by good intentions.

Regulation. Law 25 requires reasonable security measures proportionate to the sensitivity of the personal information involved. In the event of an incident, a known flaw, patchable for months yet still open, is exactly the kind of fact that turns a victim company into a negligent one in the eyes of the Commission d’accès à l’information (Quebec’s access-to-information authority).

Insurers. Cyber insurance questionnaires now routinely ask about patch deployment timelines and the management of end-of-life systems. An inaccurate answer can jeopardize coverage at the exact moment you need it.

Your clients. Large Quebec organizations pass their own obligations down to their suppliers: questionnaires, contractual requirements, audit evidence. An SMB unable to describe its process gradually loses access to major clients. The ISO 27001 standard makes this an explicit control, as does the NIST framework.

What are the two traps to avoid?

Believing automatic updates are enough, and believing your IT provider already handles it. Both are comfortable assumptions, and both leave blind spots exactly where attackers are looking.

“Automatic updates are enough.” They cover part of the environment, operating systems and browsers, but leave major blind spots: network equipment and remote access systems, the favorite entry points of ransomware groups, business applications, websites, systems that never reboot. And they sometimes fail silently.

“Our provider handles it.” Perhaps, but under what commitments? If your managed services contract specifies no remediation deadlines, no defined scope, and no reporting, you don’t have a vulnerability management program, you have an expectation. Recent incidents involving remote administration tools are also a reminder that the provider itself is part of your attack surface.

How does RISS structure a proportionate program?

In four components, from the initial assessment to an executive dashboard, without the overhead of an enterprise-scale system. The goal is a documented, defensible process, not another tool.

Initial attack surface assessment. Inventory of your internet-facing assets and a full internal and external scan: a factual snapshot, including forgotten systems and end-of-life versions.

Setting up the cycle. Prioritization based on actual exploitation and asset criticality, realistic remediation deadlines, integration with your internal team or provider, whom we also help hold to contractual commitments.

Validation through penetration testing. Scanning detects; testing proves. Our tests, aligned with the OWASP and NIST SP 800-115 frameworks, confirm whether residual flaws are actually exploitable in your environment.

Executive reporting. A quarterly dashboard in business terms: current exposure, trend, comparison against commitments. Enough to answer an insurer, a client, or an auditor with confidence.

FAQ

We don’t have a team to keep up with monthly scans. What should we do?

Start with the internet-facing perimeter, which is both the smallest and the most dangerous. A monthly external scan of your public addresses and websites takes about half a day to analyze, and it covers the vectors automated attackers actually use. The internal network can wait until the following quarter: what matters is a sustained rhythm, not an ambitious program that gets abandoned.

How do we know which flaws are actively exploited?

CISA’s Known Exploited Vulnerabilities catalog is the free, public reference. It only lists flaws with confirmed exploitation, which makes it the best available filter for judging urgency. The EPSS score, which estimates the probability of exploitation, is a useful complement. A high CVSS score alone says nothing about actual urgency.

Should an end-of-life system be patched or replaced?

If the vendor no longer issues patches, patching is no longer an option: you either replace the system or isolate it. Isolation is a legitimate response and often the only realistic one in the short term, particularly for industrial equipment or a business application with no successor. What is not defensible is leaving an unmaintained system accessible from the internet or from the general office network.

Sources