Microsoft July 2026 Patch Tuesday ships two actively-exploited zero-days — AD FS local EoP (CVE-2026-56155) and unauthenticated SharePoint EoP (CVE-2026-56164)

The July Patch Tuesday entry covered the two KEV-listed exploited zero-days (AD FS CVE-2026-56155, SharePoint CVE-2026-56164). Four further high-severity fixes in the same cycle carry pre-auth risk and warrant separate attention. CVE-2026-55040 (CVSS 9.1, weak authentication) is a SharePoint JWT token-validation bypass that Rapid7's Stephen Fewer built into a two-vulnerability chain for Pwn2Own Berlin 2026: a remote unauthenticated attacker who knows a target's Active Directory SID or User Principal Name can forge identity and operate as that SharePoint user or administrator (Rapid7 Labs, 2026-07-14). Rapid7 chained it to a still-undisclosed RCE that Microsoft will not patch until the August 2026 cycle — but "patching CVE-2026-55040 will successfully break this exploit chain," so the July update is the available defense today even with the RCE half outstanding (Rapid7 Labs, 2026-07-14).

CVE-2026-55944 (CVSS 9.8) is an unauthenticated deserialization RCE in Microsoft Dynamics NAV / Dynamics 365 Business Central (on-premises) — "deserialization of untrusted data ... allows an unauthorized attacker to execute code over a network," triggered by a crafted login request before any session exists (vector AV:N/AC:L/PR:N/UI:N), and rated "Exploitation More Likely" (Microsoft MSRC, 2026-07-14). It is easy to overlook against SharePoint or Exchange in a busy Patch Tuesday, yet on-prem Dynamics back-office instances are frequently exposed. Two more SharePoint deserialization RCEs — CVE-2026-50522 and CVE-2026-58644 (both CVSS 9.8, "Exploitation More Likely") — require Site-Owner-level access per Microsoft's FAQ; CVE-2026-50522 is fixed in the July cumulative update, while CVE-2026-58644's patch actually shipped in the June cumulative update and the CVE was only documented on 14 July after being omitted from June's release notes — so a SharePoint estate patched through June is already covered for 58644 (Microsoft MSRC, 2026-07-14).

The 2026-07-15 entry carried CVE-2026-58644 as a CVSS 9.8 SharePoint deserialization RCE rated only "Exploitation More Likely," with its patch noted as having shipped in the June 2026 cumulative update. CISA has now confirmed it is being exploited in the wild: its SharePoint alert, updated 2026-07-16, states CISA "is aware of active exploitation of vulnerabilities CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, and CVE-2026-58644, enabling cyber threat actors to gain unauthorized access to on-premises SharePoint Server instances," and CISA added CVE-2026-58644 to the KEV catalog the same day (CISA, 2026-07-16). The alert describes the cluster's post-exploitation as stealing IIS machine keys — the ASP.NET view-state signing/encryption keys — and using deserialization techniques to gain persistence and deploy malware, so the machine key, not the single CVE, is the durable foothold once any of the four is exploited.

The July 2026 SharePoint patch cluster carried CVE-2026-50522, a deserialization-of-untrusted-data RCE that all sources had assessed as not-yet-exploited (Microsoft flagged only an "increased likelihood"). That changed on 2026-07-21: NCSC-NL updated advisory NCSC-2026-0237 to report, per watchTowr, that public exploit code for CVE-2026-50522 was published and the flaw is now actively exploited against on-premises SharePoint, with attackers stealing machine keys for long-term access (NCSC-NL, 2026-07-21).

watchTowr detailed the chain (relayed via BleepingComputer): a malicious .NET BinaryFormatter payload is delivered as the cookie of a forged SecurityContextToken in a WS-Federation sign-in response posted to SharePoint's /_trust/default.aspx endpoint; a successfully processed payload executes code and lets the attacker exfiltrate the server's machine keys, which are then used to forge valid ASP.NET authentication tokens/ViewState — giving persistent, re-authenticatable access that survives patching unless the keys are rotated (BleepingComputer, 2026-07-21). A PowerShell PoC (attributed by BleepingComputer to researcher "Janggggg") went public on 2026-07-20, and watchTowr's Attacker Eye honeypots captured successful compromises within hours (BleepingComputer, 2026-07-21); Security Affairs corroborates that the public PoC triggered active exploitation (Security Affairs, 2026-07-21). No authentication is required for the initial RCE.

The entry on July's SharePoint pre-auth JWT bypass covered CVE-2026-55040 as one half of a Pwn2Own chain whose second half was still unpatched, and the W29 outlook carried it as an item in motion — a SharePoint chain half-patched until August. Both halves are now disclosed and one of them has public exploit code. Microsoft's August Patch Tuesday published CVE-2026-63520, a remote code execution vulnerability in SharePoint Server, and Rapid7 — whose Senior Principal Security Researcher Stephen Fewer discovered it — states that "this vulnerability is the second in a pair of exploits which, when chained together, comprise a critical unauthenticated remote code execution vulnerability in a vulnerable SharePoint server" (Rapid7, 2026-08-11). The same post records the second half of the release: "Alongside today's coordinated disclosure of CVE-2026-63520, Rapid7 has now published a detailed technical analysis and proof-of-concept for CVE-2026-55040, the first vulnerability in the chain."

