Key Takeaways
- Microsoft’s July 2026 Patch Tuesday fixed a record 570 vulnerabilities — nearly triple last month’s count — with 59 rated Critical, including 48 remote code execution flaws
- Three zero-days were patched, two of which are actively exploited, both in Active Directory Federation Services (ADFS) — a prime target for red teams and attackers alike
- AI-assisted vulnerability discovery is directly responsible for the flood of patches, but this means your patch management pipeline needs to accelerate or you’re exposed
- CISA has added the affected ADFS flaws to its Known Exploited Vulnerabilities catalog, giving federal agencies a hard deadline
- The traditional monthly patch cycle is dead. You need a risk-based, continuous patching strategy or you’ll drown
What the Hell Happened
When I first saw the number 570, my immediate thought was that the data feed had to be broken. Last month’s count was already high. This month nearly tripled it. This isn’t incremental growth — it’s a volcanic eruption.
Microsoft attributes this to the full-scale deployment of AI-assisted vulnerability discovery. In plain terms, they’re using large language models to chew through code paths that human researchers never had time to cover. The results are dramatic — 570 vulnerabilities, and the community suspects AI found a significant chunk of them. On Reddit’s r/SecOpsDaily thread, someone nailed it: “AI finds vulnerabilities faster than we patch them.” That stings, but it’s our new reality.
Adding to the pain, 3 of those 570 are zero-days, and 2 are already being actively exploited. Both in ADFS. If you’re running ADFS, you’re not sleeping well this week.
ADFS Flaws: Why Red Teams Love It, Blue Teams Hate It
The two exploited zero-days both live in ADFS. If you’re not familiar, ADFS is Microsoft’s identity federation gateway — it bridges on-prem Active Directory identities to Office 365, Azure AD, and a pile of SaaS apps. Essentially, ADFS is the front door to your identity boundary.
Breach the door, and everything is lost.
ADFS has always been a high-value target in red team circles for one simple reason: compromise ADFS and you hold the keys to the entire cloud identity kingdom. Attackers can forge tokens without knowing a single user’s password, impersonating anyone to access protected resources. When our team did a red team exercise last year, we spent two weeks studying ADFS signing key management and found our target customer’s ADFS server running a vulnerability publicly disclosed back in 2019 — no zero-day needed, an old bug was enough.
Community analysis suggests the exploited zero-days this time are token signing verification bypasses. An attacker can craft a malicious token that ADFS accepts as legitimate. This is far more efficient than phishing for credentials — you don’t need to trick any users, just find a way into ADFS.
CISA has added both flaws to the KEV catalog, which means federal agencies face mandatory patching timelines. Private sector isn’t directly bound by CISA, but if you have FedRAMP compliance requirements, those timelines apply to you too.
And the same day as Patch Tuesday, Ars Technica reported another zero-day dropping publicly — either attackers deliberately timed their disclosure to coincide with patch day, or a researcher’s disclosure date collided with Microsoft’s release schedule. Either way, it’s gross.
Technical Breakdown: What Those 570 Patches Actually Cover
Microsoft’s update spans a massive product surface, but a few areas deserve special attention.
Remote Code Execution (RCE) is the worst-hit category. The 48 Critical RCEs span Windows Kerberos, Hyper-V, Exchange Server, SharePoint, and more. Hyper-V RCEs are particularly nasty — if you run virtualization clusters, a host-level vulnerability means attackers can escape from VMs to the hypervisor, blowing through your isolation boundary.
Privilege Escalation (EoP) vulnerabilities are staggering in volume. Digging through the patch list, you’ll find EoP bugs scattered across the Windows kernel, Win32k, and countless system services. These are typically chained with phishing attacks — get initial foothold, then escalate privileges.
Information disclosure bugs shouldn’t be ignored either. Even though severity ratings might only say Important, these are often the early reconnaissance step in an attack chain. Attackers need to map your internal network, identify service versions, and enumerate accounts before planning the actual breach.
Here’s a quick breakdown of what this patch cycle looks like:
| Severity | Count | Typical Attack Scenario |
|---|---|---|
| Critical | 59 | Remote code execution, identity bypass, unauthenticated attacks |
| Important | ~490 | Privilege escalation, information disclosure, DoS |
| Moderate/Low | ~20 | Edge cases, low-impact exploitation |
| Zero-days | 3 | 2 actively exploited, both in ADFS |
Patch Management: You Can’t Patch 570 Flaws at Once
Here’s the problem — 570 vulnerabilities, and your patch management team has maybe a few people. How many change requests can you process in a week? If you try to deploy all 570 patches at once, your business units will riot.
I’ve seen too many enterprises default to “defer everything to the next maintenance window,” which then gets pushed back indefinitely due to business priorities. Eventually it becomes “we’ll patch when it’s convenient,” and convenient never comes.
With patch volumes like this, you need a layered response strategy:
Priority 1: The exploited zero-days. There’s zero excuse to delay those two ADFS flaws. If you run ADFS, confirm your version is affected and schedule an emergency change window. Don’t wait for monthly windows. Don’t wait for business approval. Just patch. Last year, our team did an emergency patch at a client site — from confirming impact to completing the patch took six hours, including rollback planning and verification. That timeline is acceptable.
Priority 2: Critical RCEs that need no authentication. Attackers only need to find one internet-facing interface to break through. These should be patched within 72 hours.
Priority 3: Other Critical and high-value Important. These can go into a two-week regular patch window.
Priority 4: Everything else. Handle on a monthly cadence, but keep monitoring for public exploit code.
On the operational side, PowerShell remains the core tool for Windows patch management. Here’s a script we actually use to audit which machines are missing a specific KB:
# Audit all domain machines for a specific KB patch
$kbid = "KB5040427" # Replace with actual KB number
$computers = Get-ADComputer -Filter {Enabled -eq $true} -Properties Name | Select-Object -ExpandProperty Name
$results = foreach ($computer in $computers) {
try {
$session = New-CimSession -ComputerName $computer -ErrorAction Stop
$patch = Get-CimInstance -CimSession $session -ClassName Win32_QuickFixEngineering -Filter "HotFixID='$kbid'"
if ($patch) {
[PSCustomObject]@{Computer=$computer; Patched=$true; InstalledOn=$patch.InstalledOn}
} else {
[PSCustomObject]@{Computer=$computer; Patched=$false; InstalledOn=$null}
}
Remove-CimSession $session
} catch {
[PSCustomObject]@{Computer=$computer; Patched="UNKNOWN"; InstalledOn=$null}
Write-Warning "Unable to connect to $computer : $_"
}
}
$results | Export-Csv -Path "patch_audit_$kbid.csv" -NoTypeInformation
$results | Group-Object Patched | Select-Object Name, Count
When this finishes, you get a clear picture — which machines are patched, which aren’t, and which you can’t even reach. The unreachable ones are your security liabilities, and they need individual attention.
For critical infrastructure like ADFS, I recommend a more granular verification. After patching, confirm the ADFS service starts correctly and token signing verification works as expected. Here’s a lightweight ADFS health check:
# ADFS health check
$adfsServer = "adfs.contoso.com"
# Check ADFS service status
$service = Get-Service -ComputerName $adfsServer -Name "ADFSSrv"
Write-Host "ADFS Service Status: $($service.Status)"
# Check ADFS event log for errors
$events = Get-WinEvent -ComputerName $adfsServer -LogName "AD FS/Admin" -MaxEvents 50 |
Where-Object {$_.LevelDisplayName -in @("Error", "Critical")}
if ($events) {
Write-Host "Found $($events.Count) ADFS error events:" -ForegroundColor Red
$events | Select-Object TimeCreated, Id, Message | Format-Table -Wrap
} else {
Write-Host "ADFS log clean, no errors." -ForegroundColor Green
}
# Test ADFS metadata endpoint
try {
$meta = Invoke-WebRequest -Uri "https://$adfsServer/FederationMetadata/2007-06/FederationMetadata.xml" -UseBasicParsing -TimeoutSec 10
Write-Host "ADFS metadata endpoint response: HTTP $($meta.StatusCode)" -ForegroundColor Green
} catch {
Write-Host "ADFS metadata endpoint unreachable: $_" -ForegroundColor Red
}
Run that and you’ll quickly confirm whether the ADFS patch applied cleanly and the service is healthy. But honestly — scripts are just tools. The real test is whether your change management process is fast enough and flexible enough to handle this new reality.
Why Did Patch Volume Triple This Month
The core driver behind this patch flood is AI-assisted vulnerability discovery. Microsoft has deployed large-scale AI code auditing systems that automatically scan their codebase for potential vulnerability patterns. It’s like sweeping the beach with a metal detector — previously humans only checked a few key zones, now AI can cover the whole beach.
But here’s the subtle problem. AI finds vulnerabilities faster, but what about the fix rate? Microsoft’s engineering teams are now processing three times the vulnerabilities in the same timeframe, which raises questions about patch quality. The community is already asking — how many of these patches are genuine fixes versus temporary mitigations?
The r/pwnhub thread mentioned 48 Critical RCEs in this batch alone. Forty-eight RCEs. Many SMBs don’t have 48 remotely exploitable attack surfaces across their entire IT estate. At this scale, it’s clear that Windows’ codebase has grown so massive that human-only auditing simply cannot keep up.
AI-assisted discovery is a double-edged sword. On one hand, it helps Microsoft find more flaws before attackers exploit them. On the other hand, attackers are using AI too. There was a sharp comment on Hacker News: Microsoft is now racing AI against AI, and patches are their only weapon.
The New Reality of Patch Management: From Monthly Event to Continuous Process
This 570-patch Patch Tuesday tells us a brutal truth: the traditional monthly patch model is dead.
You cannot test and deploy 570 patches in a single day. Even if you could, your business units would have you drawn and quartered. I’ve seen too many compatibility disasters at client sites — broken apps, print services dying, VPN connections failing. Every issue takes time to troubleshoot, and time is the one resource you don’t have.
What you need is a risk-based continuous patching strategy:
Step 1: Asset inventory. You can’t patch what you don’t know exists. Maintain an accurate asset list including OS versions, installed patches, and exposure surface.
Step 2: Risk scoring. Score every vulnerability based on CVSS, exploitation status, internet exposure, and whether it hits critical systems. Don’t just look at CVSS — a CVSS 9.8 that doesn’t affect your environment should rank lower than a CVSS 7.5 that directly hits your core business system.
Step 3: Automated testing. Test patches in pre-production. You don’t need a full regression suite — that’s too slow — but at least confirm core business functions aren’t visibly broken.
Step 4: Phased deployment. Patch test environments first, then edge systems, then core production. Leave observation windows between phases.
Step 5: Verification and monitoring. Patching isn’t the end. Monitor for anomalous behavior — performance degradation, service crashes, security events.
Our team maintains a patch status dashboard that aggregates all server patch states via PowerShell and ranks them by risk level. That dashboard lets management see at a glance: how many machines are still missing critical patches, and which ones are highest risk.
Here’s the core of that script:
# Aggregate patch status across all servers
$servers = Get-Content -Path "servers.txt"
$allPatches = @()
foreach ($server in $servers) {
try {
$session = New-CimSession -ComputerName $server -ErrorAction Stop
$hotfixes = Get-CimInstance -CimSession $session -ClassName Win32_QuickFixEngineering
foreach ($hf in $hotfixes) {
$allPatches += [PSCustomObject]@{
Server = $server
HotFixID = $hf.HotFixID
InstalledOn = $hf.InstalledOn
Description = $hf.Description
}
}
Remove-CimSession $session
} catch {
Write-Warning "Unable to access $server : $_"
}
}
# Compare against critical patch list
$criticalPatches = @("KB5040427", "KB5040431", "KB5039212") # Replace with actual KBs from this cycle
$missingPatches = foreach ($kb in $criticalPatches) {
$patchedServers = $allPatches | Where-Object {$_.HotFixID -eq $kb} | Select-Object -ExpandProperty Server
$unpatchedServers = $servers | Where-Object {$_ -notin $patchedServers}
if ($unpatchedServers) {
[PSCustomObject]@{
Patch = $kb
UnpatchedServers = $unpatchedServers -join ", "
Count = $unpatchedServers.Count
}
}
}
$missingPatches | Format-Table -AutoSize
When this runs, you get a clear list: which patches are missing on which machines, and how many machines are affected. With that data, you can make a much stronger case for emergency windows with your business stakeholders than “Microsoft released a bunch of patches and we should apply them.”
Patch Management Tooling Comparison
There are plenty of patch management tools out there, each with different trade-offs. Here’s my honest take based on actual usage:
| Tool | Best For | Pros | Cons | Learning Curve |
|---|---|---|---|---|
| Microsoft Intune | Cloud-first, hybrid environments | Native Azure AD integration, supports Windows Update for Business policies | Weak for traditional on-prem domains, requires cloud subscription | Medium |
| SCCM/MECM | Large enterprises, complex environments | Full-featured, supports app deployment and OS imaging | Complex setup, resource-heavy, high maintenance cost | High |
| WSUS | Small environments | Free, lightweight, gets the job done | Limited features, weak reporting, no automated testing | Low |
| Automox | Multi-cloud, distributed teams | Cloud-managed, no infrastructure needed, cross-platform | Paid, limited custom policies | Low |
| Patch My PC | Third-party app patching | Automates third-party app updates, integrates with SCCM/Intune | Additional subscription needed | Medium |
Honestly, for most SMBs, WSUS plus PowerShell scripts for patch auditing is more than enough. Don’t rush into SCCM — that thing is a configuration rabbit hole, and I’ve seen too many SCCM deployments at client sites that went sideways halfway through.
AI-Assisted Vulnerability Discovery: Impact on the Industry
This 570-patch Patch Tuesday marks the dawn of a new era — AI isn’t just assisting analysis anymore, it’s directly finding vulnerabilities. The implications for the security industry are profound.
On the positive side, AI can cover code volumes that are completely unrealistic for human auditing. Windows has tens of millions of lines of code; human auditors can only cover core modules, while AI can scan every code path around the clock. That means more vulnerabilities found before attackers exploit them, rather than discovered during incident response.
On the negative side, the patch volume explosion means heavier patching burdens for enterprises. 570 vulnerabilities — even if you only patch the 59 Critical ones, that’s a full change window. If your IT team has two or three people, that’s two weeks of full-time work.
More unsettling is that attackers are using AI too. The underground market already has AI-assisted vulnerability discovery services. Attackers can use AI to quickly analyze Microsoft’s patches, reverse-engineer vulnerability details, and develop exploit code. The window between patch release and exploit availability is shrinking dramatically — previously it might take weeks, now possibly days.
One Hacker News comment stuck with me: Microsoft’s AI can’t find vulnerabilities faster than attackers’ AI can analyze patches. Because Microsoft has to follow the full SDLC — analyze, fix, test, release — while attackers only need to find an exploitation method.
Mistakes I’ve Made and Lessons Learned
Enough theory. Let me share some real-world scars.
Mistake one: Patch compatibility disasters. Last year, we patched a Windows Server at a client site and their SQL Server cluster immediately went down. The patch updated an underlying library that conflicted with a SQL Server component. That incident cost us a weekend, and the client’s business systems were down for two full days. Since then, we have an iron rule: every patch gets validated on a test machine with core business applications before hitting production.
Mistake two: Assuming auto-update means patched. Lots of enterprises enable Windows automatic updates and assume all machines are patched. In reality, Windows Update fails in all sorts of ways — network drops, insufficient disk space, service conflicts, group policy restrictions. We found one machine that failed patch installation three months in a row while still displaying “installing updates.” If you don’t actively audit patch status, those failures are completely invisible.
Mistake three: Ignoring isolated systems. One client had an industrial control server on a completely isolated network segment with no internet connectivity. Their security team decided it didn’t need patching — attackers couldn’t reach it anyway. Then one day, a USB drive brought malware in, and the malware exploited a three-year-old RCE vulnerability. Isolation doesn’t equal security. Air-gapped systems need patch management too, just through different channels.
Practical Guidance for This Patch Cycle
If you’re currently working through these 570 patches, here’s my practical advice based on hard-won experience:
Do immediately:
- Confirm whether your ADFS version is affected — if so, schedule an emergency patch now
- Check your asset inventory and identify all internet-facing Windows systems
- Run the PowerShell audit script above to establish your current patch baseline
Within 24 hours: 4. Deploy patches for the two actively exploited zero-days 5. Cross-reference the CISA KEV catalog against your environment 6. Contact your security vendor to confirm detection rules for these exploits exist
Within a week: 7. Schedule patch windows for all Critical-severity vulnerabilities 8. Update your intrusion detection rules with new exploit signatures 9. Review your patch management process to see if it needs adjustment
Long-term: 10. Build continuous patch monitoring — don’t rely on monthly Patch Tuesday 11. Consider AI-assisted patch risk assessment tools 12. Run regular red team exercises to verify patches actually stop attacks
Conclusion: The Future of Patch Management Is Here
A 570-vulnerability Patch Tuesday isn’t an outlier — it’s the new normal. AI-assisted vulnerability discovery will keep accelerating the pace of vulnerability detection, and what you need is a patch management process that can keep up.
Stop asking “can we patch all 570 vulnerabilities” — that question is already outdated. The right question is “how do we ensure the most critical vulnerabilities get fixed in the shortest possible time.” A risk-based continuous patching strategy isn’t optional anymore. It’s mandatory.
Our team’s practice: on Patch Tuesday each month, spend two hours analyzing the vulnerability list, confirming which ones affect our environment, then creating a phased patching plan. Critical vulnerabilities get patched within 72 hours. Important ones within a week. Everything else goes into the regular monthly window. This cadence, combined with automated audit scripts, covers the vast majority of risk.
One final thought — Microsoft says AI-assisted discovery is behind the record patch count. But I keep wondering: if AI found 570 vulnerabilities, how many are still out there that AI hasn’t found yet? That number might be unknowable. What we can do is stay vigilant, keep patching, and make sure we don’t become the next case study in what happens when you don’t.
FAQ
Q1: How many of the 570 vulnerabilities are zero-days? This Patch Tuesday includes 3 zero-days, 2 of which are actively exploited, both in Active Directory Federation Services (ADFS). CISA has added both ADFS flaws to its Known Exploited Vulnerabilities (KEV) catalog, subjecting federal agencies to mandatory patching timelines.
Q2: What’s the severity distribution of this patch cycle? 59 vulnerabilities are rated Critical, approximately 490 are Important, and about 20 are Moderate or Low. The Critical bucket includes 48 remote code execution flaws spanning Hyper-V, Kerberos, Exchange Server, and other key components.
Q3: Why is this patch count nearly triple last month’s? Microsoft attributes the volume spike to full deployment of AI-assisted vulnerability discovery. AI code auditing tools can scan Windows’ massive codebase around the clock, identifying vulnerability patterns that human audits can’t realistically cover. This also reflects how both attackers and defenders are accelerating their use of AI.
Q4: How should enterprises prioritize these 570 patches? Use a risk-tiered approach: Tier 1 is the two exploited ADFS zero-days — patch immediately. Tier 2 is unauthenticated Critical RCEs — patch within 72 hours. Tier 3 is other Critical vulnerabilities — patch within a week. Tier 4 is everything else — handle on the normal monthly window while monitoring for public exploit code.
Q5: Is the traditional monthly patch model still viable? With patch volumes exploding, a pure monthly model is insufficient. Adopt a risk-based continuous patching strategy using automated tools to audit patch status, set shorter patch windows for critical vulnerabilities, and validate patches in phases before production deployment.
References & Community Insights
Here are the key resources and community discussions that provide deeper context on this record-breaking patch cycle:
- Krebs on Security - Microsoft Patches a Record 570 Security Flaws — Original reporting with detailed vulnerability breakdown and affected product list
- Hacker News Discussion Thread — 208 points, 122 comments of deep community debate on AI-assisted vulnerability discovery pros/cons and patch management strategy
- Ars Technica - Windows 0-day drops the same day Microsoft releases record number of patches — Coverage of a new zero-day going public on patch day
- Reddit r/SecOpsDaily Discussion — Real SecOps practitioners discussing patch management pressure and response strategies
- Reddit r/pwnhub Discussion — Technical details on the ADFS zero-days and exploitation scenarios
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "How many of the 570 vulnerabilities are zero-days?",
"acceptedAnswer": {
"@type": "Answer",
"text": "This Patch Tuesday includes 3 zero-days, 2 of which are actively exploited, both in Active Directory Federation Services (ADFS). CISA has added both ADFS flaws to its Known Exploited Vulnerabilities (KEV) catalog, subjecting federal agencies to mandatory patching timelines."
}
}, {
"@type": "Question",
"name": "What's the severity distribution of this patch cycle?",
"acceptedAnswer": {
"@type": "Answer",
"text": "59 vulnerabilities are rated Critical, approximately 490 are Important, and about 20 are Moderate or Low. The Critical bucket includes 48 remote code execution flaws spanning Hyper-V, Kerberos, Exchange Server, and other key components."
}
}, {
"@type": "Question",
"name": "Why is this patch count nearly triple last month's?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Microsoft attributes the volume spike to full deployment of AI-assisted vulnerability discovery. AI code auditing tools can scan Windows' massive codebase around the clock, identifying vulnerability patterns that human audits can't realistically cover. This also reflects how both attackers and defenders are accelerating their use of AI."
}
}, {
"@type": "Question",
"name": "How should enterprises prioritize these 570 patches?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Use a risk-tiered approach: Tier 1 is the two exploited ADFS zero-days — patch immediately. Tier 2 is unauthenticated Critical RCEs — patch within 72 hours. Tier 3 is other Critical vulnerabilities — patch within a week. Tier 4 is everything else — handle on the normal monthly window while monitoring for public exploit code."
}
}, {
"@type": "Question",
"name": "Is the traditional monthly patch model still viable?",
"acceptedAnswer": {
"@type": "Answer",
"text": "With patch volumes exploding, a pure monthly model is insufficient. Adopt a risk-based continuous patching strategy using automated tools to audit patch status, set shorter patch windows for critical vulnerabilities, and validate patches in phases before production deployment."
}
}]
}
</script>
