A record Patch Tuesday: 570 flaws and 3 zero-days

July 2026’s Patch Tuesday went into the record books as the largest in Microsoft’s history: 570 vulnerabilities fixed, including three zero-days — two actively exploited in attacks and one publicly disclosed before a patch existed. For comparison, a typical month brings one to two hundred bugs. July was a multiple of that.

Before the conclusions, one clarification about the numbers, because two different figures circulated in the media. Some sources reported 622 CVEs — that broader figure also includes fixes for the Chromium-based Edge browser, which ship on a separate schedule tied to Google’s releases. The number referring to Patch Tuesday itself and Microsoft’s products is 570. We’ll use that below.

This post isn’t a CVE list — the vendor publishes those and they stay current for about a week. It answers the question teams actually face: how do you approach 570 fixes when your maintenance window covers 40 of them?

Why the number alone is misleading

The “all-time record” headline triggers a panic reflex, and panic is a poor adviser in patching. Three things are worth settling straight away.

A rising CVE count doesn’t directly mean rising risk. Growing statistics are driven by many factors unrelated to code quality: broader bug bounty programmes, more automated bug-finding tooling (including AI-based), a wider product portfolio, and changes in what the vendor classifies as a separate CVE at all. More bugs found is also a signal that more people are looking.

The severity distribution is heavily skewed. Of 570 vulnerabilities, the vast majority require local access, user interaction, or produce limited impact. July’s batch was dominated by elevation of privilege (about 41%), remote code execution (about 27%) and information disclosure (about 18%). Genuinely urgent items number in the dozens, not the hundreds.

Risk concentrates in a handful of items. The three zero-days weigh more than the other 567 combined — because for them confirmed exploitation or public code exists, the condition under which attack probability stops being theoretical.

Three zero-days — why they set the priority

Distinguishing zero-day types has operational consequences, so let’s name them precisely:

Type	What it means	Priority
Actively exploited (2 items)	Confirmed attacks against real targets	Highest — patch immediately
Publicly disclosed (1 item)	Technical details public before the patch	High — exploits usually appear within days
Everything else	No evidence of exploitation	Standard cycle

Active exploitation is the strongest signal a defender can get. It means we’re no longer weighing a hypothetical — someone is doing this, and scanning the internet for vulnerable systems is automated and cheap. That’s why presence in the CISA KEV catalogue should outrank the CVSS score in your decision process. We expand on that principle in how to prioritise critical vulnerabilities.

Public disclosure before a patch is an intermediate but underrated category. Once technical details are public, the path from analysis to a working exploit can be very short — we saw it with the Adobe ColdFusion flaw, where attacks began within hours of a write-up being published.

Triage: how to approach 570 fixes

Below is the practical order we use with large update batches. The overarching rule: we don’t patch “everything”, we patch the right things in the right order.

Step 1: Start with what’s visible from the internet

Publicly reachable systems have the shortest time from disclosure to attempted attack, because scanners sweep the internet continuously. Mail servers, portals, VPN gateways, application servers, anything with a public address — that’s the first wave, regardless of what the rest of the list looks like.

The precondition is knowing what is visible at all. If you don’t have a current exposure map, start there — that’s the role of external attack surface management (EASM). Surprisingly often the biggest finding isn’t an unpatched server but a server nobody knew about.

Step 2: Apply the active-exploitation filter

From the full list, extract items present in the CISA KEV catalogue plus anything the vendor flagged as exploited or publicly disclosed. That typically reduces five hundred items to a couple of dozen. That list is your top priority after edge systems.

Step 3: Match vulnerabilities against your actual architecture

This is where most items drop out — and where most mistakes happen. Ask three questions of every critical flaw:

Do we even have this component? A server role you never installed isn’t your problem.
Are the exploitation preconditions met here? Many CVEs require a specific configuration — a feature enabled, a particular authentication mode, local access.
What does the attacker achieve by exploiting it? Privilege escalation on an isolated test machine is a different matter from the same flaw on a domain controller.

The last point deserves expansion. Elevation of privilege flaws — the largest category in July’s batch — tend to be dismissed (“the attacker must already be on the system”). That’s a mistake. In a typical attack chain the attacker is already on the system: they arrived via phishing or stolen credentials, and all they lack is the privilege to move further. A privilege-escalation flaw is precisely that missing piece. Certighost in AD CS illustrates it perfectly, where an ordinary domain account led to full domain takeover.

Step 4: Patch in waves, not in one strike

A proven sequence:

Wave 0 (within 48 hours): internet-facing systems with actively exploited flaws.
Wave 1 (within 7 days): domain controllers, identity servers, management systems — anything whose compromise produces a mass effect.
Wave 2 (within 14 days): remaining servers and workstations, ideally automatically via your update distribution system.
Wave 3 (next cycle): low-risk systems, test environments, hardware requiring long maintenance windows.

