Published on 13 August 2026
On August 11, 2026, the security firm Rapid7 published a technical analysis together with a proof-of-concept (that is, working sample code demonstrating how a vulnerability can be exploited) for a critical SharePoint vulnerability. Just one day later, on August 12, the threat intelligence provider Defused reported that attackers were already using exactly this sample code against its SharePoint honeypots — deliberately deployed trap systems. This makes it clear: CVE-2026-55040 is being actively exploited. Anyone running their own Microsoft SharePoint Server that isn't fully patched is now a realistic target.
This article explains what exactly happened, who is affected, how to check whether your company is at risk — and which steps you should take today.
At the center are two vulnerabilities in self-hosted Microsoft SharePoint Server, which Rapid7 reported as part of an attack chain:
Individually, both vulnerabilities are dangerous. Combined, they produce an unauthenticated remote code execution — an attacker without any credentials whatsoever can then run malicious code directly on your SharePoint server. Rapid7 researcher Stephen Fewer summarizes the impact of the first vulnerability as follows:
„A remote unauthenticated attacker can leverage CVE-2026-55040 to bypass authentication on a vulnerable SharePoint server, and perform operations as a SharePoint site user or administrator.“ (Ein entfernter, nicht authentifizierter Angreifer kann CVE-2026-55040 nutzen, um die Authentifizierung auf einem verwundbaren SharePoint-Server zu umgehen und Aktionen als SharePoint-Nutzer oder -Administrator durchzuführen.) – Stephen Fewer, Rapid7
Important for context: the evidence of active exploitation currently rests on a honeypot observation by Defused. There is no publicly confirmed figure of actually compromised companies and no attribution by name to any threat group. The trend is nonetheless unmistakable: just one day after the PoC was published, the vulnerability was already under fire.
CVE-2026-55040 affects SharePoint's JWT-based authentication. A JWT (JSON Web Token) is a digital "ID card" with which a user identifies themselves to the server. According to Rapid7, several weaknesses in the validation of these tokens can be combined so that an attacker generates a forged token that the server accepts as valid. This allows the attacker to slip into the identity of a real user or administrator — and to access all content and modify data for which that account is authorized. Microsoft describes the consequences as follows:
„Exploiting this vulnerability could allow an attacker to disclose files and modify data, but the attacker cannot impact the availability of the system.“ (Die Ausnutzung könnte einem Angreifer erlauben, Dateien offenzulegen und Daten zu verändern, ohne die Verfügbarkeit des Systems zu beeinträchtigen.) – Microsoft Security Response Center
CVE-2026-63520, according to Rapid7, is based on an insecure .NET type instantiation in the Business Connectivity Services (a SharePoint component for connecting external data sources). It enables code execution with the privileges of the SharePoint site's service account. On its own it would normally require a preceding identity — but that is exactly the hurdle the authentication bypass from CVE-2026-55040 removes. This produces the complete, unauthenticated RCE chain.
For responsible reasons, we deliberately refrain here from providing attack code or reproducible exploit steps.
Affected are organizations that run Microsoft SharePoint Server themselves, specifically in these versions:
Not directly affected are companies that merely have a website hosted for them without running their own SharePoint server. So if you only have a company website with a hosting provider, that falls outside the scope named by Microsoft. Nevertheless: ask your IT service providers and partners whether SharePoint is in use there and how the patch status stands.
In mid-July, the BSI counted almost 10,000 internet-reachable SharePoint systems worldwide and over 400 in Germany. This figure describes reachability — not that all these systems are vulnerable or compromised. It does, however, show how large the potential attack surface is. Particularly critical is the combination of internet reachability, confidential documents, and the typical connection to Active Directory, Outlook, Teams, and OneDrive — the latter often enabling attackers to move laterally through the network after a takeover (lateral movement).
Note: This is a factual assessment and not legal advice. An unpatched vulnerability alone is not yet a reportable personal data breach. Under Art. 4 No. 12 GDPR, such a breach exists when a security breach leads, among other things, to the unauthorized disclosure of, or unauthorized access to, personal data.
If there are solid indications of actual access, the controller must inform the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware — provided the breach is likely to result in a risk to the rights and freedoms of natural persons. Processors must inform the controller without undue delay. Where a high risk is likely, the affected individuals must also be notified, subject to legal exceptions such as effective encryption.
For violations of the security requirements under Art. 32 GDPR, Art. 83(4) provides for a maximum of up to EUR 10 million or 2% of the worldwide annual turnover of the previous year. The specific penalty depends on the individual case and must be effective, proportionate, and dissuasive.
How relevant avoidable data exposure is in practice is shown by a German comparison case: the Hamburg Data Protection Commissioner (HmbBfDI) reports on a cashback agency where at least 56,635 records were temporarily accessible without special barriers due to inadequate technical measures. The authority imposed a fine in the low five-figure range for violations of Art. 32 GDPR and further breaches. This is not a SharePoint case and not a benchmark tariff — but it illustrates that inadequate technical protective measures can have concrete consequences.
The overall risk is high and time-critical for unpatched, self-hosted SharePoint servers — especially where internet-exposed. CVE-2026-55040 requires no valid account and is already being used against honeypots following the PoC publication. The consequences range from unauthorized file access and data manipulation to takeover of administrator privileges. With the now likewise patched RCE component CVE-2026-63520, this can become a complete, unauthenticated server code execution.
To put the trend in context: CISA reported as early as 2026-07-28 on active exploitation of other SharePoint vulnerabilities (CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, CVE-2026-58644 and CVE-2026-50522). On August 12, SecurityWeek classified CVE-2026-55040 as already the fifth SharePoint vulnerability whose exploitation became known in the summer of 2026. On-premises SharePoint is thus under sustained, broad attack — even if this is no proof of an identical threat group.
What is missing is a solid damage figure: there is no published figure of compromised organizations or exposed records for these two CVEs. The roughly 10,000 exposed systems are an exposure value, not a damage figure.
The timeline is a case study in patch urgency: Rapid7 reported the chain back in May 2026, Microsoft closed the authentication bypass in July and the RCE component in August. On August 11 the PoC was published — on August 12 the first attacks rolled in. The window between public analysis and active exploitation was therefore barely 24 hours.
If you run your own SharePoint Server, the message is unambiguous: Check your patch level and internet exposure today, apply the August 2026 updates completely, and, on suspicion, search specifically for signs of intrusion. If you still run SharePoint 2016 or 2019, whose extended support has expired, you should plan the replacement in parallel. And anyone who does not run their own server should ask about the patch status at their service providers and IT partners — because attackers make no distinction about where vulnerable systems are located.