Nobody Stole a Password: CVE-2026-55040 Lets Attackers Mint a SharePoint Admin

On August 12 and 13, 2026, the exploitation tracker KEVIntel logged eight attacks against Microsoft SharePoint servers. That is not a big number. What matters is the window: those eight landed in the 48 hours right after Rapid7 published a working proof of concept, and they made up two thirds of the twelve total attempts recorded since mid-July, from eight unique IP addresses across Hong Kong, Japan, the Netherlands, Taiwan and the United States.

The bug is CVE-2026-55040, CVSS 9.1, patched in Microsoft's July 2026 Patch Tuesday and added to CISA's Known Exploited Vulnerabilities catalog on August 18 with a remediation deadline of August 21 under BOD 26-04. Three days. Shadowserver currently tracks more than 8,700 SharePoint servers reachable from the internet.

I want to argue that the interesting part of this vulnerability has almost nothing to do with SharePoint, and everything to do with an assumption baked into most identity detection programs: that to act as a user, an attacker first has to obtain something belonging to that user. CVE-2026-55040 skips that step entirely. The attacker does not steal an admin credential. They print one.

Four failures, stacked

Rapid7's Stephen Fewer, who found and disclosed the flaw, describes it as a chain of four separate weaknesses in SharePoint's JWT validation pipeline, spread across the SPJsonWebSecurityTokenHandlerV2 and SPJsonWebSecurityBaseTokenHandlerV2 classes. Read them in order, because each one on its own is survivable and together they are fatal:

1. val.RequireSignedTokens = false. Signature verification on the outer token is switched off. A token with alg: none is accepted.
2. The inner actor token's x5t header is used to resolve a signing key, but the actor token's signature is never checked against that key.
3. When the resolved certificate is not present in TrustedSecurityTokenServices, the issuer is accepted unconditionally instead of being rejected.
4. GetTokenSignature confirms that a signature string is non-empty. It performs no cryptography at all.

So the attack is this. Fetch the SharePoint Security Token Service signing certificate from /_layouts/15/metadata/json/1, an endpoint that hands it to anonymous callers by design. Take its thumbprint. Build a JWT with alg: none, set the actor token's x5t to that thumbprint, and name whichever SID or UPN you want to be. SharePoint resolves the key, never verifies anything, and issues you a session. Microsoft's own advisory language is unusually blunt: "the authentication feature could be bypassed as this vulnerability allows impersonation."

There is no password involved. No hash, no Kerberos ticket, no OAuth grant, no phishing page. The server signs off on your claim to be the site administrator because the code path that was supposed to disagree with you was never wired up.

Three detections this quietly kills

Here is where it stops being a SharePoint story. Most identity detection stacks I see are built on three load-bearing assumptions, and a forged token breaks all three at once.

Failed logins precede successful ones. Password spraying, credential stuffing and brute force all generate noise before they generate access. That noise is the signal most SIEM identity rules are tuned on. A forged JWT produces a single clean authentication with a valid-looking token. Zero failures. The ratio your detection depends on never moves. We covered the inverse case in our teardown of the LSHIY ROPC campaign, where the noise existed but conditional access had been told to ignore it. Here there is no noise to ignore.

Anomalous credential use looks anomalous. Impossible travel, new device, unusual sign-in location: these all key off an identity provider's view of an authentication event. On-premises SharePoint STS is not Entra ID. It does not feed your risky sign-in detections, it does not evaluate conditional access, and it does not care whether the impersonated administrator has MFA enrolled. The account being impersonated may not even have logged in that month.

Containment means rotating the credential. This is the one that hurts. After a normal credential theft incident you rotate the password, revoke the sessions, and the attacker's access dies. What do you rotate here? Nothing of the admin's was taken. Until the July patch is applied, the attacker can mint a fresh token for any user, any time, as many times as they like. Rotation is not a control against a bug that manufactures identity from nothing.

CrowdStrike reported that 82% of detections in 2025 were malware-free, a figure we dug into in our analysis of 27-second breakout times. Token forgery is the far end of that trend. There is no malware, and now there is not even a stolen secret. The intrusion consists entirely of well-formed, successfully authenticated requests.

The chain, and the gap inside it

