Threat actors have begun targeting internet-facing Microsoft SharePoint servers with exploit code for a critical authentication-bypass vulnerability less than 24 hours after detailed technical research and a public proof of concept were released.
The vulnerability, tracked as<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-55040?trk=article-ssr-frontend-pulse_little-text-block” rel=”nofollow noopener” target=”_blank”>CVE-2026-55040, affects supported on-premises editions of Microsoft SharePoint Server and carries a critical CVSS severity score of 9.1. It allows a remote attacker who has no valid credentials to forge authentication tokens and impersonate a SharePoint user—including, under the right conditions, a site administrator.
Threat-intelligence company Defused said on August 12 that its SharePoint honeypots had received attacks using the proof-of-concept code published a day earlier by Rapid7 security researcher Stephen Fewer. The activity provides early evidence that attackers are rapidly incorporating the publicly available technique into internet scanning and exploitation operations.
The observations do not yet establish that attackers have successfully compromised production organisations throughCVE-2026-55040. Honeypot activity demonstrates malicious attempts and validates attacker interest, but it does not by itself reveal how many real SharePoint installations have been breached, which groups are responsible or what attackers have done after gaining access.
Nevertheless, the speed with which the exploit was adopted significantly raises the risk for organisations that have not installed Microsoft’s July security updates. Microsoft had already classified exploitation ofCVE-2026-55040as “more likely,” even before the technical details became public.
The vulnerability is particularly serious because Rapid7 has demonstrated that it can be chained with a separate SharePoint remote-code-execution flaw,CVE-2026-63520. Microsoft patched that second vulnerability as part of its August 2026 security updates. Together, the two flaws can allow an unauthenticated attacker to progress from the internet to executing arbitrary code on a vulnerable SharePoint server.
A failure inside SharePoint’s trust system
CVE-2026-55040is not a conventional password attack. It does not require an attacker to steal a password, capture a session cookie, defeat multifactor authentication or persuade an employee to open a malicious document.
Instead, the vulnerability affects the mechanism SharePoint uses to decide whether a JSON Web Token, or JWT, should be trusted.
JWTs are widely used to pass identity and authorisation information between applications and services. A token can contain claims describing a user, the application making a request, the token’s intended recipient and the permissions associated with the identity. Cryptographic signatures are intended to prevent an attacker from altering or fabricating those claims.
Rapid7’s analysis found that SharePoint’s service-to-service authentication process uses a nested token structure. An outer token contains information about the user, while an embedded “actor token” represents the application acting on that user’s behalf.
According to Rapid7,CVE-2026-55040is not caused by one isolated programming error. It results from four weaknesses in SharePoint’s JWT validation pipeline that become dangerous when combined.
The first and most fundamental issue is that the affected code explicitly disables the requirement for tokens to carry a valid cryptographic signature. SharePoint then performs parts of the issuer and certificate-validation process through its own custom logic.
A second weakness allows an attacker-controlled certificate thumbprint in the actor token to be matched to a certificate trusted by the SharePoint installation. Rapid7 found that an attacker can obtain the SharePoint Security Token Service’s public certificate through an unauthenticated metadata endpoint and reference its thumbprint in a forged token.
The application resolves that certificate as though it were the actor token’s signing certificate, but it does not subsequently verify the token’s signature against the corresponding cryptographic key.
Rapid7 also identified weaknesses in issuer validation and a later token-signature check that does not provide genuine cryptographic verification. The combined result is that SharePoint can accept a fabricated JWT and convert its claims into an authenticated SharePoint identity.
The research was based on analysis of SharePoint Server Subscription Edition, including the Microsoft.SharePoint.IdentityModel component and the classes responsible for parsing and validating bearer service-to-service tokens.
Rapid7 said the chain enables an unauthenticated remote attacker to forge a token and impersonate a selected SharePoint user. The attacker still needs to identify the account they want to impersonate, such as through a username, user principal name or security identifier. That requirement offers limited protection in practice because corporate email formats, administrator account names and directory information can often be identified or inferred.
Rapid7’s complete technical analysis and proof-of-concept tool were released on August 11, almost a month after the coordinated disclosure of the vulnerability on July 14.Rapid7’s technical analysisdescribes the token-validation failures in detail.
From impersonation to complete server compromise
On its own,CVE-2026-55040allows an attacker to cross SharePoint’s authentication boundary and perform actions with the permissions of the impersonated user. Microsoft says successful exploitation can expose files and allow data to be changed, although the flaw does not directly affect system availability.
That description understates the broader risk when the bypass is combined with other vulnerabilities reachable by authenticated SharePoint users.
Rapid7 discoveredCVE-2026-55040during a zero-day research project that produced a two-stage attack chain. The second weakness,CVE-2026-63520,is a SharePoint remote-code-execution vulnerability patched by Microsoft on August 11.
CVE-2026-63520allows a malicious authenticated user to trigger unsafe .NET deserialisation. Rapid7 developed a custom .NET gadget chain capable of performing arbitrary operations, including executing operating-system commands. Code launched through the flaw runs with the privileges of the Windows service account operating the affected SharePoint site.
When combined,CVE-2026-55040eliminates the second vulnerability’s authentication requirement. An attacker can first create a forged identity token and then use the resulting SharePoint access to reach the deserialisation flaw, producing an unauthenticated remote-code-execution chain.
That distinction is crucial for defenders. A vulnerability described as requiring a low-privileged account may appear less urgent when considered alone. An authentication bypass can effectively remove that prerequisite and turn the same weakness into a remotely exploitable route from the public internet.
Rapid7 has not yet published the complete technical details or proof-of-concept code forCVE-2026-63520. The company said it intends to release its analysis within 30 days of disclosure. However, the immediate availability of theCVE-2026-55040exploit means attackers can already breach the authentication layer on servers that missed the July update and probe the authenticated SharePoint attack surface for other weaknesses.
Microsoft has released August fixes forCVE-2026-63520covering SharePoint Server Subscription Edition, SharePoint Server 2019 and SharePoint Enterprise Server 2016. The issue also affects certain versions of Microsoft Project Server and Office Web Apps Server.Rapid7’s advisory on CVE-2026-63520lists the relevant update packages and fixed builds.
Thousands of SharePoint servers remain exposed
Shadowserver’s internet measurements identify more than 8,500 systems presenting Microsoft SharePoint services directly to the internet. That figure should not be interpreted as the number of vulnerable servers: it can include patched installations, security research systems, honeypots and servers whose precise versions cannot be established remotely.
It does, however, illustrate the size of the potential attack surface. Publicly accessible SharePoint installations are attractive targets because the platform frequently serves as a repository for confidential documents, internal communications, employee records, project data and business workflows.
SharePoint also commonly connects to Active Directory, databases, Office services and other internal systems. A compromised server can therefore provide more than access to one web application. Depending on its configuration, service-account privileges and network position, it may become a staging point for credential theft, lateral movement, persistence or access to additional corporate resources.
The emergence of public exploit code also changes the nature of the threat. Before August 11, exploitingCVE-2026-55040required independent technical research or access to non-public knowledge. Attackers can now study and adapt working code without reproducing the original vulnerability research.
The transition from vulnerability disclosure to automated scanning can be extremely short. Defused’s honeypot observations indicate that, in this case, malicious testing began within roughly a day.
Microsoft’s official status has not caught up with the new activity
Microsoft’s Security Response Center had not, at the time of reporting, changedCVE-2026-55040’s status to confirm exploitation in the wild. Its advisory continued to assess exploitation as more likely rather than listing it as detected.
That apparent discrepancy is not necessarily a contradiction. Microsoft’s designation generally requires a level of validation beyond reports of exploit attempts against honeypots. It may seek evidence of successful exploitation, affected customer environments or attributable post-compromise activity before changing the status.
Defenders should not treat the absence of a formal “exploited” label as evidence that delaying remediation remains safe. A functioning public exploit is available, malicious systems are sending it to SharePoint targets and a related vulnerability can turn the authentication bypass into server-side code execution.
The most accurate current assessment is that malicious exploitation attempts have been observed, while the scope of successful compromise against real organisations remains unknown.
CISA had already warned organisations to harden SharePoint
The US Cybersecurity and Infrastructure Security Agency issued a SharePoint security alert in July after exploitation of several other vulnerabilities affecting the platform.
CISA urged organisations to avoid placing SharePoint servers directly on the internet unless external access is operationally necessary. Where exposure cannot be eliminated, the agency recommended placing the service behind a Layer 7 reverse proxy or another application-aware security control.
It also advised administrators to block external access to SharePoint Central Administration and restrict communication between farm components and database systems to authorised hosts and required ports. These measures reduce the number of interfaces an attacker can reach and make it more difficult to pivot from a compromised web-facing server.
CISA’s alert initially distinguishedCVE-2026-55040from SharePoint vulnerabilities for which active exploitation had already been confirmed. That assessment was published before Rapid7 released its proof of concept and before Defused observed the new attack traffic.CISA’s SharePoint hardening alerthas since been updated as additional SharePoint flaws were added to the agency’s Known Exploited Vulnerabilities catalogue.
CVE-2026-55040itself had not been added to the KEV catalogue at the time of reporting. Inclusion would impose a binding remediation deadline on US federal civilian agencies, but private-sector organisations should not wait for that administrative step before responding.
CISA has recorded 14 SharePoint vulnerabilities as exploited since November 2021, eight of which are associated with ransomware activity. That history demonstrates why exposed SharePoint infrastructure is repeatedly targeted by financially motivated criminals and state-aligned groups.
A separate SharePoint flaw is now linked to ransomware
The latest activity comes as CISA has also updated its listing forCVE-2026-45659to indicate that the vulnerability is being used in ransomware campaigns.
CVE-2026-45659is a high-severity SharePoint deserialisation vulnerability that allows an authenticated attacker with low privileges to execute code remotely. It was already known to be actively exploited in early July, but the ransomware designation confirms its use in financially motivated intrusions.
There is currently no public evidence showing thatCVE-2026-55040has been combined withCVE-2026-45659. The two issues should not be described as a confirmed exploit chain.
Their coexistence nevertheless illustrates a wider defensive problem. If an attacker can useCVE-2026-55040to become an authenticated user, vulnerabilities that nominally require an account may become reachable without stolen credentials. Organisations must therefore assess their complete SharePoint patch state rather than treating individual CVEs as independent risks.
The July SharePoint updates also addressed numerous other remote-code-execution, information-disclosure, spoofing and elevation-of-privilege vulnerabilities. Applying only a narrow fix, or checking only forCVE-2026-55040, can leave other exploitable paths open.
Which SharePoint versions are affected?
Microsoft’s CVE record identifies on-premises SharePoint products, including SharePoint Enterprise Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition.
SharePoint Online is not listed as affected. Organisations using Microsoft 365 should still confirm that they do not retain an on-premises or hybrid SharePoint farm for legacy applications, internal portals, search, workflows or document management.
The distinction matters because some businesses describe themselves as having migrated to SharePoint Online while continuing to operate older servers for limited workloads. Forgotten or poorly inventoried systems are especially dangerous when they remain accessible from the internet.
Microsoft’s July updates included KB5002891 for SharePoint Server 2016 and KB5002882 for SharePoint Server Subscription Edition. Microsoft published separate packages for SharePoint Server 2019 and language-dependent components. Administrators should follow the product-specific guidance rather than assume that installing one package completes the update across an entire farm.Microsoft’s Subscription Edition update documentationidentifies build 16.0.19725.20434 as the July security-update build.
The August fixes for the second-stage RCE include:
- KB5002893 for SharePoint Server Subscription Edition, build 16.0.19725.20522.
- KB5002894 and KB5002896 for SharePoint Server 2019, build 16.0.10417.20198.
- KB5002905 and KB5002906 for SharePoint Enterprise Server 2016, build 16.0.5565.1001.
Administrators should consult Microsoft’s Security Update Guide and support pages for the precise packages required by each product and language configuration.
Installing the update is only part of remediation
Patching SharePoint is more involved than updating an ordinary Windows workstation. Security teams should confirm that the relevant packages have been installed on every server in the farm and that the SharePoint Products Configuration Wizard, or its command-line equivalent PSConfig, has been completed where required.
A package can appear in Windows update history while the SharePoint farm remains incompletely upgraded. Mixed build levels across web front ends and application servers can also create operational problems and make vulnerability assessment unreliable.
Microsoft’s July updates include product-specific prerequisites and known issues. For example, organisations using SharePoint Workflow Manager may need to install its corresponding update before applying the SharePoint cumulative update. Microsoft has also documented authentication prompts, workflow errors and Office document-rendering problems affecting some configurations.
Those compatibility concerns require testing, but they should not be used to justify leaving an internet-facing server exposed. If an organisation cannot immediately update a production farm, it should remove or tightly restrict external access until remediation can be completed.
Microsoft explicitly warns against disabling protections such as SessionCookieTransformProtectionEnabled as a workaround for repeated authentication prompts. Although doing so may appear to resolve a compatibility problem, it can weaken authentication security.
What defenders should do now
Organisations operating on-premises SharePoint should treat the release of public exploit code as an urgent change in risk.
Security teams should immediately identify every SharePoint server, determine whether it is internet-accessible and verify its installed build rather than relying solely on an asset-management label or an update deployment report. The July fix forCVE-2026-55040and the August fix forCVE-2026-63520should both be installed.
External access should be removed where it is not essential. Necessary public-facing deployments should be placed behind an application-layer reverse proxy or web application firewall, although those controls should be considered supplementary rather than substitutes for patching.
Administrators should prevent internet access to Central Administration, limit management interfaces to dedicated administrative networks and restrict connections between SharePoint web servers, application servers and databases.
Security operations teams should review web, authentication, proxy, endpoint and Windows event logs for unusual access involving unexpected user identities, abnormal bearer tokens, administrative actions, unexplained file changes or commands launched by SharePoint application-pool identities.
Because the vulnerability enables impersonation, a successful request may appear in some application logs as activity performed by a legitimate account. Investigators should therefore correlate SharePoint events withmal activity rather than assuming that a recognised username proves the request was genuine
Systems showing convincing signs of exploitation should be treated as potentially compromised, isolated from the network and subjected to forensic analysis. Simply installing the update does not remove web shells, scheduled tasks, stolen credentials or other persistence that an attacker may already have established.
A narrowing window for unpatched organisations
CVE-2026-55040is dangerous because it undermines a foundational security decision: whether a remote request represents an authenticated user.
Rapid7’s research shows that several apparently separate validation weaknesses can be combined to make a fabricated token look legitimate to SharePoint. The subsequent disclosure ofCVE-2026-63520demonstrates how quickly that identity failure can escalate into control of the underlying server.
Public exploitation attempts arriving within a day of the proof-of-concept release are a clear indication that the grace period has ended. Although the number of successfully compromised organisations remains unknown, defenders now have evidence of hostile adoption, a working public exploit and thousands of potentially reachable SharePoint systems.
For organisations still running affected on-premises versions, the priority is no longer simply to schedule a routine cumulative update. It is to verify exposure, install both the July and August security fixes, complete the farm upgrade process and investigate whether attackers reached the server before remediation.
