Rapid7’s PoC triggers active exploitation of the SharePoint authentication bypass (CVE-2026-55040)

July 14, 2026. Microsoft patches CVE-2026-55040, an authentication bypass in SharePoint Server reported by Rapid7. August 11, 2026. Researcher Stephen Fewer of Rapid7 publishes the full technical analysis and a proof of concept. August 13, 2026. Threat intelligence firm Defused reports that attackers are already using that PoC against its SharePoint honeypots. In eleven days, a “fixed” flaw became an active vector again.

The story carries a lesson that goes beyond SharePoint: a patch is a step, not a conclusion. And the flaw itself is a case study in how a JWT validation chain can fail four times in a row without ever throwing an error.

A chain of four weaknesses, not a single flaw

Fewer decompiled the Microsoft.SharePoint.IdentityModel module from a fully patched SharePoint Server Subscription Edition instance (version 16.0.19725.20210). The bypass rests not on one spectacular bug but on four weaknesses that, combined, let a remote unauthenticated attacker forge a valid JWT and impersonate any site user.

SharePoint’s S2S (service-to-service) authentication uses a nested JWT: an outer token carrying the user’s identity, and an inner actor token expected to be signed by a trusted certificate. That is where everything plays out.

• Weakness 1 — signatures are disabled. In SPJsonWebSecurityTokenHandlerV2.ValidateToken(), the line val.RequireSignedTokens = false; disables cryptographic verification of the outer token. The library then accepts an alg: none header: no signature check on the main token at all.
• Weakness 2 — the key is resolved without verification. The actor token points to its signing key via the x5t (certificate thumbprint) header, an attacker-controlled value. The resolver searches trusted certificates for a match — including SharePoint’s own local STS certificate, retrievable unauthenticated from the /_layouts/15/metadata/json/1 endpoint.
• Weakness 3 — the issuer is accepted by default. ValidateIssuer() unconditionally accepts an issuer whose certificate is not in the TrustedSecurityTokenServices collection. Referencing the local STS certificate via x5t therefore passes issuer validation without any real check.
• Weakness 4 — the signature is never checked. GetTokenSignature() only requires a non-empty signature. An actor token signed AAAA is enough: the value is never matched against a real RSA verification.

The line that sums it all up, extracted from the decompiled code:

// SPJsonWebSecurityTokenHandlerV2.cs — ValidateToken()
val.RequireSignedTokens = false;

Once validation passes, the outer token’s nameid claim — an attacker-controlled Windows SID or UPN, or even the local service identity — is resolved into a user identity. Rapid7’s PoC demonstrates all three mechanisms.

The deepest technical lesson lies elsewhere: validation rested on four independent assumptions, and none checked the other. A correct implementation should have rejected the token at the first weakness; here, every link gave way in turn. This is exactly the kind of chain that code reviews and audits of authentication libraries are meant to catch — and that a monthly patch cannot fix on its own.

A public PoC, exploitation within hours

The timeline is the worrying part. Fewer published his analysis on August 11 on the Rapid7 blog, alongside the script on GitHub (sfewer-r7/CVE-2026-55040). Less than two days later, on August 13, Defused reported that actors were using the PoC against its SharePoint honeypots.

Exploitation starting that fast after publication is hardly surprising: the PoC requires no prior access, and the attack surface — exposed SharePoint Server instances — is vast and heterogeneous. Microsoft, for its part, describes the impact with significant restraint: the bypass allows impersonation, disclosing files, and modifying data, but “the attacker cannot impact the availability of the system.” Microsoft has not confirmed in-the-wild exploitation, even as it flags the flaw as a likely target.

The gap between PoC publication and mass scanning, once measured in weeks, is now measured in hours — and SharePoint honeypots are the canary.

The amplifier: chaining toward RCE

On its own, CVE-2026-55040 is already serious. But it does not stop there. Combined with CVE-2026-63520, a SharePoint RCE also discovered by Rapid7, the authentication bypass “could lead to unauthenticated remote code execution against a vulnerable SharePoint server,” according to NHS England Digital. The pair features in our August Patch Tuesday analysis.

This is the classic chaining pattern: the auth bypass provides the identity, the RCE provides the commands. CISA, for its part, has urged administrators to harden their SharePoint deployments, citing active exploitation of several other vulnerabilities in the platform. The implicit message is clear: an internet-exposed SharePoint Server is a priority target, and the list of exploitable flaws grows every week.**

One nuance worth keeping straight: the bypass grants the identity of a SharePoint site user or administrator, within the scope of the site collection the token targets. It is not, by itself, farm-level code execution — which is precisely why the chain with CVE-2026-63520 matters. Alone, the flaw is a data-disclosure and tampering risk; chained, it becomes an entry point to the server.

What to do about it, concretely

The July 2026 patch exists and must be applied — but it is not enough, since unpatched or poorly exposed instances are precisely the ones attackers are hitting. The response plays out at three levels.

• Patch and verify. Apply the July 2026 update to every SharePoint Server farm, then confirm it is applied — a farm that “received” the patch without a full service restart remains vulnerable.
• Reduce exposure. CISA’s guidance is blunt: avoid exposing SharePoint Server directly to the internet; if you must, place it only behind a Layer 7 reverse proxy that requires authentication and can inspect and filter requests.
• Watch the chains. Track alerts on CVE-2026-63520 and treat the pair as a single attack scenario — the auth bypass is only a stepping stone to RCE.
• Detect. A legitimate S2S access carries a verified signature; watching ULS logs and abnormal authentication attempts on the farms helps spot forged tokens — even if, without the patch, a well-built token leaves no error trace.

The detail that matters: the bypass works without any interaction and without credentials. Classic perimeter controls (MFA, password complexity) change nothing. The only effective barrier, short of the patch, is to take the server out of direct exposure.

Verdict

CVE-2026-55040 is not the most sophisticated zero-day of the year — it is worse in its own way. It is a flaw patched since July, whose public PoC was enough to restart exploitation within two days, because the patch had not yet been applied everywhere and the exposed surface remains enormous. Its gravity lies less in the code than in the gap between “fixed at the vendor” and “fixed at your end.”

The recommendation is conditional and blunt. If you run an internet-exposed SharePoint Server, treat applying the July patch as today’s emergency, and put it behind an authenticating reverse proxy right now — the PoC is circulating and honeypots are already seeing it arrive. If your SharePoint servers are internal, apply the patch at the next window, but do not lower your guard: the chain with CVE-2026-63520 turns an identity flaw into code execution, and it is inside “trusted” networks that this chaining does the most damage.

References

• Attackers exploit critical SharePoint flaw after PoC goes public (CVE-2026-55040) — Help Net Security, August 13, 2026
• Rapid7 Analysis: Microsoft SharePoint JWT Token Authentication Bypass (CVE-2026-55040) — Rapid7, August 11, 2026
• CVE-2026-55040 — Microsoft Security Response Center
• CISA urges SharePoint hardening after new exploitations — CISA