CVE-2026-55040: SharePoint's JWT Bug Lets Attackers Forge Any User's Identity

An attacker who has never logged into your SharePoint server can now become anyone who has, admin included, without a password, a phishing email, or a stolen session cookie. CVE-2026-55040 is a weak-authentication flaw in how on-premises SharePoint validates JSON Web Tokens, and it’s already being exploited in the wild. If you run SharePoint Enterprise Server 2016, SharePoint Server 2019, or SharePoint Server Subscription Edition anywhere in your infrastructure, this is the patch to check today, not next sprint.

What the bug actually does

SharePoint uses JWTs internally to represent an authenticated session: a signed token that says, in effect, “this request comes from user X, and here’s the cryptographic proof.” CVE-2026-55040 breaks that proof. Technical analysis from Rapid7 found that the flaw isn’t one bug but a chain of four separate weaknesses in the JWT validation path, CWE-1390, weak authentication, in CISA’s classification, and together they let an attacker construct a token SharePoint accepts as genuine without ever authenticating.

The practical result: send SharePoint a forged token naming any user, and the server treats subsequent requests as if that user issued them. There’s no password check, no MFA prompt, no session to steal, because the attacker never needed a real session in the first place.

Normal flow:   User logs in → SharePoint issues signed JWT → JWT proves identity on each request
CVE-2026-55040: Attacker crafts JWT → SharePoint's validation chain fails to catch the forgery
                → Attacker's requests are treated as the impersonated user's requests

The one thing an attacker does need is the target username. That’s a real constraint, but not much of one against most SharePoint farms: admin accounts, service accounts, and IT staff usernames tend to follow predictable patterns or are simply known from prior reconnaissance. Once the attacker picks a target with elevated privileges, forging that identity gets them the same access the real user has, site content, document libraries, and depending on configuration, broader farm administration.

Why it scored 9.1 and landed on the KEV list fast

CVSS 9.1 reflects the combination that makes this kind of bug dangerous: no authentication required, no user interaction required, and a direct path to impersonating a privileged account over the network. SharePoint farms are also disproportionately internet-facing, organizations expose them specifically so remote staff and partners can reach documents and workflows, which means the attack surface for this bug is wide by design, not by misconfiguration.

The exploitation timeline moved fast even by 2026 standards:

Date	Event
Aug 11	Rapid7 publishes technical details of the JWT validation chain
Aug 11–14	Attackers begin active exploitation using the disclosure as a blueprint
Aug 18	CISA adds CVE-2026-55040 to the Known Exploited Vulnerabilities catalog
Aug 21	Federal civilian agency remediation deadline

Three days from public technical disclosure to confirmed in-the-wild exploitation is consistent with what’s become the normal pattern for on-prem enterprise software this year: once a researcher publishes enough detail to reconstruct the exploit, opportunistic scanning starts within days, sometimes hours. If your SharePoint patch cycle assumes weeks of runway after disclosure, that assumption stopped holding some time ago. It’s the same compressed window we covered with the Cisco ASA and FTD VPN flaw earlier this month, exploited within days of the advisory going public.

What’s affected, and what isn’t

This is strictly an on-premises issue:

• Affected: SharePoint Enterprise Server 2016, SharePoint Server 2019, SharePoint Server Subscription Edition.
• Not affected: SharePoint Online, the cloud-hosted service inside Microsoft 365. It runs on a different, unified identity stack (Entra ID) and doesn’t share the on-prem JWT validation code path this flaw lives in.

If your organization has fully migrated to SharePoint Online, you can rule this one out. If you’re running a hybrid setup, on-prem SharePoint for some workloads alongside Microsoft 365 for others, only the on-prem instances are exposed, but that’s usually enough to be a serious problem: on-prem SharePoint deployments frequently sit closer to internal file shares, legacy integrations, and service accounts with broader network reach than a typical cloud tenant.

What to do about it

Patch first. Microsoft has published the fix; apply it to every on-premises SharePoint server in your environment, not just the internet-facing ones. Because the forged-token attack impersonates a specific user rather than exploiting a network-position weakness, an internal-only SharePoint server is not automatically safe if an attacker has already gained any foothold that lets them reach it.

There’s no meaningful workaround. Unlike some vulnerabilities where disabling a specific feature closes the hole, this one lives in the core authentication path. You can’t selectively turn off JWT validation and keep SharePoint functional. If you genuinely cannot patch within the next day or two, the next best step is reducing exposure: pull internet-facing SharePoint behind a VPN or restrict it to known IP ranges until the patch is applied, understanding that this only reduces the attacker population, not the underlying risk from anyone who already has network access.

Check for signs of prior exploitation. Given the compressed window between disclosure and active attacks, review authentication and access logs for anomalous administrative actions in the days since August 11, particularly any admin-level activity that doesn’t correlate with a real login event, since a forged-token session won’t show up in your logs the way a normal login does.

Rotate anything a compromised admin session could have touched. If you find evidence of exploitation, or can’t rule it out with confidence, treat it the way you’d treat a confirmed admin account compromise: rotate credentials, service account secrets, and any API keys that SharePoint’s admin identity had access to, and audit for persistence mechanisms an attacker might have planted while impersonating that identity.

The takeaway

CVE-2026-55040 is a reminder that authentication bugs in enterprise collaboration platforms carry more weight than the software’s day-to-day reputation suggests, because these systems sit at the center of document access, internal workflows, and often broader identity trust than a typical internet-facing app. The fix here is straightforward and already available; the risk is in the gap between “the patch exists” and “every affected server actually has it.” If you’re auditing exposure across a fleet of on-prem systems and need a second set of eyes on what’s internet-facing and what isn’t, that kind of infrastructure review is part of the security work our team does for clients running mixed on-prem and cloud environments.