SharePoint Skips the Login, ADFS Hands Over Its Signing Keys: Inside Microsoft's July 2026 Zero-Days

Every Patch Tuesday brings noise, and we usually pick a lane. This month, no lane. Microsoft shipped fixes for more than 570 vulnerabilities on July 14, and three of them we could not stop thinking about, because they share the same shape underneath. In SharePoint, an unauthenticated request reaches a critical function that never asks who is calling. ADFS is worse: the container guarding the token signing keys quietly accepts readers it should not. And a Pwn2Own Berlin bug lets you be any SharePoint user whose Active Directory SID you can guess.

CISA added CVE-2026-56164 (SharePoint) and CVE-2026-56155 (ADFS) to the Known Exploited Vulnerabilities catalog the day the patches shipped [1]. The third, CVE-2026-55040, is Rapid7 Labs' Pwn2Own Berlin 2026 disclosure, chained with a still-embargoed second CVE to reach unauthenticated remote code execution on SharePoint [2]. The embargoed half is expected in the August 2026 rollup, which turns today's SharePoint patch into a rolling deadline rather than a finish line.

SharePoint stops asking who you are: CVE-2026-56164

Microsoft's advisory is unusually blunt: missing authentication for a critical function, remote unauthenticated attacker, elevation of privilege over the network with no user interaction [3]. Tenable pegged CVSS at 5.3 and Moderate, and CISA still added it to KEV the same day because exploitation is confirmed [4]. The shape is obvious: some SharePoint endpoint that was supposed to require a signed-in caller does not check, and once you reach it, you act with more privilege than the anonymous role should carry. Microsoft credits Jayson Frost at Mandiant, Genwei Jiang and Google Cloud's FLARE OTF, and an anonymous researcher, which almost always means the finding came out of a real incident rather than an audit [3].

Microsoft's interim mitigation points at the shape too. Enabling the Antimalware Scan Interface (AMSI) on the SharePoint server with Request Body Scan set to Full is a partial mitigation while you patch [3]. AMSI inspects the HTTP body against defender signatures before the request reaches the vulnerable handler, so if that helps, the exploit lives in a request body a defender can pattern match. It slows opportunistic scanners; it will not stop a targeted operator.

ADFS gives up its signing keys: CVE-2026-56155

The ADFS bug is a lovely one to read as a defender because the failure is not in the code, it is in the ACL. Active Directory Federation Services keeps its signing and encryption certificates encrypted at rest, and the private keys are protected by a Distributed Key Manager (DKM) container inside AD. Read access to that container is supposed to be tightly scoped to the ADFS service accounts. The July disclosure describes the flaw as insufficient granularity in that access control: a low-privilege authenticated principal can read the DKM material, decrypt the private keys, and mint any token the ADFS farm can mint [5].

If someone owns your ADFS token signing key, the identity plane is over. They can forge SAML assertions and JWTs for any federated user, and the downstream trust surface accepts them because the signature is real: every Microsoft 365 tenant, every on-premises app federated to the farm inherits the compromise. This is Golden SAML in the strict sense, and Microsoft says it is being exploited already [6]. The fix is more than the monthly rollup; administrators also need to apply the ACL hardening in KB5121391 on the DKM container itself, or the code fix does not close the read path [5]. Jeremy Kingston and Scott Clark of Microsoft's DART team get credit, and DART finds bugs the way we do, by looking at what an actor already did in someone's environment.

The Pwn2Own JWT chain: CVE-2026-55040

The third one is the most fun and the most concerning. Rapid7 Labs' entry at Pwn2Own Berlin 2026 was a two-bug chain against SharePoint. The front half, CVE-2026-55040, is an authentication bypass in SharePoint's JWT validation pipeline (CVSS 9.1, CWE-1390 Weak Authentication); the writeup says a remote unauthenticated attacker can assume the identity of any SharePoint site user or administrator, provided they know that user's AD Security Identifier or User Principal Name in advance [2]. In enterprise SharePoint deployments, SIDs and UPNs are not secrets: they leak through Autodiscover, through public metadata, through any authenticated Graph query a first-stage foothold already has.

