If you only get to fix five things from July, fix these five.
Three are in CISA KEV. One was exploited before a patch existed. One scores higher than all of them and has no exploit at all, which is the reason this list isn’t ordered by CVSS. They run in order of exploitation evidence: what was attacked before a fix existed, then how long each has been confirmed in use, then what hasn’t been attacked at all.
Each one is tracked on Strobes Vulnerability Intelligence with live EPSS and KEV state.
CVE-2026-56155 is an elevation of privilege flaw in Active Directory Federation Services, CVSS 7.8, exploited in the wild before a patch existed. Root cause is insufficient access-control granularity. It needs local access and low privileges to start, which is why it scores 7.8 instead of higher.
Credit went to Microsoft’s Detection and Response Team. That line matters more than the score. DART does incident response. A DART-credited zero-day wasn’t found in a lab or submitted through a bounty program, it was pulled out of a real compromise.
AD FS is the worst place to have a privilege escalation bug. It’s the identity broker between your on-premises directory and every federated application behind it. ZDI’s read is that it’s exactly what attackers pivot through once inside, and that it pairs naturally with an RCE, which is the standard two-stage pattern in ransomware intrusions.
AD FS also picked up more than ten other fixes in the same release, mostly denial of service. If MDASH is now grinding through AD FS, expect more, and expect some to matter more than their scores suggest.
CVE-2026-45659 is authenticated deserialization RCE in SharePoint Server, CVSS 8.8, and it needs only Site Member permissions. Microsoft shipped the fix in May 2026. No admin rights, no elevated privileges, just the level of access most SharePoint deployments hand out without thinking.
CISA added it to KEV on July 1 with a July 4 federal remediation deadline. Microsoft’s advisory had tagged it “Exploitation Less Likely.”
That’s the first of two vendor exploitability labels in this post that didn’t survive contact with reality. Vendor exploitability fields are forecasts published before anyone attacks the bug. KEV is a measurement taken after. Triaging on the forecast means patching against a prediction that was already six weeks stale.
On attribution: Microsoft has separately described SharePoint intrusions involving Storm-2603 and Warlock ransomware, and it’s tempting to connect that here. Don’t. As of reporting it isn’t publicly known who is exploiting 45659 or what they want. Exploitation is confirmed. The actor isn’t.
The operational lesson is patch lag. A fix existed for roughly six weeks before exploitation was confirmed, which is a normal enterprise patch cycle. Whether you got hit came down to where in that cycle you happened to sit. That’s the argument for risk-based vulnerability management over calendar-driven patching.
CVE-2026-58644 is unauthenticated deserialization RCE in SharePoint Server, CVSS 9.8, with no credentials and no user interaction required. It has a twin, CVE-2026-50522, next on this list: same product, same score, same root cause. ZDI covered both in a single entry because there’s no operational difference between them. CISA listed this one on July 16, six days before the twin.
Both ship in the same July update, so patching once closes both. The reason it’s worth naming separately is what it tells you about the product. SharePoint deserialization produced exploited RCE in 2025 and produced it again across multiple CVEs in 2026.
When the same bug class keeps landing in the same product, the CVE isn’t the finding. The finding is that you’re running an internet-facing app with an uncontained deserialization surface, and you should expect a sixth and a seventh.
CVE-2026-50522 is unauthenticated remote code execution in Microsoft SharePoint Server, CVSS 9.8, with no credentials and no user interaction required. The root cause is deserialization of untrusted data. Reach the server, send the payload, get code execution.
Here is the second vendor label of the month that didn’t survive contact with reality, and it failed in the opposite direction to 45659’s. This bug was demonstrated at Pwn2Own Berlin in May, meaning ZDI handed Microsoft a working exploit before the patch shipped. Microsoft’s advisory still carried an “Exploit Maturity Unknown” label. Childs flagged that in ZDI’s July review as a reason to run your own risk assessment instead of trusting a vendor exploitability field.
CISA added it to KEV on July 22 as part of a broader SharePoint hardening alert. That alert names five separate exploited SharePoint CVEs and describes the post-exploitation pattern: stealing IIS machine keys and chaining further deserialization to persist and deploy malware.
Machine key theft is the detail that changes your response plan. If an attacker pulled your keys before you patched, the patch doesn’t evict them. They keep forging valid payloads against a fully updated server. Patching closes the door. It doesn’t remove the guest.
CVE-2026-57092 is a use-after-free in Windows VMSwitch, CVSS 9.9, the highest of the July release, and it escalates a low-privileged attacker out of a guest VM to full host compromise. ZDI called it the top score of the month and drew the comparison to the ESXi guest-to-host escape demonstrated at Pwn2Own Berlin. If you run Hyper-V, VMSwitch is in the path.
A guest-to-host escape breaks the boundary your architecture depends on. Every “that workload is isolated” claim in your risk register rests on it holding.
It also has no KEV entry and no public proof-of-concept as of this writing, and that isn’t a mystery. It requires code execution inside a guest first. It’s a second-stage primitive, not an entry point, so low exploitation volume is what you’d predict from the access requirements alone.
Which is exactly the gap CVSS doesn’t measure. Compare it to CVE-2026-56164 from the same release: SharePoint elevation of privilege, CVSS 5.3, rated Moderate, missing authentication, unauthenticated over the network, no user interaction. CISA added it to KEV on July 14. A 5.3 that anyone on the internet could reach got attacked. A 9.9 that needs a foothold first didn’t.
CVSS measures technical severity honestly and it was never designed to answer the question you’re actually asking. Attackers select on reachability, reliability, and target count. Pre-auth beats post-auth every time, regardless of what the number says. That’s the basis of risk-based prioritization.
Three of these five are the same product. That’s the story of July.
| CVE | Product | CVSS | Type | Exploited | Fix |
|---|---|---|---|---|---|
| CVE-2026-56155 | Active Directory Federation Services | 7.8 | Local priv-esc, zero-day | Exploited pre-patch, DART credit | July Patch Tuesday |
| CVE-2026-45659 | SharePoint Server | 8.8 | Authd deserialization RCE | KEV July 1, FCEB due July 4 | May Patch Tuesday |
| CVE-2026-58644 | SharePoint Server | 9.8 | Unauth deserialization RCE | KEV July 16 | July Patch Tuesday |
| CVE-2026-50522 | SharePoint Server | 9.8 | Unauth deserialization RCE | KEV July 22, Pwn2Own demo | July Patch Tuesday |
| CVE-2026-57092 | Windows VMSwitch (Hyper-V) | 9.9 | Guest-to-host VM escape | Not exploited | July Patch Tuesday |
CVSS values as published by Microsoft and carried on Strobes VI at time of writing. Two of the five arrived with vendor exploitability labels, “Exploit Maturity Unknown” and “Exploitation Less Likely,” that KEV later contradicted.
Patch AD FS first, then the three SharePoint bugs, then VMSwitch on your normal cycle. That inverts the CVSS ranking, which would have put the untouched 9.9 at the top.
The order follows what each factor predicts. AD FS leads because it was exploited before any fix existed, which is the strongest evidence on this list and something no amount of patch discipline would have covered. The SharePoint bugs follow by KEV date, oldest first, because longer confirmed exploitation means more dwell time on anything you left exposed. VMSwitch is severe and unattacked, which makes it a patch rather than an incident.
The one rule to take from July: stop feeding vendor exploitability fields into triage. Both SharePoint labels failed in the same month, on the same product, in opposite directions. Those fields are published before anyone attacks the bug. KEV and EPSS move afterward, which is what makes them worth acting on.
Six hundred CVEs a month is the new baseline and Microsoft said so out loud. Manual severity triage doesn’t survive that volume. What survives is a queue ordered by exploitation evidence, exploit availability, and confirmed reachability in your environment, which is the prioritization stage of a CTEM program and what Strobes VI tracks per CVE at strobes.co/vi.
Which July 2026 CVE should I patch first?
CVE-2026-56155, the AD FS flaw, because it was exploited before a patch existed. Then the three SharePoint RCEs, oldest KEV entry first. All three are in CISA KEV and CISA issued a dedicated SharePoint hardening alert. Rotate machine keys after patching, because attackers have been stealing them for persistence.
Why is CVE-2026-45659 on a July list if it was patched in May?
Because CISA confirmed exploitation on July 1 and set a July 4 federal deadline. Microsoft had assessed it “Exploitation Less Likely” when the patch shipped. The fix sat available for roughly six weeks before anyone confirmed attacks, which is why rolling re-prioritization beats closing a patch cycle and calling it done.
Do I still need to act if I already applied the July SharePoint update?
Yes. CISA’s alert describes attackers stealing IIS machine keys for persistence. If your server was exposed before you patched, rotate ASP.NET machine keys across the farm, recycle the app pools, and hunt for prior access. A patch alone won’t remove an attacker holding valid keys.
Should I treat CVE-2026-57092 as urgent because it scores 9.9?
No. It’s a real Hyper-V guest-to-host escape worth patching, but it needs code execution inside a guest first, so it’s a second-stage primitive rather than an entry point. There’s no confirmed exploitation and no public PoC as of this writing. Meanwhile a SharePoint bug scored 5.3 reached KEV on July 14.
Why did Microsoft ship over 600 CVEs in one month?
Microsoft confirmed that an AI vulnerability discovery pipeline called MDASH now feeds its patch stream and told customers to expect higher volumes in every release going forward. ZDI’s Microsoft CVE count for 2026 to date already exceeds every previous full-year total in its twenty-year ledger.
How does Strobes help with a month like July?
Strobes Vulnerability Intelligence tracks exploit availability, EPSS movement, and KEV status per CVE in real time, and the platform validates which findings are actually reachable in your environment rather than theoretically present. That turns a 600-CVE release into a short ordered queue. See Adversarial Exposure Validation and RBVM.