A note on testing order: with a batch this size, regression risk rises. That doesn’t mean wave 0 can wait “until we’ve tested”. A sensible compromise is parallelism: wave 0 goes to production after an abbreviated smoke test, while the broad remainder goes through the normal validation cycle.

Step 5: Verify the patch actually took effect

The most common failure here is calling the job done when the update is pushed. Check three things: that the fix is installed, that the system was restarted (many kernel and library patches only take effect after a reboot), and that the version number on the host matches. Report state from a central management system, not from a survey of administrators. That cycle — inventory, deploy, confirm — is the heart of vulnerability management.

Five mistakes that cost the most

With large update batches the same errors recur in most organisations. They’re worth naming, because each has a simple counter.

Patching by CVSS score instead of exposure. Sorting the list descending by score looks rational, but leads to patching a 9.8 on an internal test server before addressing a 7.5 on an internet-facing gateway. Order should follow exposure × evidence of exploitation × system criticality, not a single number.

Skipping reboots. A patch installed but not applied shows up in reports as a success while providing no protection. For kernel components and system libraries, the reboot is part of the deployment, not an optional extra. Report state after reboot, not after install.

Forgetting systems outside the cycle. The biggest backlogs rarely sit on workstations covered by automatic distribution. They sit in edge appliances, virtual machines powered off at deployment time, systems in isolated segments and hardware “that must not be restarted”. Each of those categories needs its own path, or it drops out of the process permanently.

Treating testing as an excuse. Testing before deployment is correct practice, but with actively exploited flaws it becomes an excuse if it means delays measured in weeks. The answer is separation: an abbreviated path for wave 0, a full validation cycle for the rest.

Not closing the loop. Deployment without verification isn’t a process, it’s an intention. Whenever a report says “100% compliant”, spot-check a few hosts with an independent tool. Divergence between report and reality is the rule, not the exception.

The smaller organisation’s perspective

If you don’t have a security team, the process above reads like it’s from another league. In practice it reduces to four decisions you can make once and maintain:

Enable automatic updates on workstations and anywhere regression risk is acceptable. For most small businesses, the risk of an unpatched system clearly outweighs the risk of a failed update.
List what’s visible from the internet and prioritise those systems. If it’s only a website and cloud email, your attack surface is small and easy to maintain.
Follow one source on active exploitation (such as the CISA KEV catalogue) instead of reading every advisory. You care about a couple of dozen items a year, not several thousand.
Plan reboots. An installed-but-inactive patch is the most common silent gap in small environments.

We cover a wider set of priorities for smaller organisations in small business cybersecurity and security monitoring for SMEs.

Frequently asked questions (FAQ)

570 or 622 vulnerabilities — which number is right? They describe different things. 570 is the vulnerabilities in Microsoft products covered by July’s Patch Tuesday. The broader 622 added fixes for Chromium-based Edge, which ship on a separate schedule tied to Google’s releases. For operational planning use 570, but don’t forget browser updates — that’s a separate and equally important track.

Do we have to patch all 570 this month? No, and you probably can’t. What you must do is consciously decide what you’re not patching and why. The difference between a mature and immature process isn’t that everything is patched; it’s that the backlog is known, justified and has a deadline.

Why is a zero-day more dangerous than a CVSS 9.8 flaw? Because CVSS describes potential while active exploitation is a fact. A 9.8 flaw nobody has written an exploit for is less urgent than a 7.8 being used in a campaign today. Real-world exploitation data should therefore outweigh the score in your process.

What if we can’t restart a server? Treat that as a risk to manage, not a permanent state. Set a maintenance window, plan a failover, or apply a compensating control (network access restriction, a virtual patch on the WAF). Record the decision and a deadline — an unpatched system with no deadline is debt that always surfaces at the worst moment.

How do we check whether our patching process actually works? The simplest test: pick one critical vulnerability from last month and count how many systems are still vulnerable. The answer usually differs from the report. If you want external verification of what’s visible from the internet and how fast you close windows — let’s check it together.

Summary

July’s record — 570 vulnerabilities and three zero-days — is less a story about an unusually bad month and more a test of process maturity. Patch counts will keep rising: finding bugs is getting cheaper, partly thanks to automated tooling, and software portfolios keep widening. Organisations still basing patching on manual advisory review and a quarterly maintenance window will fall further behind.

The practical conclusion is simple: focus on the intersection of three sets — what’s internet-facing, what’s actively exploited, and what you actually run. That’s usually a couple of dozen items out of five hundred. Handle the rest on the normal cycle, and measure time rather than percentages. If you want to know how your organisation performs on the real time-to-close for critical windows — let’s start with attack surface reconnaissance.

Sources and further reading: Microsoft Security Update Guide, Krebs on Security, BleepingComputer, Zero Day Initiative, CISA KEV.