UPDATE — CVE-2026-55040 crosses into confirmed exploitation on CISA's catalogue while Microsoft still records it as not exploited, and it lands on an on-premises SharePoint estate this constituency has already had breached twice

UPDATE · originally covered 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 (2026-08-13)

the exploitation status flipped. CISA added CVE-2026-55040 to its Known Exploited Vulnerabilities catalog on 2026-08-18, describing it as a weak-authentication flaw that "allows an unauthorized attacker to bypass a security feature over a network" (CISA KEV catalog, 2026-08-18), ENISA's EU Vulnerability Database carries the same date and an EPSS of 3.97, mirroring that determination rather than independently confirming it (ENISA EUVD, 2026-08-18). The earlier entry carried this flaw as proof-of-concept-public on the strength of Rapid7's exploit being replayed against honeypots a day after publication — real exploitation attempts, but against sensors rather than estates. The federal catalogue now classes it as exploited outright, which is a stronger statement than honeypot telemetry even though it rests on one authority.

Microsoft's own record has not moved. It still records exploitation as no, and its published explanation of the impact remains that "the authentication feature could be bypassed as this vulnerability allows impersonation" (Microsoft Security Response Center, 2026-07-14) — the vendor rates the flaw Critical at CVSS 9.1 and does assess exploitation as more likely, which agrees with the catalogue's direction — what disagrees is the record's own exploited field, still set to no with no revision since 14 July. That is the second Microsoft CVE in this catalogue update whose exploited field contradicts the catalogue, and it is a reason not to let a vendor-scored feed be the only input to a SharePoint patch decision. (On the sibling IKE Extension flaw the vendor's exploitability assessment is the disagreeing field too; here only the exploited flag is.)

The reason this matters here more than the score suggests is the estate. Switzerland's federal IT provider BIT confirmed a SharePoint Server intrusion affecting around 200 federal user and technical accounts, and canton Graubünden disclosed its own SharePoint server breach a day later — both already covered here, and neither publicly tied to this identifier by any source. What the exploitation listing changes is the standing of an unpatched, internet-reachable farm: the honest reading is no longer "a proof-of-concept exists" but "this is being used", and a farm that sat exposed between the July patch and now warrants a look at its authentication records rather than an upgrade ticket alone.

Hunting concentrates on the impersonation outcome rather than the request that produced it, because a forged token is accepted by design once validation fails. In authentication and application telemetry, the signals are SharePoint access events whose asserted identity has no corresponding interactive sign-in from the same source within the session window, site-administrator-level operations from a client that never authenticated normally, and unauthenticated requests to token-handling endpoints immediately preceding privileged activity. Triage: federated and app-only access legitimately produce SharePoint operations with no interactive sign-in, so that pattern alone is normal in most tenants — the discriminators are whether the asserted principal is one that federation or a registered application is actually configured to assert, and whether the source address belongs to the estate's own service ranges. Patching is the remediation; there is no configuration workaround in the vendor's record.