The back half is a separate RCE bug Rapid7 has not disclosed and Microsoft has not yet patched. Rapid7 confirmed the pair reaches unauthenticated remote code execution, with the second half expected in the August 2026 patch cycle [2]. Patching CVE-2026-55040 today breaks the chain, so the SharePoint July rollup is the load-bearing piece until August lands. Rapid7 will publish full technical detail within thirty days, at which point we will know exactly what claim or signature step SharePoint mishandles.

Why your normal tooling misses all three

None of these are noisy on the wire, which is why they slip past a well-run SOC. CVE-2026-56164 looks like an ordinary anonymous request to a legitimate SharePoint URL until you notice the response contains data the anonymous role should not see. The ADFS bug is entirely inside Active Directory, an LDAP read against the DKM container by an account with a valid ticket, so there is no exploit payload for your IDS to fingerprint. And the Pwn2Own bypass arrives with a JWT your own SharePoint server signs off on; the identity is real, the signature verifies, the downstream logs record a legitimate session. Mapped to MITRE ATT&CK this cluster is dominated by T1550.001, T1606.002, and T1078, with T1190 only at the SharePoint initial request and only if you were already logging anonymous status codes on-premises. Most fleets are not.

Where the tell actually lives

CVE-2026-56164 leaves its mark in the SharePoint IIS logs. Hunt for any 200-status response to an anonymous request against paths that should have redirected to sign-in: GET or POST with no cookies and no bearer token, returning 200 from /_layouts, /_api, or /_vti_bin. Time-box the window against the July 14 install date and correlate against your legitimate anonymous baseline.

The ADFS bug lives on the domain controller side. You want directory service access events (4662) on the DKM container's distinguished name (CN=DKM, CN=ADFS, CN=Microsoft, CN=Program Data, DC=...) from any principal that is not the ADFS service account. Turn directory service auditing on for that specific container if it is not already, and treat any hit as an incident: assume the token signing key is compromised, rotate the ADFS certificates as part of the response rather than after, and check every federated relying party for tokens minted outside your issuance window.

CVE-2026-55040 is different. Rapid7 has not published the exploit primitive yet, so there is no static signature to write today. Log every JWT-authenticated SharePoint session and correlate incoming source IP and user agent against the historical baseline for the claimed user. A UPN that suddenly authenticates from a new country with a token minted seconds ago and no matching interactive login event is the shape of it; rebuild that hunt against Rapid7's writeup when it lands.

What to actually do this week

Patch order matters. Apply the July 14 Windows Server updates to your ADFS servers, then run the KB5121391 ACL hardening on the DKM container, and verify the container ACL afterward with dsacls. Apply the SharePoint July 14 updates to Subscription Edition, 2019, and Enterprise Server 2016 [4]. If you cannot meet CISA's KEV deadline [1], enable AMSI Request Body Scan and restrict anonymous access at the load balancer in front of SharePoint. Rotate ADFS token signing and encryption certificates as soon as the patch is verified, mandatory on any farm showing indicators of DKM reads. The SharePoint July rollup is also what breaks the Pwn2Own chain, so it is not an August problem.

The interesting thing about these three bugs is how ordinary the broken thing is in each: a missing auth check, a misapplied ACL, a JWT pipeline that trusts a claim it should not. None of the mechanisms are novel, and yet all three let an attacker become a user they are not, which is the bug worth remembering once the record CVE count fades.

At BlueTeamAutomation we run these scenarios continuously through BASzy against your SharePoint and ADFS estate, so the detection you build today for Golden SAML or an anonymous SharePoint hit keeps proving itself between patches. That is the loop we automate end to end, from simulated identity forgery through EDR and SIEM correlation into a SOAR playbook, so proof of the patch is a daily state rather than a Tuesday scramble.