TL;DR

CVE-2026-55040 is a CVSS 9.1 weak-authentication flaw (CWE-1390) in the JSON Web Token validation pipeline used by on-premises Microsoft SharePoint Server. An unauthenticated, remote attacker who can supply a target’s AD SID or UPN can forge a JWT that SharePoint accepts as valid, and operate as that user — including a site administrator. No credentials, no session cookie, no prior access required. CISA added it to the Known Exploited Vulnerabilities catalog on August 18, 2026, with a remediation deadline of August 21 that has already passed. If you run on-prem SharePoint and the server is reachable from the network, the deadline has lapsed and you should be checking your build number now.

This is worth writing about twice. First, the specific: an internet-facing SharePoint farm is now a confirmed exploitation target with public PoC code. Second, the general: this is the fourth time in a row that a JWT or token-validation pipeline has been the entry point to a serious breach, and the same four mistakes keep appearing.

The vulnerability

Rapid7 Labs found the bug as part of a zero-day research project built for the Pwn2Own Berlin competition and disclosed it jointly with Microsoft on July 14, 2026 — patched the same day in that month’s Patch Tuesday. The disclosure of the second half of the chain (the RCE) and a working PoC landed on August 11. CISA’s KEV addition followed on August 18.

SharePoint’s REST API and internal service-to-service calls authenticate partly through bearer JWTs. The validation pipeline is supposed to do two things: cryptographically verify the token’s signature, and verify the identity of the issuer. CVE-2026-55040 breaks that pipeline in four separate places at once.

  • Signature verification disabled by default. The validation code sets RequireSignedTokens = false. A token with alg: none in its header skips signature validation on the outer JWT entirely. An attacker can hand-craft a token with no signature and have it accepted as structurally valid.
  • The actor token’s key is resolved from the token itself, never verified. In SharePoint’s delegated (service-to-service) model, the “actor token” carries an x5t (certificate thumbprint) header. The code uses that thumbprint to look up the signing key — but it trusts the thumbprint the attacker supplied and never actually verifies the signature against the resolved key.
  • Fail-open issuer check. When the certificate resolved from the thumbprint is not found in SharePoint’s TrustedSecurityTokenServices collection — i.e., it is not a certificate SharePoint actually trusts — the logic accepts the issuer anyway. The intended fail-closed behavior is inverted into fail-open.
  • The signature check is not cryptographic. GetTokenSignature() checks that a signature field is a non-empty string. Any placeholder satisfies it.

Any one of those four, alone, might have been contained. Together they let an unauthenticated attacker forge a token the server treats as legitimate. The attacker’s only real prerequisite is knowing the identity they want to become — an AD SID or a UPN in the form user@domain. Rapid7’s PoC enumerates candidate users via SID discovery and then assumes the site-admin identity.

Why it’s 9.1, and what’s missing from the score

Microsoft’s CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — 9.1, Critical. Network, low complexity, no privileges, no user interaction, high confidentiality and integrity impact, no availability impact. That’s an accurate base score for the auth bypass on its own.

But the CVSS understates the practical risk, and it’s important to say why. The bypass hands the attacker authenticated access. And once you’re authenticated as the site administrator, you’re standing at the door of the Business Connectivity Services (BCS) attack surface — a separate RCE, CVE-2026-63520 (CVSS 8.1, disclosed August 11) where an unvalidated, attacker-controlled type name lets a malicious BDC model instantiate a deserialization gadget (System.Web.UI.LosFormatter). VulnCheck has published a working exploit that chains the two: unauthenticated RCE against the farm, no credentials, no session, no prior access.

So the real threat model is a two-hop chain, and a single CVSS line on the first hop doesn’t capture it. This is the same dynamic as every “auth bypass → RCE” pair: the first flaw is the door, the second is the room, and the CVSS on the door is the number most people will patch against.

Affected and fixed

On-premises editions only. SharePoint Online (Microsoft 365) is not affected. If your deployment is entirely online, you’re out of scope for this specific flaw — though you should still read the rest, because the JWT lesson applies to any token pipeline you run.

For the on-prem versions, the fixed builds for CVE-2026-55040 (auth bypass) are:

