CVE-2026-55040: SharePoint's JWT Bypass Is a Patch Problem That Patching Won't Solve

The Short Version

A critical JWT authentication bypass in on-premises Microsoft SharePoint, tracked as CVE-2026-55040, moved from proof-of-concept to active exploitation in a matter of hours after the PoC went public. Rapid7 published a technical breakdown and a working exploit on GitHub, and within days security researchers were tracking real-world attacks against unpatched on-prem SharePoint servers, including cases where attackers forged administrator credentials with no password at all [1][2][3][6][11].

This is on-premises SharePoint. Organizations still running SharePoint Server internally, the kind that sits behind the firewall and rarely gets the attention Exchange or Active Directory does, are the ones exposed. If your client list includes anyone with an on-prem SharePoint farm, this is not a next-sprint item.

Microsoft has issued a fix [1]. That is the easy part of this story. The hard part is what happens to the environments that were exploited before the patch went in, because the vulnerability itself is not the only thing an attacker walks away with.

Why a Patch Doesn't Undo What Already Happened

CVE-2026-55040 lets an attacker bypass authentication by forging a JWT that SharePoint trusts, effectively minting an admin session without ever knowing a password [4][8]. Once that forged session exists, an attacker with administrative access to a SharePoint server can do what admins can do: read the ASP.NET machine keys used to sign and validate tokens, drop a web shell, create a scheduled task, or set up a second, quieter way back in.

We watched this exact pattern play out with the 2025 on-prem SharePoint exploitation wave, where attackers who compromised the ASP.NET machine key were able to keep forging valid authentication tokens even after the original vulnerability was patched, because the patch fixes the flaw in the code, not the fact that the attacker now holds the cryptographic keys used to sign trusted requests [13][15][17][18]. A machine key stolen on day one is still valid on day thirty unless someone rotates it. A web shell dropped during the window of exposure doesn't get removed by a Windows Update. And a session token forged before the patch landed doesn't expire just because the server is now running current code.

That is the uncomfortable truth of this class of vulnerability: patching stops new exploitation. It does nothing about existing exploitation. If an attacker was in your client's SharePoint environment between PoC publication and patch deployment, and given how fast this one moved from PoC to active attacks, that window may have been very short, the patch is necessary but nowhere near sufficient [15][16].

What Actually Needs to Happen, in Order

A partner triaging this for a client with on-prem SharePoint should be running through more than a patch ticket:

1. Patch the vulnerability. Apply Microsoft's fix. This closes the door for new exploitation attempts, full stop, do it first [1].

2. Assume compromise if the server was internet-facing and unpatched during the exploitation window. Given how quickly this PoC was weaponized, "we patched three days after disclosure" is not the same as "we were never exposed" [3][5][6][7][9].

3. Rotate the ASP.NET machine keys. This is the step everyone forgets and the one that actually matters. A stolen machine key lets an attacker keep forging valid tokens regardless of patch status. Rotating it invalidates every token signed with the old key, forged or legitimate [13][15][16].

4. Kill existing sessions. Forced re-authentication across the environment closes the gap between "we rotated the keys" and "someone was still using a session minted before we rotated the keys."

5. Hunt for web shells and scheduled tasks. Machine key theft is usually paired with a persistence mechanism dropped during the window of access. Finding and removing the persistence, not just the vulnerability, is what actually evicts the attacker [13][16][18].

6. Isolate before you investigate, not after. If there's active suspicion of compromise, network isolation of the affected server buys time to do steps 3 through 5 properly instead of racing an attacker who knows the clock started when the patch went public.

That's a lot of steps for a security bulletin most MSPs will initially read as "apply patch, close ticket."

This Is the Argument for a SOC That Acts, Not Just Alerts

Here's the part that matters for how you position this to clients, and it's not a hypothetical.

A monitoring tool that only alerts will flag the patch availability, maybe flag some suspicious authentication activity if it's looking in the right place, and then leave the response to whoever picks up the ticket. If that's a generalist admin working through a Monday morning queue, the machine key rotation step gets missed, because it's not obvious, it's not in the patch notes as "also do this," and it requires understanding that this specific vulnerability class leaves cryptographic material behind even after the code is fixed.

Vijilan's Global SOC is built around the containment step, not just the notification step. When an incident like this one presents, an admin session forged through a token bypass, a server showing signs of persistence, the SOC's job is to isolate the affected host, terminate active sessions, and drive the key rotation as part of the response, not as a footnote in an alert email hoping the client's IT team connects the dots at 2 a.m.

For MSSP and MSP partners reselling under Vijilan, this is the difference you're actually selling when a client asks what "managed" means. It's easy to promise 24/7 eyes on glass. It's a different promise to say the SOC will pull a forged session and rotate a compromised key without waiting for you to relay instructions back and forth while the attacker is still inside. ThreatRespond™, our Managed XDR service, is built for exactly this kind of identity-and-endpoint intersection, where the fix isn't purely a patch and isn't purely an EDR alert, it's both, coordinated, fast, and executed by people who've seen this exact pattern before.

We never compete with our partners for their clients. When a case like this lands, the containment work happens under your brand, on your relationship, with your client never knowing (or needing to know) that Vijilan is the SOC behind the curtain unless you want them to.

What to Tell Clients This Week

If you have clients running on-prem SharePoint, the conversation isn't "did you patch." It's "did you patch, rotate the keys, kill the sessions, and check for a web shell, in that order, and can you prove it." Most clients cannot answer that fourth question themselves. That's the gap a managed SOC exists to close.

If you're a partner wanting to know how ThreatRespond handles containment actions like this inside your existing stack, our MSP partner page walks through the model. If you're evaluating what this level of response actually costs against what a missed persistence mechanism costs, that conversation belongs on our pricing page, not buried in a vulnerability bulletin.

Frequently asked questions

Does patching CVE-2026-55040 remove an attacker who already got in?

No. The patch fixes the authentication bypass so new exploitation attempts fail, but it doesn't revoke session tokens or machine keys an attacker already stole during the exposure window. Those need to be separately rotated and invalidated.

What is a machine key and why does it matter here?

SharePoint uses ASP.NET machine keys to sign and validate authentication tokens. If an attacker steals the key during exploitation, they can keep forging valid tokens even after the underlying vulnerability is patched, because the key itself, not just the flawed code, is what needs to be replaced.

Is this the same as the 2025 SharePoint 'ToolShell' exploitation wave?

It's a different CVE, but the persistence pattern is the same: attackers use an authentication or code-execution flaw to gain admin-level access, then steal cryptographic material to maintain access beyond patching. The 2025 wave is exactly why security teams now treat machine key rotation as mandatory after any on-prem SharePoint compromise.

How fast did this vulnerability move from disclosure to active attacks?

Multiple outlets and researchers reported exploitation beginning within hours of the proof-of-concept exploit becoming public, which is an unusually short window even by current standards for weaponizing disclosed vulnerabilities.