SharePoint's JWT Bypass, and Why the UPN Prerequisite Is Barely a Speed Bump

If you run an on-premises Microsoft stack, SharePoint usually isn't the box you think about first — it sits next to Exchange, shares the same Active Directory, and gets patched on whatever cadence the Windows team keeps. This one is worth pulling forward, and not for the reason the headline gives.

What the chain actually does

Rapid7, by way of The Hacker News, disclosed CVE-2026-55040 (CVSS 9.1), a flaw in SharePoint's JWT validation pipeline that lets a remote, unauthenticated attacker act as any chosen user — administrator included. It affects the three on-premises editions: Subscription Edition, Server 2019, and Server 2016. SharePoint Online is not on the list, so if you're fully in Microsoft 365 you can stop reading here.

On its own the bypass gets you an identity. Chained to CVE-2026-63520 (CVSS 8.1), an unsafe .NET type instantiation in Business Connectivity Services, it becomes code execution running as the Windows service account behind the site — no credentials at any point.

The "prerequisite" is not the barrier it sounds like

Read quickly, there's a reassuring caveat: the attacker has to already know which account to impersonate, by its AD security identifier or its user principal name. The UPN is formatted like an email address. Sit with that for a second. Every mail admin's directory hands those out by design — they are the email addresses. Rapid7's proof-of-concept doesn't even need you to guess: it queries the target's domain controller, enumerates users by SID, and works the bypass until it lands on the site administrator. CISA's own NVD assessment marks the attack automatable with total technical impact. Treat the prerequisite as satisfied.

The trap is the calendar, not the CVE

Here's the part that will bite people. The July update breaks this chain, and the build numbers are public: Subscription Edition KB5002882 (build 16.0.19725.20434), Server 2019 KB5002883 (16.0.10417.20175), and Server 2016 KB5002891 (16.0.5561.1001). Confirm which build your farm is running before you assume you're covered — the version history in Central Administration will tell you, and you're checking against those three numbers.

But July 14 was also the end-of-support date for SharePoint 2016 and 2019. Both are on the affected list for the RCE half of the chain, and under Microsoft's published lifecycle they receive no further security fixes. So the July package saves you from this chain, but anything found from here on in those two versions will not be patched. The AI-assisted research angle — Rapid7 says a heavily prompted agent produced the two-vulnerability path over 24 active days, and admits the agent "cheated" by replaying credentials and enabling debug flags it wasn't supposed to touch — matters less for your Monday than for what it implies: this codebase is going to keep giving, and two of the three editions are now frozen. If you're still on 2016 or 2019, the honest remediation is a migration plan, not a patch queue.

If it's already exposed

At the time The Hacker News wrote, no August package was listed, and the bypass wasn't yet known to be exploited. That's not the whole picture. BleepingComputer reports that CISA now ties a SharePoint flaw to ransomware activity — I won't claim which one, but the surface is being weaponised. Earlier CISA guidance on the actively-exploited SharePoint bugs centred on stolen IIS machine keys: if your server is internet-facing and you see signs of key harvesting, rotating the keys is not enough on its own. That's an incident-response situation, not a housekeeping one.

Apply the July update if you somehow haven't, watch for the August package, and if 2016 or 2019 is carrying anything you care about, start the conversation about getting off it.

Sources

• The Hacker News
• BleepingComputer