SharePoint auth bypass goes from Rapid7 write-up to honeypot hits in about a month

A critical SharePoint authentication bypass that Microsoft patched in its July 2026 Patch Tuesday release is now being exploited, following the publication of proof-of-concept exploit code by Rapid7 ^[1][2]. That moves any SharePoint server still sitting on June's patch level from a maintenance ticket to an incident-response question.

The mechanics are unglamorous and effective. Microsoft's own description is that "the authentication feature could be bypassed as this vulnerability allows impersonation," and that exploitation "could allow an attacker to disclose files and modify data, but the attacker cannot impact the availability of the system" ^[3]. Rapid7 researcher Stephen Fewer, who published the technical analysis alongside the PoC, put it more usefully for defenders: a remote unauthenticated attacker can bypass authentication on a vulnerable server and "perform operations as a SharePoint site user or administrator," with the root cause being "several issues in the JWT token validation pipeline" ^[4][5].

Read those two framings together. Microsoft's advisory language emphasises that availability is untouched, which is the sort of scoping that quietly downgrades a bug in a change-advisory-board meeting. Administrator-level read and write against a document management platform is a data breach and a persistence foothold, not a partial outage.

The chaining makes it worse. According to NHS England Digital, when CVE-2026-55040 is paired with CVE-2026-63520 the combination "could lead to unauthenticated remote code execution against a vulnerable SharePoint server" ^[8]. That is the difference between file theft and owning the box, and it means the two CVEs need to be treated as one remediation item rather than two independently prioritised ones.

On the evidence for exploitation, be precise about what exists. The in-the-wild signal comes from threat intelligence firm Defused, which warned on X that attackers are using the Rapid7 PoC against its SharePoint honeypots ^[6]. Microsoft has not confirmed exploitation, though it does flag the flaw as a likely target ^[7]. Honeypot telemetry from a single vendor is a real indicator, and it is also the earliest and noisiest kind: it tells you scanning and opportunistic exploitation have started, not how many production estates have been hit. Treat it as a starting gun, not a casualty count.

Separately, CISA is urging administrators to harden SharePoint deployments, citing active exploitation of several other vulnerabilities in the platform ^[9]. Its guidance is architectural rather than patch-specific: "Avoid exposing SharePoint Servers directly to the internet unless necessary; and if necessary, only configure a SharePoint Server behind a Layer 7 reverse proxy or equivalent application-layer security control that requires authentication and can inspect and filter requests" ^[10]. Defenders were also pointed at Microsoft's official SharePoint hardening documentation ^[11].

The timeline is the part worth internalising. Help Net Security reported the exploitation on 13 August ^[12], roughly 30 days after the July fix shipped ^[13]. A month of patch lag was survivable while the bug was theory; it stopped being survivable when the JWT validation flaws were written up in detail with code attached.