SharePoint Authentication Bypass Chain: What On-Premises Admins Must Patch Now

Microsoft has finished patching a chain of two SharePoint flaws. Together, they let an attacker take over an on-premises server without ever logging in. The last piece closed on 11 August, when researchers at Rapid7 disclosed CVE-2026-63520, a remote code execution bug in SharePoint’s Business Connectivity Services. Chained with a SharePoint authentication bypass patched a month earlier, it adds up to unauthenticated SharePoint remote code execution. That’s the kind of vulnerability that turns a routine intranet server into a route straight into the network.

Inside the SharePoint authentication bypass

The first flaw, CVE-2026-55040, sits in how SharePoint validates JSON Web Tokens. Rapid7 found four separate weaknesses stacked in the same code path. Signature checking was switched off. A certificate used to verify tokens was trusted without checking it was genuine. The final signature check only confirmed a value was present, not that it was correct.

Put together, those four gaps add up to one working exploit. An attacker just needs a target’s Active Directory username. That’s often guessable, or sitting in a prior breach dump. With it, they can forge a token. SharePoint then treats them as that user, even an administrator. No password is needed. No account of their own, either.

On its own, that bypass scored 9.1 out of 10 on the CVSS severity scale. Microsoft patched it on 14 July. The fix shipped as KB5002882, KB5002883 and KB5002891, covering SharePoint Server Subscription Edition, 2019 and 2016.

From impersonation to full control

The second flaw is where impersonation turns into full control. It’s catalogued as CVE-2026-63520, rated 8.1. The bug sits in Business Connectivity Services, a SharePoint component that builds .NET objects from crafted input in an unsafe way. An attacker who has already forged their way in as an administrator can use it to run their own code. It executes with the privileges of the SharePoint service account. Microsoft shipped the fix for this one on 11 and 12 August, via KB5002893, KB5002894, KB5002905 and related updates depending on version.

The attacker doesn’t need to be inside the network first, either. Rapid7’s technical write-up describes an unauthenticated endpoint, /_layouts/15/metadata/json/1. It hands out the certificate SharePoint uses to sign its tokens. Combine that public endpoint with a known username and the four validation weaknesses. The entire chain becomes reachable from outside the firewall, with no VPN and no prior foothold required.

Who found it, and how

Rapid7 built the exploit chain as an entry for the Pwn2Own Berlin hacking contest. The team ran two research sprints against SharePoint, in January and March 2026. Notably, they used an AI agent for a large part of the work: roughly 80,000 tool calls across 96 sessions over 24 active days, hunting through SharePoint’s code for the weaknesses that became these two CVEs, including the SharePoint authentication bypass.

The submission itself didn’t place at the contest, but the underlying research still stood up. Rapid7 reported it to Microsoft through normal coordinated disclosure on 18 May. Microsoft confirmed the findings two days later. Rather than rush out both patches at once, it split the fix across two update cycles. That’s why the authentication bypass and the code execution flaw closed a month apart, not on the same day.

As of Microsoft’s July disclosure, CISA said the bypass was not known to have been exploited. Rapid7 reports the same for the RCE flaw at time of writing. Take that as a narrow window, not a reason to wait. Proof-of-concept exploit chains for high-severity Microsoft vulnerabilities typically appear within days of technical write-ups going public. This one already has two detailed vendor blog posts explaining exactly how it works.

What’s affected, and what isn’t

This is an on-premises problem. SharePoint Server Subscription Edition, SharePoint Server 2019 and SharePoint Server 2016 are all affected by the SharePoint authentication bypass. The RCE flaw additionally touches Project Server 2013 SP1 and Office Web Apps 2013 SP1. SharePoint Online, the Microsoft 365 hosted version, is not affected at all. If your organisation runs SharePoint entirely in Microsoft’s cloud, this story doesn’t apply to you.

If you still run an on-premises farm, though, both patches need to be applied, not just the more recent one. The July update closes the door the attacker walks through. The August update closes what they can do once inside. A server patched against only one half of the chain is still exposed.

Why this matters beyond SharePoint

Two things about this disclosure are worth sitting with. First, the SharePoint authentication bypass required no credentials at all. It only needed a username format that’s often visible in email addresses, staff directories or old breach data. That’s a low bar, and it’s why the CVSS score sits above nine.

Second, this kind of chained research fits a pattern. A bypass and a low-severity-looking code execution bug combine into something critical. That’s exactly what a proper penetration test is built to catch. Automated scanners flag CVEs individually. They rarely model how two moderate findings on the same server add up to full compromise.

For any business running SharePoint on its own infrastructure, that’s the practical lesson. Confirm both KBs are installed on every farm server. Check external exposure of the SharePoint front end. Treat a clean vulnerability scan as a starting point, not an answer.