CRITICAL: SharePoint CVE-2026-55040 Exploited After Public PoC Release

There is a specific kind of dread that comes from watching a working exploit land on GitHub for a bug you have not gotten around to patching. Anyone still running SharePoint Server on their own hardware got to feel it this week, and the window between publication and attack was about as narrow as these things ever get.

Microsoft fixed CVE-2026-55040 back in the July 2026 Patch Tuesday batch. It went out carrying a CVSS score of 9.1 and the usual restrained advisory language about a security feature bypass, and then it sat there for four weeks while most of the industry looked at flashier bugs. On August 11, Rapid7 published a full technical analysis of the flaw along with a working proof of concept script. Roughly one day later, honeypots started catching people using it.

The telemetry so far is small, but the shape of it tells you everything. KEVIntel recorded twelve exploitation attempts since July 19, 2026, and eight of those twelve arrived on August 12 and 13 alone, from eight unique IP addresses tied to Hong Kong, Japan, the Netherlands, Taiwan, and the United States. That is not a flood. That is the part right before the flood, when a handful of operators quietly confirm the exploit works before it gets folded into everybody else's tooling.

What the bug actually does

The vulnerability is an authentication bypass in how SharePoint validates JSON Web Tokens, formally classified as CWE-1390, weak authentication. Microsoft's own description is almost polite about it. The advisory notes that the authentication feature could be bypassed because the vulnerability allows impersonation, and adds that exploiting it could allow an attacker to disclose files and modify data, but that the attacker cannot impact the availability of the system. That last clause is the entire reason the score landed at 9.1 instead of 9.8. The CVSS 3.1 vector, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, hands out full marks for confidentiality and integrity impact and nothing at all for availability. Network reachable, low complexity, no privileges required, no user interaction. An attacker needs a route to the server and nothing else.

Part of what makes this one instructive is how thoroughly it slipped past everybody in July. Microsoft categorized it as a security feature bypass rather than remote code execution, and in the triage math most organizations actually run, a bypass without an RCE tag slides down the queue even when the CVSS number is screaming. It shipped inside a Patch Tuesday rollup, which is where genuinely dangerous bugs go to hide. Four weeks later Rapid7 supplied the missing context, and the calculus changed overnight. This is roughly how it goes every single time.

Rapid7's analysis is where the story gets genuinely embarrassing, because this is not one mistake. It is four of them, stacked, each individually survivable and collectively fatal. The trouble lives in two handler classes, SPJsonWebSecurityTokenHandlerV2 and SPJsonWebSecurityBaseTokenHandlerV2, along with SPApplicationAuthenticationModuleV2.

The first weakness is that the code explicitly sets RequireSignedTokens to false, which instructs the underlying JWT library to accept a token carrying the alg none header without performing any cryptographic verification whatsoever. The second is that SharePoint pulls the x5t certificate thumbprint straight out of the attacker supplied actor token and uses it to resolve a signing key through SPIssuerTokenResolver, without ever checking that actor token's own signature against that key. The third is that when the resolved certificate fails to match anything listed in TrustedSecurityTokenServices, the ValidateIssuer routine accepts it unconditionally rather than rejecting it, which very conveniently lets SharePoint's own STS certificate sail right through. The fourth is that GetTokenSignature checks only that a signature string exists at all. Four characters of nonsense like AAAA satisfies it. Nobody ever verifies the thing.

Chain those four together and an unauthenticated attacker forges a JWT that SharePoint cheerfully accepts as any user it likes, up to and including a site administrator. Rapid7's own summary is that the chain allows a remote, unauthenticated attacker to forge a valid JWT and impersonate any SharePoint site user.

How exploitation looks in the wild

In practice the attack opens quietly. The endpoint at /_layouts/15/metadata/json/1 serves up metadata without requiring authentication, which gives an attacker what they need to start assembling a token. From there the forged JWT goes to /_api/web/currentuser to confirm the impersonation took, then to /_api/contextinfo to collect a form digest value, and after that every authenticated SharePoint REST endpoint is on the menu. Read documents, enumerate and modify list items, pull down whatever the impersonated account can reach.