The two records read very differently on their own, which is the point of reading them together. Microsoft classes CVE-2026-63520 as improper input validation (CWE-20), CVSS 8.1 with high attack complexity, severity Important, allowing an unauthorised attacker to execute code over a network (MSRC, 2026-08-11). CVE-2026-55040 is the more severe of the pair on its own terms: "Weak authentication in Microsoft Office SharePoint allows an unauthorized attacker to bypass a security feature over a network", CWE-1390, CVSS 9.1 with low attack complexity and no privileges or user interaction required, severity Critical (MSRC, 2026-08-11). Microsoft records both as not exploited and not publicly disclosed before their patches, and rates both "Exploitation More Likely". Patches exist for SharePoint Server Subscription Edition, 2019 and 2016 (Rapid7, 2026-08-11).

What moves this ahead of the ordinary patch cycle is not a score but the disclosure state. The authentication-bypass half now has published analysis and working proof-of-concept code, and the code-execution half it chains into was documented the same day — so the research cost of reconstructing an unauthenticated RCE against an unpatched on-premises farm has collapsed to reading two public write-ups. Nothing in either advisory reports exploitation yet; the exposure is the window between publication and patch coverage, on a product class whose internet-facing deployments are collaboration portals rather than obscure infrastructure.

That window matters more than usual for this constituency. Two Swiss public-sector SharePoint compromises were disclosed in the last nine days — the Confederation's own IT provider on 4 August and the canton of Graubünden on 5 August, both on-premises estates and both attributed by the affected bodies to the SharePoint flaws disclosed in mid-July. Neither of those intrusions involves the CVEs here, and nothing in the cited sources connects them; the relevance is the estate, not the incident. An organisation that has just rebuilt or re-imaged SharePoint servers in response to the July wave is exactly the organisation whose new builds may predate both the July and August updates, and whose asset inventory for those hosts is least likely to be current.

Detection concepts are constrained by what has been published: neither Microsoft record describes the vulnerable code path, and this entry does not have Rapid7's technical analysis in hand, so behavioural detail beyond the advisories would be invention. What the advisories do support is exposure work rather than detection work — enumerate on-premises SharePoint farms and their patch levels across Subscription Edition, 2019 and 2016, and treat internet-reachable ones as the priority, since both halves of the chain are network-reachable with no authentication and no user interaction. Where a farm's August update cannot be applied immediately, restricting the server's reachability to authenticated internal networks is the control that does not depend on knowing which request shape to look for.

Yesterday's entry recorded that Rapid7 had published a technical analysis and proof-of-concept for CVE-2026-55040 and stated plainly that it did not have that analysis in hand, so no behavioural detail could be offered. Two things changed within a day. The proof-of-concept is being used in attacks, and the analysis — read in full for this entry — turns an exposure problem into a hunt.

Threat-intelligence company Defused reported on 2026-08-12 that "Attackers are now using the @rapid7 POC for CVE-2026-55040 against our SharePoint honeypots", roughly a day after the code was published (BleepingComputer, 2026-08-12). That is one company observing its own sensors, not a vendor confirmation: the same report notes that "While Microsoft has labeled this security flaw as an attractive target for attackers", it has not yet flagged it as successfully exploited in the wild (BleepingComputer, 2026-08-12). Switzerland's NCSC added the exploitation-attempt claim to its own July Patch Tuesday advisory on 12 August, having added the analysis and proof-of-concept to the same advisory the day before (NCSC-CH, 2026-08-12). For scale, the same reporting cites Shadowserver, which "currently tracks over 8,500 Microsoft SharePoint servers exposed online", with the honest caveat that how many are honeypots or already patched is unknown (BleepingComputer, 2026-08-12).

How the bypass works, and why it matters that it is four bugs and not one. Rapid7's analysis, based on decompilation of the identity module from a fully patched Subscription Edition build, states that "The root cause is a chain of four distinct weaknesses that, when combined, allow an unauthenticated remote attacker to forge a valid JWT and impersonate any SharePoint site user" (Rapid7, 2026-08-11). SharePoint's server-to-server authentication uses a nested token: an outer token carrying user identity claims, and an inner "actor token" representing the calling application that is expected to be cryptographically signed. Each of the four failures removes one guarantee from that design.

First, the token handler explicitly turns off the requirement for signed tokens when it builds its validation parameters — Rapid7's description is blunt: "This single line disables the JWT library's cryptographic signature verification", so the outer token is accepted with no signature at all. Second, the code resolves the inner actor token's signing key from a thumbprint value carried in that token's own header, searching all trusted certificates including SharePoint's own local security-token-service certificate, and assigns the resolved key without ever verifying a signature against it. Third, issuer validation then looks for a registered token service matching that certificate, does not find one — because the server's own signing certificate is not in the collection being searched — and treats the absence of a match as grounds to accept rather than reject. Fourth, the final signature step requires only that a signature string be non-empty; any arbitrary value satisfies it. The result is that the identity in the outer token's name claim, which the caller chooses, is resolved to a real account. (Rapid7, 2026-08-11)

