SharePoint's JWT bug let anyone forge an admin, no password needed

Most authentication bypasses come down to one missing check. CVE-2026-55040, a critical (CVSS 9.1) flaw in on-prem Microsoft SharePoint Server disclosed as part of July 2026 Patch Tuesday and added to CISA’s Known Exploited Vulnerabilities catalog on August 18 after a public proof-of-concept turned into real attacks, took four (Rapid7). It’s a clean case study in how a token-validation pipeline can look defense-in-depth on paper — issuer checks, certificate checks, signature checks — while each individual check is quietly broken, and the sum of four broken checks is no authentication at all.

Root cause

SharePoint’s server-to-server auth uses a nested JWT: an outer token carrying user identity claims, wrapping an inner “actor token” that represents the calling application and is supposed to be signed by a trusted certificate. Rapid7’s teardown of the patch found four independent failures in how that structure gets validated (Rapid7):

• Signatures were optional. The code building TokenValidationParameters for the underlying Microsoft.IdentityModel library set RequireSignedTokens = false, so a token with "alg": "none" sailed through with no cryptographic check at all.
• The signing key came from the attacker. When a signature was present, the server resolved which certificate to validate against using a thumbprint taken straight from the attacker-controlled JWT header — the client got to nominate which key would be trusted to check its own token.
• Issuer validation didn’t actually restrict anything. The issuer check passed because it was searching the wrong trusted list — SharePoint’s own STS certificate matched, just not through the path the validator thought it was checking.
• “Signed” meant non-empty, not valid. Where a signature was still required, the final check only verified the signature field wasn’t an empty string (AAAA satisfied it) — never that it was cryptographically correct.

Any one of those alone would be a real bug. Together they mean an unauthenticated attacker can hand-build a JWT claiming to be any user — including a Farm Administrator — and SharePoint has no step left in the pipeline that actually verifies the claim. This is CWE-1390, weak authentication, but “weak” undersells it: functionally there’s no authentication step to defeat, just paperwork that resembles one.

Blast radius

CVE-2026-55040 hits SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016 — SharePoint Online is unaffected, so this is specifically the on-prem/hybrid estate (cybersecuritynews.com). A successful forgery grants access “as” whatever user the attacker specifies in the token, with no password, MFA prompt, or session to steal first — including administrative accounts, which means content across every site collection on the farm, plus whatever the SharePoint service account and downstream integrations (Search, Search crawlers hitting file shares, Power Automate connectors, Teams file backends) can reach. Rapid7 and CISA both note it chains with a second flaw, CVE-2026-63520, into unauthenticated remote code execution on the SharePoint server itself — turning “impersonate an admin” into “run code as the farm” (securityonline.info). That’s the same shape as the 2025 ToolShell SharePoint chain: an auth bypass on its own is bad, but the real damage shows up once it’s paired with the next link.

Exploitation moved fast. The patch shipped in July 2026 Patch Tuesday; Rapid7 published a technical writeup with proof-of-concept details in August; within days, honeypot telemetry showed real attackers running the PoC against exposed servers, and CISA added it to KEV on August 18 (Help Net Security). That’s the now-familiar timeline for on-prem enterprise software: patch ships quietly, researcher writeup makes the bug legible, and the gap between “PoC public” and “mass scanning” is measured in days, not weeks.

Remediation

• Patch now if you haven’t. Apply the relevant July 2026 update — KB5002882 (Subscription Edition), KB5002883 (2019), or KB5002891 (Enterprise 2016) — then re-run the SharePoint Products Configuration Wizard on every farm server; the binary update alone doesn’t finish the job.
• Assume compromise if you were patched late. Given the KEV listing and active exploitation, treat any internet-reachable, unpatched farm between the July disclosure and your patch date as a potential breach, not a near-miss — review IIS and ULS logs for anomalous admin-context requests and unexpected actor-token traffic during that window.
• Cut internet exposure to SharePoint admin and STS endpoints. If a farm must stay internet-facing for collaboration, put the /_vti_bin/, admin-center, and token-service paths behind IP allowlisting or a VPN — this bug (and the RCE chain behind it) both start with an unauthenticated HTTP request.
• Check the CVE-2026-63520 chain separately. Patching the auth bypass alone still leaves the RCE half of the chain if that companion CVE isn’t also addressed on the same farm.
• Reduce what a forged admin token can actually reach. Service accounts and downstream connectors (Search crawl accounts, Power Automate, Teams) inheriting broad farm permissions is what turns “an admin session” into “every file share the crawler indexes.” Least- privilege for the SharePoint service identity limits this bug’s ceiling the same way scoping an IAM role limits a stolen cloud credential’s.

The bigger lesson

The interesting failure here isn’t any single check — it’s that four checks each failed in a way that looked, in isolation, like normal defensive code doing its job: validate the signature requirement, resolve a certificate, check the issuer, verify the signature. A code reviewer skimming any one of those functions would see a plausible-looking validation step. The bypass only becomes visible when you trace the data flow end to end and notice the attacker controls an input — the key thumbprint — at exactly the point the server is deciding whom to trust. That’s the same class of mistake as a cloud IAM policy that looks locked-down clause by clause but composes into a privilege-escalation path nobody reviewed as a whole: individually reasonable checks don’t add up to a secure pipeline unless someone verifies the composition, not just the parts.