Attackers picked up the SharePoint exploit code the day after it was published

On 11 August 2026 Rapid7 published a technical analysis of CVE-2026-55040, an authentication bypass in Microsoft SharePoint, together with code demonstrating how the flaw is exploited. The vulnerability was disclosed on 14 July 2026 by Rapid7 and Microsoft jointly. Defused, which runs SharePoint honeypots, states on X that attackers were using the Rapid7 code against those systems the very next day. The observation concerns attempted exploitation against decoy systems, and none of the sources say that production servers have been compromised.

What happens technically

SharePoint accepts a signed token, a JWT, that states who the user is. Rapid7 describes four weaknesses in the validation of that token, and it is the combination of them that makes the attack possible. The first sits in the setup itself: the code switches off the requirement that the token be signed. The library then accepts a token declaring that it carries no signature at all, and no cryptographic check is performed on the outer token. Audience and issuer validation are also switched off in the library, because SharePoint does that work itself further down in its own code.

The second weakness is the one that makes the attack practical. A token can contain what is called an actor token, and SharePoint finds the key for it by looking up a thumbprint stated in the header of the token itself. The thumbprint is therefore chosen by whoever builds the token. The lookup searches every certificate SharePoint trusts, including the server own token signing certificate, and that certificate can be fetched by anyone from the endpoint /_layouts/15/metadata/json/1 without logging in. The attacker sets the thumbprint to the server own certificate, the lookup finds a match, and the signature is never verified against the key that was found. The last two weaknesses close the circle: issuer validation explicitly accepts a certificate that is not registered as a trusted issuer, and the signature check is not cryptographic. The result is that an attacker with no login can forge a token and act as any user or administrator on the site.

Two things are worth keeping apart. The Rapid7 analysis was carried out against SharePoint Server Subscription Edition, and the flaw is fixed by the updates Microsoft released in July. The Defused observation is something else, namely that the code is now being used in attempted attacks. Honeypots are systems set up to be attacked, and traffic against them tells you about activity under way, not about who has succeeded. That the distance from published analysis to live attempts was one day is therefore the most important number in this story.

What this means for you if you run SharePoint yourself

If you run SharePoint on your own premises, this is a job for today rather than for the next maintenance window. The attack needs no account, no phishing and no user mistake. It only needs your server to answer on the internet and to be missing the July update. If you have an installation nobody is sure who owns, that is the one to look for first. Our experience is that there is almost always one more SharePoint server, set up for a project that finished long ago.

You should also search the logs, not only patch. The trace to look for is requests without a login that nevertheless carry a token, and lookups against the endpoint that hands out certificate information. Berigo assesses that patching alone does not answer the question of whether anyone got in before you closed the hole, and that question has to be answered before the case can be put aside. Under NIS2 article 21 this is vulnerability handling and incident handling, and both have to be documented afterwards.

Berigo recommends

• Install the July update from Microsoft on every on-premises SharePoint server, including those missing from your service catalogue.
• Search for requests without a login that carry a token, and for lookups against the endpoint that hands out certificate information.
• Close internet access to SharePoint servers that do not need to be open, at least until the update is in place.
• Check whether there are SharePoint installations without an owner, and either give them one or switch them off.
• Write down what you found and when you patched, so the question of compromise has an answer later.