Edition Fixed build KB
SharePoint Server Subscription Edition 16.0.19725.20434 KB5002882
SharePoint Server 2019 16.0.10417.20175 KB5002883
SharePoint Enterprise Server 2016 16.0.5561.1001 KB5002891

If you also want the RCE (CVE-2026-63520) closed, the fixed builds are a step higher: SE 16.0.19725.20522, 2019 16.0.10417.20198, 2016 16.0.5565.1001. Patch both if you can — closing only the auth bypass leaves the BCS RCE reachable by any legitimately authenticated path, and patching the BCS RCE without the auth bypass leaves the unauthenticated door open.

The exposure math

Censys counted roughly 329,000 SharePoint instances on the internet as of August 25, of which about 21,000 are on-premises deployments that expose version numbers. SharePoint is not a niche product. It is the default enterprise collaboration and document-management layer in a huge share of on-prem Microsoft estates, and a large fraction of those are internet-facing for remote access — often behind an SSO or reverse proxy that does not actually remove the exposure. An internet-reachable SharePoint farm with an unpatched JWT handler is exactly the asset an attacker enumerates first, because it’s common, it’s high-value, and the exploit is public.

What to do

  1. Inventory your SharePoint and check the build number, not the product name. The July fixes advance only the final revision within each existing build branch. A check that resolves version at a coarser level (major.minor, or just “SharePoint 2019”) will not distinguish a patched farm from an unpatched one. You need the full build, and you need it on every server in the farm — a partially patched farm is still exposed.
  2. Verify the post-install configuration actually applied. Microsoft’s fix requires completing the post-installation steps. A build number that’s right but a config that didn’t land is the same as not patching at all.
  3. Reduce direct internet exposure where you can. CISA’s guidance is to avoid exposing SharePoint Server directly to the internet; where exposure is required, put it behind a Layer 7 reverse proxy or equivalent that requires authentication and can inspect and filter requests. This is a mitigation, not a fix — the proxy has to actually enforce auth, not just sit there.
  4. Hunt for exploitation, because the deadline passed. The KEV due date (August 21) has lapsed and public PoC code has been available since August 11. Review SharePoint and identity logs for the signature of token forgery: an unauthenticated request that produces an authenticated session, a bearer token with alg: none or a non-trusted issuer certificate, and admin-level operations without a corresponding login. Assume it’s happened somewhere in the wild.
  5. If you can’t patch immediately, treat it as an incident. For a KEV-listed flaw with public exploit and a passed deadline, “we’ll patch next month” is no longer a defensible posture. If you can’t close it quickly, restrict the network path to the farm and consider whether the exposure is worth it.

The broader lesson: JWT pipelines fail the same four ways

The specific SharePoint bug is the news. The pattern is the lesson, and I want to name it, because it keeps recurring.

Token-based authentication is a trust decision made by code that parses an untrusted structure. A JWT is a self-describing, signed (supposedly) token. The entire security of the scheme rests on the validation pipeline doing four things right, and CVE-2026-55040 is a clean catalog of what happens when each of them is skipped:

  1. Verify the signature. (RequireSignedTokens was off. alg: none was accepted.)
  2. Verify the key came from a trusted source, not from the token itself. (The x5t thumbprint was attacker-supplied and trusted.)
  3. Fail closed when you don’t recognize the issuer. (Unknown certificate → accepted.)
  4. Make the signature check cryptographic, not a string presence check. (Non-empty string passed.)

If you build or audit any token-validation path — JWT, SAML, OIDC, mTLS session tokens, service-to-service bearer tokens — these four are your checklist. Miss #1 and alg: none is your RCE. Miss #2 and the token carries its own key. Miss #3 and “unknown issuer” becomes “any issuer.” Miss #4 and the signature is decoration.

I’ve written about OAuth access tokens and identity before, and this is the same family: the credential is only as strong as the code that validates it, and the validation code is where the bugs live, not the token format. JWT is not unsafe. Untested, fail-open JWT validation is unsafe.

The takeaway

Patch the build, on every farm, with the post-install config confirmed. Then close the exposure window by moving SharePoint behind real authentication, and hunt the logs for the forgery signature while the exploit is fresh and public.

And keep the four-failure checklist in your back pocket. The next token pipeline that skips any of them is the next 9.1 with a public PoC and a passed KEV deadline.

References