SURIQ
The most useful signal in Microsoft's July 2026 Patch Tuesday is who found the bugs that matter. Two of the three zero-days in this release were already being exploited when the patch shipped on July 14, and neither surfaced from a bug bounty or an automated scanner. Microsoft credited them to incident-response teams: its own Detection and Response Team for the Active Directory Federation Services flaw, and Mandiant plus Google Cloud researchers for the SharePoint one. When an IR team is the finder, the flaw usually turned up while they were cleaning up a real intrusion. The exploitation came first; the CVE is the aftermath.
Both flaws sit on the identity and access plane, and CISA added both to its Known Exploited Vulnerabilities catalog on the same day Microsoft disclosed them. That is a tight loop. Federal agencies have until July 17 to fix the SharePoint bug and July 28 for the federation one. If you run either product on your own servers, treat those dates as your floor, not a suggestion.
The two bugs already in use
CVE-2026-56164 is a missing-authentication flaw in on-premises SharePoint Server. According to Microsoft's advisory, it lets an attacker with no credentials reach a privileged function over the network and raise their access on the server. CVE-2026-56155 is a weakness in how AD FS enforces access control that lets an already-authenticated user climb to higher privileges on the host. The remaining zero-day, a Windows BitLocker weakness tracked as CVE-2026-50661, was made public but carries no reports of exploitation, so it can wait behind the other two.
| Attribute | CVE-2026-56164 (SharePoint) | CVE-2026-56155 (AD FS) |
|---|---|---|
| Product | On-premises SharePoint Server | Active Directory Federation Services |
| Access needed | None (unauthenticated) | Authenticated local user |
| Vector | Over the network | Local elevation of privilege |
| Microsoft severity | Moderate | Important |
| CISA deadline | July 17, 2026 | July 28, 2026 |
| Credited finder | Mandiant / Google Cloud | Microsoft DART |
The full release is enormous. BleepingComputer counted more than 570 CVEs, which it called the largest Patch Tuesday Microsoft has ever shipped. Volume like that makes triage the real problem: nobody patches 570 things at once, so the question is which handful to move on today. The KEV listing answers it for you.
The severity labels are pointing the wrong way
Microsoft rated the SharePoint zero-day Moderate and the AD FS zero-day Important. Neither is labeled Critical. Yet both are confirmed exploited and both drew a CISA deadline. If you sort your patch queue by the vendor's severity string, these two drop below dozens of Critical-rated bugs that nobody is using.
We saw the same gap two weeks ago. Microsoft shipped CVE-2026-45659 with an "Exploitation Less Likely" tag in May, and CISA added it to the KEV catalog on July 1 after attacks in the wild. The lesson repeats: a pre-release exploitability guess is not a field observation. When the people who found a bug are an incident-response team, the label has already been overtaken by events. Sort by exploitation status, not by the CVSS band.
On-premises SharePoint is now a standing target
CVE-2026-56164 is the second SharePoint Server flaw CISA has KEV-listed inside two weeks. On-premises SharePoint has become a reliable way into corporate networks, the way internet-facing VPN appliances were a few years ago. If you still run it yourself, the honest posture is assume-breach: patch, then go looking for signs someone was already inside before you did.
Microsoft's interim mitigation for the SharePoint bug is worth doing even after you patch. Turning on the Antimalware Scan Interface and setting request body scanning to Full gives your security tools visibility into the request content hitting the server, which is the same hardening Microsoft has pushed for on-premises SharePoint during earlier exploitation waves. Operators who already enabled it have both partial coverage and a logging vantage point for the hunt.
Why the AD FS bug is bigger than one server
An elevation-of-privilege flaw in AD FS is easy to underrate because it needs an authenticated foothold first. The reason it matters is where AD FS sits. It is the trust anchor that issues the tokens your federated applications accept, so an attacker who gains control there is not compromising one box, they are in a position to influence authentication decisions across every application that trusts it. That is a familiar failure class: we covered a forged-identity flaw in CoreWCF's SAML handling that trusted an attacker as an administrator, and the Azure CLI password spray that walked past MFA through a retired login flow. The identity layer is where a small foothold turns into a large one.
Patch SharePoint today, AD FS by month end
Sequence the work by exposure and deadline, not by the severity label:
- On-premises SharePoint Server: apply the July update now. If you cannot patch immediately, enable AMSI and set request body scanning to Full, then assume the server may already be touched and start hunting.
- AD FS: patch by the July 28 deadline, sooner if the server is reachable by anyone who could get an authenticated foothold. Review who can log in locally to the AD FS host and treat that list as privileged.
- Everything else in the 570: the BitLocker zero-day is disclosed but not exploited, so it sits behind the two KEV items. Work the KEV list first, then the Critical RCEs.
Patching closes the hole. It does not tell you whether someone walked through it in the window before you moved, and for both of these the exploitation predates the fix. That is the part a patch ticket misses: after you update, look at authentication logs on the AD FS host and request patterns on the SharePoint server for the days before you patched. This is exactly the assume-breach hunt a managed detection and response practice runs, and where our threat-hunting and vulnerability-detection work focuses: closing the gap between a patch that stops the next attempt and evidence about the last one.