Two properties of that chain matter operationally more than the mechanics themselves. The certificate whose thumbprint the attacker needs is published by the server: Rapid7 records that it is retrievable from an unauthenticated metadata endpoint on the SharePoint site itself, so no prior access is required to obtain it. And picking a useful identity is a separate reconnaissance step — Rapid7 describes querying the target's domain controller over an anonymous SMB session to learn the domain identifier, then walking relative identifiers to enumerate candidate accounts and find one that is a site administrator, noting that a user principal name works too but is less reliable to guess. (Rapid7, 2026-08-11)

Detection, in telemetry terms. The decisive weakness leaves a server-side record: Rapid7's decompilation shows the issuer-validation path emitting a trace message stating that the issuer was accepted because no registered token service matches the signing certificate, immediately before returning success (Rapid7, 2026-08-11). On a healthy farm that path should be rare; on an attacked one it fires on every forged token. That message in the SharePoint diagnostic trace logs is the highest-value single artefact available, and it is a server-side one, so it survives an attacker who never touches the endpoint. Alongside it, three sequences are worth building around: an unauthenticated request to the site's metadata endpoint from an external address, followed within a short window by bearer-token requests to the site's REST API from the same source; authenticated REST activity — reading files, minting a form digest, changing configuration — with no corresponding interactive sign-in or federation token issuance for that account in identity logs; and anonymous SMB sessions enumerating account identifiers from an address that also talks to the SharePoint front end.

Triage: legitimate server-to-server integrations also present bearer tokens to the SharePoint REST API, which is why the token's presence is not the signal. The discriminators are the ones the mechanism forces: a token whose acceptance is accompanied by the unregistered-signing-certificate trace message, activity attributed to a highly privileged account with no matching sign-in event in the identity provider, and an external source address that fetched the unauthenticated metadata endpoint shortly beforehand. A normal integration is registered, so its issuer resolves against a registered token service and never takes the accepting-by-default branch.

The exploitation status flipped. CISA added CVE-2026-55040 to its Known Exploited Vulnerabilities catalog on 2026-08-18, describing it as a weak-authentication flaw that "allows an unauthorized attacker to bypass a security feature over a network" (CISA KEV catalog, 2026-08-18), ENISA's EU Vulnerability Database carries the same date and an EPSS of 3.97, mirroring that determination rather than independently confirming it (ENISA EUVD, 2026-08-18). The earlier entry carried this flaw as proof-of-concept-public on the strength of Rapid7's exploit being replayed against honeypots a day after publication — real exploitation attempts, but against sensors rather than estates. The federal catalogue now classes it as exploited outright, which is a stronger statement than honeypot telemetry even though it rests on one authority.

Microsoft's own record has not moved. It still records exploitation as no, and its published explanation of the impact remains that "the authentication feature could be bypassed as this vulnerability allows impersonation" (Microsoft Security Response Center, 2026-07-14) — the vendor rates the flaw Critical at CVSS 9.1 and does assess exploitation as more likely, which agrees with the catalogue's direction — what disagrees is the record's own exploited field, still set to no with no revision since 14 July. That is the second Microsoft CVE in this catalogue update whose exploited field contradicts the catalogue, and it is a reason not to let a vendor-scored feed be the only input to a SharePoint patch decision. (On the sibling IKE Extension flaw the vendor's exploitability assessment is the disagreeing field too; here only the exploited flag is.)

The reason this matters here more than the score suggests is the estate. Switzerland's federal IT provider BIT confirmed a SharePoint Server intrusion affecting around 200 federal user and technical accounts, and canton Graubünden disclosed its own SharePoint server breach a day later — both already covered here, and neither publicly tied to this identifier by any source. What the exploitation listing changes is the standing of an unpatched, internet-reachable farm: the honest reading is no longer "a proof-of-concept exists" but "this is being used", and a farm that sat exposed between the July patch and now warrants a look at its authentication records rather than an upgrade ticket alone.

Hunting concentrates on the impersonation outcome rather than the request that produced it, because a forged token is accepted by design once validation fails. In authentication and application telemetry, the signals are SharePoint access events whose asserted identity has no corresponding interactive sign-in from the same source within the session window, site-administrator-level operations from a client that never authenticated normally, and unauthenticated requests to token-handling endpoints immediately preceding privileged activity. Triage: federated and app-only access legitimately produce SharePoint operations with no interactive sign-in, so that pattern alone is normal in most tenants — the discriminators are whether the asserted principal is one that federation or a registered application is actually configured to assert, and whether the source address belongs to the estate's own service ranges. Patching is the remediation; there is no configuration workaround in the vendor's record.