CVE-2026-55040 gets you identity. It does not get you code. For that, attackers pair it with CVE-2026-63520, an RCE in SharePoint's Business Data Connectivity subsystem that Rapid7 and Microsoft disclosed on August 11, CVSS 8.1. The root cause is a DbTypeReflector class that instantiates arbitrary assembly-qualified .NET types out of BDC model XML with no allowlist. Authentication bypass plus unsafe type instantiation equals unauthenticated remote code execution. VulnCheck's Jonathan Peterson published a proof of concept for the second half on August 24.

But look closely at what the honeypot operators actually saw. Defused reported the chain being probed with the JWT bypass exercised first, "followed by heavy admin enumeration and probing of the Business Data Catalog sink behind CVE-2026-63520. No code execution observed yet."

Heavy admin enumeration. That phrase is the whole detection opportunity, and I think most teams will read past it.

Between minting the token and landing the payload, the attacker has to look around. They do not know your site collection layout. They do not know which document libraries hold the credentials, the network diagrams, the exported config files, the spreadsheet of service account passwords that somebody promised to delete in 2023. So they browse. As an administrator, over a legitimate session, generating access logs that look exactly like an administrator browsing.

You cannot pattern-match your way out of that. Every request is authorised. Every request is well-formed. The signature-based approach fails because there is no anomaly in the traffic, only in the intent behind it.

What a decoy does that a rule cannot

This is the case for deception stated in its narrowest and most defensible form: when an attacker's actions are indistinguishable from legitimate ones, stop trying to classify the action and start planting objects that only an attacker would touch.

A honeytoken document in a SharePoint library has no business purpose. Nobody in finance opens VPN-recovery-keys-DO-NOT-DELETE.xlsx, because it was never part of anyone's workflow and it does not appear in any link, email or bookmark. Its only property is that it is findable and it looks valuable to someone enumerating. When the credentials inside it are used anywhere on your network, or when the document itself is fetched, you have not detected a suspicious pattern. You have detected a person, because there is no false-positive path. That property is what makes credential decoys work against directory enumeration, where the attacker likewise never fired a single exploit and simply read what they were allowed to read.

Two practical notes from actually doing this in SharePoint, because the naive version generates noise and gets switched off in a week.

First, exclude the search crawl account. SharePoint's own indexer will read your decoy document on its normal crawl schedule, and if your alert fires on any read, your first three alerts will be the search service and your team will lose faith in the whole thing. Scope the trigger to exclude the crawl identity and the backup service principal, then alert on everything else. Better still, make the tripwire the credential inside the file rather than the file access, so the alert fires on use rather than on read. Nothing legitimate ever authenticates with a fake key.

Second, put decoys where enumeration goes, not where you would file a real secret. Attackers moving through a forged-admin session look at the site collection administrators list, the BDC model definitions, and any library with "IT", "Admin", "Infra" or "Ops" in the name. A decoy in a well-governed, correctly permissioned library will never be found. That is the opposite of how you place real data, and it takes some getting used to.

The same logic extends past the document layer. A decoy service listening where nothing should be talking, which is what MineField does for internal network segments, catches the lateral movement that follows once the attacker has read enough to know where to go next. The SharePoint box is rarely the objective. It is the map.

What to do this week

Patch both CVEs. July's fix alone does not close the chain, and neither does August's; you need both. If you have on-premises SharePoint reachable from the internet, assume the twelve recorded attempts are a floor rather than a ceiling, since honeypot telemetry only sees what wandered into honeypots. CVE-2026-55040 is the fifth SharePoint flaw exploited in the wild in 2026, after CVE-2026-45659, CVE-2026-56164, CVE-2026-58644 and CVE-2026-50522. That cadence is not going to slow down.

Then go looking backwards. Anonymous GETs to /_layouts/15/metadata/json/1 are the tell, because that certificate fetch has no legitimate unauthenticated use case in most deployments. Pull your IIS logs from mid-July onward and check. Pair that with admin-context activity from accounts whose owners were on holiday, and with any burst of site-collection enumeration that has no matching sign-in event in your identity provider.

And accept the structural point, because it will keep showing up. The industry spent a decade making credentials harder to steal, and the response has been to stop stealing them. Forge the token, ride the session, borrow the OAuth grant, as we saw in the device code phishing campaign that hit 340 Microsoft 365 tenants. Every one of those attacks produces a valid, authenticated, entirely normal-looking request. Detection built on distinguishing good requests from bad ones is fighting an argument it has already lost, which is why the thing worth planting is bait that carries no legitimate reason to be touched. If you want to see what that looks like against your own SharePoint estate before an attacker maps it for you, book a walkthrough with our team.