That matters more than a dry description of impersonation suggests. For most organizations, SharePoint is where the signed contracts, the HR files, the internal wikis, the board decks, and the half forgotten spreadsheet full of service account credentials all quietly coexist. It is a content repository that grew into an institutional memory, and almost nobody has audited what is actually sitting in it since the migration. An attacker impersonating an administrator does not need to escalate anywhere. They are already standing in the vault.

Affected builds cover the on-premises product line. SharePoint Server 2016 Enterprise is vulnerable before build 16.0.5561.1001, SharePoint Server 2019 before 16.0.10417.20175, and SharePoint Server Subscription Edition before 16.0.19725.20434. If your organization lives entirely on SharePoint Online, Microsoft handled this on their side and you can go back to your coffee. If you have on-premises servers, particularly ones reachable from the internet because somebody in 2019 needed extranet access for a partner portal and nobody ever turned it off, this is a drop everything and patch it now situation.

SharePoint has been down this exact road recently enough that the muscle memory ought to still be there. The ToolShell chain in July 2025 turned unpatched on-premises SharePoint into a mass compromise event, with government agencies and large enterprises alike getting cleaned out before patching caught up. The lesson then was that an internet-facing SharePoint farm is a liability with a very short fuse the moment technical details go public. The lesson has not changed, and neither, apparently, has the industry's ability to act on it inside of four weeks.

There is also a chaining angle worth taking seriously. Guidance from NHS England Digital, cited alongside this week's exploitation reporting, notes that CVE-2026-55040 combined with CVE-2026-63520 could lead to unauthenticated remote code execution. An authentication bypass on its own is bad enough. An authentication bypass that serves as the foothold for code execution is how incident response weekends get scheduled.

What to do about it

The fix is unglamorous. Apply the July 2026 SharePoint security updates and then actually confirm that your build numbers moved, because SharePoint patching has a long and proud tradition of appearing to succeed while quietly leaving one server in the farm behind. Check every web front end, not just the one you remember standing up. Verify against the build numbers above rather than trusting the update history dialog.

If patching genuinely cannot happen today, CISA's standing hardening guidance applies. Do not expose SharePoint Server directly to the internet unless there is a real, documented business reason, and put a layer seven reverse proxy or an application layer gateway that enforces authentication in front of anything that has to stay reachable. Neither of those is a fix. Both of them buy time, which is the commodity in shortest supply right now.

On detection, there is a decent amount to work with. Requests to /_layouts/15/metadata/json/1 originating from outside your normal client population are worth flagging, especially when the same source address follows up moments later with calls to /_api/web/currentuser or /_api/contextinfo. Any JWT presented with an alg value of none should be treated as hostile on sight, because no legitimate SharePoint client sends one. IIS logs and ULS logs read together will surface authenticated REST activity with no corresponding sign in event, which is the clearest tell for a forged token. If you run EDR or ship SharePoint logs to a SIEM, build that correlation now rather than after a client asks whether they were affected.

And if your servers were internet-facing and unpatched at any point between August 11 and today, treat this as a threat hunt rather than a patch exercise. Twelve recorded attempts is what a honeypot network saw. It is not a census. The absence of an alert in your environment is not evidence of the absence of a visitor.

For MSPs, this is about as clean a conversation starter as the calendar produces. An external attack surface review that turns up an internet exposed SharePoint farm justifies both an immediate remediation engagement and an ongoing vulnerability management retainer, and the four week gap between Microsoft's July patch and this week's exploitation is the most persuasive argument you will ever get for why patch verification deserves to be a billed service rather than a quiet assumption. For any client who was exposed during the proof of concept window, attach a compromise assessment, because nobody enjoys discovering a forged token six months later in the middle of an audit.

Publishing the analysis was the right call, for whatever it is worth. Defenders needed to understand why a security feature bypass rated 9.1 deserved considerably more attention than it received in July, and the four stacked weaknesses Rapid7 documented are a useful reminder that authentication code tends to fail in layers rather than all at once. The uncomfortable part is that the same document tells attackers precisely the same thing, and attackers read faster. Patch the farm.