CVE-2026-55040: SharePoint JWT Forgery Lets Attackers Impersonate Any User

Background

On-premises SharePoint Server remains widely deployed across enterprises that haven’t fully migrated to SharePoint Online, often hosting internal document repositories, intranets, and business-critical workflow integrations. Authentication for SharePoint’s REST and internal service-to-service APIs relies partly on JSON Web Tokens, validated by a pipeline that’s supposed to cryptographically verify both the token’s signature and the identity of the issuer before granting access.

CVE-2026-55040, disclosed jointly by Rapid7 and Microsoft on July 14, 2026, and patched the same day as part of that month’s Patch Tuesday, breaks that pipeline in four separate places at once. Any one of the four weaknesses alone might have been contained; together they let an unauthenticated, remote attacker forge a JWT and impersonate any SharePoint user — including site administrators — with no credentials at all. CISA added the CVE to its Known Exploited Vulnerabilities catalog on August 18, 2026, with a remediation deadline of August 21.

Technical Mechanism

CWE-1390 (Weak Authentication) is the classification, but the underlying issue is really a chain of four independent validation failures in SharePoint’s JWT handling, documented by Rapid7’s technical analysis:

Weakness 1 — Disabled signature verification. The validation code explicitly sets RequireSignedTokens = false, which means a token using alg: none in its header skips cryptographic signature validation on the outer JWT entirely. An attacker can hand-craft a token with no signature and have it accepted as structurally valid.

Weakness 2 — Unverified actor token resolution. SharePoint’s delegated authentication model uses an “actor token” to represent service-to-service calls. The validation logic resolves the actor token’s signing key using the x5t (certificate thumbprint) header from the token itself — but never actually verifies the token’s signature against the key it resolves. The attacker supplies the thumbprint; the system trusts it.

Weakness 3 — Flawed issuer validation. When the certificate resolved from that thumbprint isn’t found in SharePoint’s TrustedSecurityTokenServices collection — i.e., it’s not a certificate SharePoint actually trusts — the validation logic unconditionally accepts the issuer anyway rather than rejecting the unrecognised certificate. This inverts the intended fail-closed behaviour into fail-open.

Weakness 4 — Non-cryptographic signature check. The GetTokenSignature() method, which should be validating that a signature is cryptographically correct, only checks that a signature field is a non-empty string. Any placeholder value satisfies it.

Chained together: an attacker crafts a JWT with alg: none, supplies an arbitrary certificate thumbprint for actor token resolution, relies on the unconditional issuer acceptance for unregistered certificates, and pads a non-empty placeholder into the signature field. The result is a forged token that SharePoint accepts as a legitimate, signed assertion of any identity the attacker specifies — including administrative accounts — submitted through standard REST API endpoints.

Real-World Exploitation Evidence

The exploitation curve here tracks the public availability of tooling closely. Between the July 14 disclosure/patch and the August 11 release of Rapid7’s proof-of-concept, only four exploitation attempts were recorded — consistent with limited attacker capability to independently reconstruct a four-stage chain from the advisory alone.

That changed immediately once the PoC went public on August 11. Attackers began running the Rapid7 PoC against SharePoint honeypots within a short window of release, and CISA’s KEV addition followed a week later on August 18. The pattern is a now-familiar one for high-severity, publicly disclosed authentication bypasses: patch-to-PoC gap buys defenders time, but only if they use it, and PoC-to-exploitation gap is now measured in hours to days rather than weeks.

Impact Assessment

Successful exploitation grants an unauthenticated attacker the ability to impersonate any SharePoint site user, up to and including site administrators, through standard REST API calls — no phishing, no credential theft, no prior foothold required.

For an organisation running affected on-premises SharePoint versions, this means:

• Full read/write access to any document library, list, or site the impersonated identity can reach
• Administrative operations including permission changes, user management, and site configuration
• Potential access to sensitive documents, internal communications, and business data stored in SharePoint
• A plausible pivot point into connected systems if SharePoint holds service account credentials or API keys used for integrations
• Difficulty distinguishing forged-token activity from legitimate administrative action in standard audit logs, since the forged token presents as a valid, signed identity assertion

Affected Versions

SharePoint Online (Microsoft 365) is not affected; this is an on-premises-only vulnerability.

Remediation Steps

1. Apply the July 2026 security update immediately if not already deployed. Given the PoC is now public and actively used, treat any unpatched on-premises SharePoint instance as under active threat.

2. Audit administrative actions since August 11, 2026 for anomalies — permission grants, new site collection administrators, or configuration changes that don’t correlate with known change requests. Forged-token activity will present as legitimate admin actions in standard logs, so cross-reference against your change management records rather than relying on log review alone.

3. Review TrustedSecurityTokenServices configuration to confirm only expected certificates are registered, and investigate any evidence of unfamiliar certificate thumbprints appearing in authentication logs.

4. Rotate service account and API credentials stored in or accessible from SharePoint if compromise is suspected, given the potential for administrative-level access.

5. Restrict SharePoint REST API exposure to internal networks or VPN-only access where business requirements allow, reducing the population of potential attackers to those with existing network access.

Detection Guidance

Application log indicators:

Look for authentication events showing successful token validation with unusual or unrecognised certificate thumbprints in the x5t header, particularly where the resolved certificate does not correspond to a known, registered trusted security token service.

Anomalous privilege indicators:

Flag any account performing administrative actions (permission changes, user additions, site collection administration) that has no corresponding interactive login event or multi-factor authentication challenge in the same session — forged tokens bypass the normal login flow entirely.

SIEM query (generic web/application log):

uri_path:(*/api/* OR */_vti_bin/*)
AND event_type:auth_success
AND NOT prior_event:interactive_login
| stats count by user_identity, src_ip

Any identity showing API-authenticated administrative activity without a preceding interactive authentication event in the same window warrants investigation.

Network indicators:

Requests to SharePoint REST API endpoints carrying JWTs with alg: none in the decoded header should not appear in legitimate traffic and are a direct indicator of exploitation attempts.

Timeline

References

• Rapid7 — CVE-2026-55040 Microsoft SharePoint JWT Token Authentication Bypass (Technical Analysis)
• Rapid7 — CVE-2026-55040 Microsoft SharePoint JWT Token Authentication Bypass (Fixed)
• The Hacker News — Attackers Exploit SharePoint Authentication Bypass After Public PoC Release
• CISA — Known Exploited Vulnerabilities Catalog