UPDATE — attackers are running Rapid7's SharePoint proof-of-concept against honeypots within a day, and the published root cause is four validation failures that let an unsigned token impersonate a site administrator

UPDATE · originally covered UPDATE — the half-patched SharePoint chain this pipeline flagged in July is now complete and public: CVE-2026-63520 ships, and Rapid7 releases the analysis and proof-of-concept for CVE-2026-55040 (2026-08-12)

yesterday's entry recorded that Rapid7 had published a technical analysis and proof-of-concept for CVE-2026-55040 and stated plainly that it did not have that analysis in hand, so no behavioural detail could be offered. Two things changed within a day. The proof-of-concept is being used in attacks, and the analysis — read in full for this entry — turns an exposure problem into a hunt.

Threat-intelligence company Defused reported on 2026-08-12 that "Attackers are now using the @rapid7 POC for CVE-2026-55040 against our SharePoint honeypots", roughly a day after the code was published (BleepingComputer, 2026-08-12). That is one company observing its own sensors, not a vendor confirmation: the same report notes that "While Microsoft has labeled this security flaw as an attractive target for attackers", it has not yet flagged it as successfully exploited in the wild (BleepingComputer, 2026-08-12). Switzerland's NCSC added the exploitation-attempt claim to its own July Patch Tuesday advisory on 12 August, having added the analysis and proof-of-concept to the same advisory the day before (NCSC-CH, 2026-08-12). For scale, the same reporting cites Shadowserver, which "currently tracks over 8,500 Microsoft SharePoint servers exposed online", with the honest caveat that how many are honeypots or already patched is unknown (BleepingComputer, 2026-08-12).

How the bypass works, and why it matters that it is four bugs and not one. Rapid7's analysis, based on decompilation of the identity module from a fully patched Subscription Edition build, states that "The root cause is a chain of four distinct weaknesses that, when combined, allow an unauthenticated remote attacker to forge a valid JWT and impersonate any SharePoint site user" (Rapid7, 2026-08-11). SharePoint's server-to-server authentication uses a nested token: an outer token carrying user identity claims, and an inner "actor token" representing the calling application that is expected to be cryptographically signed. Each of the four failures removes one guarantee from that design.

First, the token handler explicitly turns off the requirement for signed tokens when it builds its validation parameters — Rapid7's description is blunt: "This single line disables the JWT library's cryptographic signature verification", so the outer token is accepted with no signature at all. Second, the code resolves the inner actor token's signing key from a thumbprint value carried in that token's own header, searching all trusted certificates including SharePoint's own local security-token-service certificate, and assigns the resolved key without ever verifying a signature against it. Third, issuer validation then looks for a registered token service matching that certificate, does not find one — because the server's own signing certificate is not in the collection being searched — and treats the absence of a match as grounds to accept rather than reject. Fourth, the final signature step requires only that a signature string be non-empty; any arbitrary value satisfies it. The result is that the identity in the outer token's name claim, which the caller chooses, is resolved to a real account. (Rapid7, 2026-08-11)

Two properties of that chain matter operationally more than the mechanics themselves. The certificate whose thumbprint the attacker needs is published by the server: Rapid7 records that it is retrievable from an unauthenticated metadata endpoint on the SharePoint site itself, so no prior access is required to obtain it. And picking a useful identity is a separate reconnaissance step — Rapid7 describes querying the target's domain controller over an anonymous SMB session to learn the domain identifier, then walking relative identifiers to enumerate candidate accounts and find one that is a site administrator, noting that a user principal name works too but is less reliable to guess. (Rapid7, 2026-08-11)

Detection, in telemetry terms. The decisive weakness leaves a server-side record: Rapid7's decompilation shows the issuer-validation path emitting a trace message stating that the issuer was accepted because no registered token service matches the signing certificate, immediately before returning success (Rapid7, 2026-08-11). On a healthy farm that path should be rare; on an attacked one it fires on every forged token. That message in the SharePoint diagnostic trace logs is the highest-value single artefact available, and it is a server-side one, so it survives an attacker who never touches the endpoint. Alongside it, three sequences are worth building around: an unauthenticated request to the site's metadata endpoint from an external address, followed within a short window by bearer-token requests to the site's REST API from the same source; authenticated REST activity — reading files, minting a form digest, changing configuration — with no corresponding interactive sign-in or federation token issuance for that account in identity logs; and anonymous SMB sessions enumerating account identifiers from an address that also talks to the SharePoint front end.

Triage: legitimate server-to-server integrations also present bearer tokens to the SharePoint REST API, which is why the token's presence is not the signal. The discriminators are the ones the mechanism forces: a token whose acceptance is accompanied by the unregistered-signing-certificate trace message, activity attributed to a highly privileged account with no matching sign-in event in the identity provider, and an external source address that fetched the unauthenticated metadata endpoint shortly beforehand. A normal integration is registered, so its issuer resolves against a registered token service and never takes the accepting-by-default branch.