Hackers Are Chaining Two SharePoint Flaws Into Full Server Takeover

A proof-of-concept exploit chain against on-premises Microsoft SharePoint Server is now being used in real attacks, and the gap between “researcher publishes a technique” and “attacker weaponizes it” was one day. That is the timeline researcher Defused reported for CVE-2026-55040, the authentication bypass at the center of the latest SharePoint exploitation wave, according to BleepingComputer’s coverage.

The chain pairs two distinct flaws. CVE-2026-55040 is a JWT token authentication bypass that lets an unauthenticated attacker act as a SharePoint site user, or a site administrator, without ever presenting valid credentials. CVE-2026-63520 is a separate flaw in SharePoint’s Business Connectivity Services (BCS) that, once an attacker has bypassed authentication, can be chained into full remote code execution on an unpatched server. Rapid7’s Stephen Fewer published proof-of-concept code for CVE-2026-55040 on August 11. VulnCheck’s Jonathan Peterson followed with proof-of-concept code for CVE-2026-63520 on August 24. Within roughly two weeks of the first disclosure, the industry had a documented, working path from zero access to code execution on a SharePoint Server.

For any organization still running on-premises SharePoint Server to exchange, store, or collaborate on sensitive data, this is not a distant advisory to file away. It is confirmation that the platform remains a live, actively targeted surface for attackers who understand its authentication and integration layers better than most of the organizations running it. CVE-2026-55040 itself was patched on July 14, 2026, as part of a wave of SharePoint Server fixes that also produced five entries in the CISA Known Exploited Vulnerabilities catalog. A patch existing since July did not stop this month’s proof-of-concept exploitation, because unpatched instances are still reachable, and because the newly disclosed BCS flaw gives attackers a fresh way to convert that old bypass into a full compromise.

This piece walks through what the two CVEs actually do, why the one-day weaponization timeline matters more than the CVSS score, and what the pattern means architecturally for CISOs and compliance leaders who are accountable for proving, not just asserting, that sensitive data moving through platforms like Kiteworks secure data exchange remains under control regardless of what happens to adjacent infrastructure.

Key Takeaways

1. A working exploit chain now exists for on-premises SharePoint Server.

CVE-2026-55040 (JWT authentication bypass) and CVE-2026-63520 (a Business Connectivity Services flaw) can be combined to move from zero access to remote code execution on unpatched servers.

2. Weaponization happened in roughly a day.

Researcher Defused documented that CVE-2026-55040’s proof-of-concept code was already being used in live attacks one day after Rapid7 published it. Publication and exploitation are now nearly simultaneous events.

3. Patching closes the CVE. It does not close the architecture.

CVE-2026-55040 was patched July 14, 2026, yet the underlying pattern, authentication bypass chained into deserialization or integration-layer RCE, keeps recurring in on-premises SharePoint Server because the platform’s attack surface is structural.

4. This is on-premises SharePoint Server, not SharePoint Online.

Conflating the two is a factual error that leads organizations to draw the wrong conclusions about their own exposure; SharePoint Online was not the subject of this exploit chain.

5. The compliance question matters as much as the technical one.

For CISOs and compliance officers, the real exposure is not just server takeover; it is the inability to produce evidence, on demand, that sensitive content passing through an affected platform stayed authorized, encrypted, and logged during the exposure window.

What CVE-2026-55040 and CVE-2026-63520 Actually Do

CVE-2026-55040 lives in how on-premises SharePoint Server validates JWT (JSON Web Token) authentication. A properly implemented token validation pipeline should make it computationally infeasible for an outside party to forge a valid session. The vulnerability breaks that assumption. An attacker with no privileges, no valid credentials, and no prior foothold can construct a request that SharePoint Server treats as coming from a legitimate site user, or in the worst case, a site administrator. That is a full authentication bypass, not a privilege escalation from an existing low-privilege account.

CVE-2026-63520, rated CVSS 8.1 (High) according to VulnCheck’s technical writeup, sits in a different part of the platform, Business Connectivity Services, the integration layer SharePoint uses to connect to external line-of-business data sources such as databases, ERP systems, and custom applications. The root cause is an unsafe .NET type instantiation that lets an attacker abuse a deserialization gadget chain built on the System.Web.UI.LosFormatter class to run arbitrary code on the server. BCS is powerful by design; it exists to let SharePoint read and write data in external systems on the user’s behalf. That same design intent is what makes it dangerous once an attacker has already bypassed authentication. A component built to broker access to external systems, combined with attacker-controlled input, becomes a path to remote code execution on the server itself.

Neither flaw alone is unusual. Authentication bypasses and integration-layer deserialization or injection flaws have both shown up repeatedly in enterprise collaboration platforms. What makes this pairing significant is straightforward. CVE-2026-55040 gets an attacker in the door with no credentials required, and CVE-2026-63520 gives that same attacker a route to execute code once inside. Individually, each is a serious finding. Chained, they represent a complete, unauthenticated path to server compromise, which is precisely the kind of finding that shows up first as a proof of concept and then, often within days, as an active exploitation campaign.

From Proof of Concept to Live Exploitation in Days

The timeline is the part of this story that deserves more attention than the individual CVE numbers. Rapid7’s Stephen Fewer published proof-of-concept code for CVE-2026-55040 on August 11. According to researcher Defused, that code was already observed weaponized in real attacks the following day. VulnCheck’s Jonathan Peterson published proof-of-concept code for CVE-2026-63520 on August 24, giving attackers the second half of the chain roughly two weeks later.

This compression is not new to 2026, but it keeps getting shorter, and on-premises SharePoint Server has become a recurring proving ground for it. A patch that exists on Microsoft’s release calendar does an organization no good if the patch has not actually been applied, and Patch Tuesday cadence was never designed to compete with a same-day exploitation window. Security teams that treat proof-of-concept publication as a signal to start planning a patch cycle are, in practice, treating it as a signal that has already expired by the time they read the advisory.

Palo Alto Networks’ Unit42, assessing the related 2025 SharePoint “ToolShell” exploitation campaign, an earlier authentication-bypass-to-RCE chain against the same on-premises platform, stated the conclusion plainly, “Patching alone is insufficient to fully evict the threat.” That conclusion was reached in the context of attackers who, once inside via an authentication bypass, moved laterally and in some cases stole IIS machine key material, credentials that survive a patch and a web shell removal because they were never rotated. It is the same lesson this month’s chain is teaching again. A server can be fully patched today and still be compromised if the credentials an earlier intrusion touched were never invalidated. Patching answers “is this specific vulnerability still exploitable.” It does not answer “is this server, and everything connected to it, still trustworthy.”

This Is a Pattern, Not an Isolated Incident

Zoom out from these two CVEs and a pattern becomes visible across on-premises SharePoint Server’s recent history: authentication and integration-layer flaws, chained together, producing unauthenticated remote code execution, followed by rapid proof-of-concept weaponization. The July 2026 wave that patched CVE-2026-55040 also produced CISA’s July 14, 2026 SharePoint hardening alert and multiple entries in the CISA Known Exploited Vulnerabilities catalog, each with its own remediation deadline measured in days, not months. Resecurity’s analysis of that attack chain documented a progression from initial unauthenticated access, through code execution, to web shell deployment, to credential theft, to lateral movement toward domain compromise.

CVE-2026-63520 extends that same structural story into a new integration surface. It is a different code path than the deserialization flaws documented in July, but it produces the same outcome through the same general mechanism: an authentication layer that can be bypassed, feeding into a second component that was built to trust authenticated requests and therefore was never hardened against attacker-controlled input arriving through a broken front door. Tenable’s FAQ on the related SharePoint Server CVEs makes a similar point: these are not isolated coding mistakes so much as recurring symptoms of a platform where authentication, deserialization, and integration components each carry independent attack surface, and where a flaw in any one of them can be combined with a flaw in another to produce full compromise.

For a CISO, the useful question is not “did we patch CVE-2026-55040 and CVE-2026-63520.” It is “how many more components in this platform carry the same category of risk, and how would we know before the next proof of concept tells us.” That is an architecture question, not a patch-management question, and it does not have a patch-management answer.

Why Patching Alone Doesn’t Close the Gap

Three things are true at once, and organizations that only hold onto the first one are the ones still exposed months later. First, Microsoft did ship a patch for CVE-2026-55040 on July 14, 2026, and organizations that applied it are no longer vulnerable to that specific bypass. Second, the one-day weaponization window means any organization that had not already applied the patch before proof-of-concept code became public was exposed to live exploitation almost immediately, with essentially no warning period between “this is theoretically exploitable” and “this is being exploited.” Third, and least discussed, patching a vulnerability does not retroactively invalidate anything an attacker may have already accessed, copied, or persisted through a prior compromise window.

This is why the compliance-and-audit reader has a different, and arguably more urgent, question than the security-engineering reader. The security question is “is the server patched.” The compliance question is “can we produce evidence that every piece of sensitive content this server touched during the exposure window was accessed only by authorized identities, and if not, do we have a defensible, evidence-quality record of exactly what was exposed.” HIPAA, CMMC, and ITAR do not distinguish between “we were breached because we failed to patch” and “we were breached one day after a patch became theoretically available.” Regulators, auditors, and opposing counsel in litigation are going to ask what data was on the platform, who could reach it, and what the audit trail shows. An on-premises SharePoint Server environment that requires custom instrumentation to answer that question is starting from a disadvantage the moment an incident like this one occurs.

The Architecture Question Compliance and Security Leaders Should Be Asking

Kiteworks was not literally in the data path of this incident. On-premises SharePoint Server is a Microsoft-native platform that Kiteworks does not sit in front of, and nothing here should be read as a claim that Kiteworks would have prevented this exact attack chain. The alignment is architectural, not counterfactual.

Kiteworks secure data exchange does not expose a JWT token validation pipeline of the kind exploited in CVE-2026-55040, and it does not rely on a Business Connectivity Services-style integration layer for data access. Every request for content, human or machine, is mediated through the Kiteworks Control Plane, which enforces policy on a per-request, zero trust basis rather than granting durable, session-based trust to whoever presents a token. That distinction matters precisely because token-forgery and session-trust flaws are what made this month’s exploitation chain possible in the first place.

The compliance layer underneath that architecture matters just as much as the architecture itself. Kiteworks holds FedRAMP High In-Process designation and has maintained FedRAMP Moderate authorization continuously since 2017, nine consecutive years of third-party control validation that on-premises, customer-managed software cannot carry on its own; FedRAMP authorization attaches to a managed service, not to software an organization deploys and secures independently. Kiteworks also supports 90% of CMMC Level 2 requirements out of the box, uses FIPS 140-3 validated encryption, and maintains SOC 2 Type II and ISO 27001 certifications alongside ITAR, HIPAA BAA, GDPR, and CCPA support. None of that is a claim that Kiteworks is immune to every category of vulnerability; no platform earns that claim honestly. It is a statement about which categories of attack surface, unauthenticated JWT bypass and integration-layer RCE chained through a general-purpose collaboration platform, do not apply to how Kiteworks was built.

For organizations weighing what to do with sensitive workflows still running through on-premises SharePoint Server, the practical question is not whether to abandon SharePoint entirely. It is which workflows carry regulated or otherwise sensitive content that would be better served by a platform where access controls, RBAC, and evidence-quality logging are native to the architecture rather than layered on afterward through custom instrumentation.

What Regulated Organizations Should Do Now

Confirm patch status for CVE-2026-55040 and CVE-2026-63520 immediately if you operate on-premises SharePoint Server 2016, 2019, or Subscription Edition; this does not affect SharePoint Online. Do not stop at confirming the patch is applied. Rotate IIS machine keys and any credentials the server had access to, since Palo Alto Unit42’s finding that “patching alone is insufficient to fully evict the threat” was specifically about credential and key persistence surviving a patch. Review authentication and Business Connectivity Services logs for the exposure window between initial disclosure and patch application, and treat any gap in that logging as a finding in its own right, not just a technical inconvenience. Finally, inventory which sensitive or regulated workflows still run through on-premises SharePoint Server and evaluate whether each one needs the incident response and evidentiary burden this platform now carries, or whether it belongs on infrastructure built for governed, regulated data exchange from the ground up.

To learn more about mediating every data request through a zero trust Control Plane instead of a session-based authentication pipeline, schedule a custom demo today.

Additional Resources

• Blog Post Zero Trust Architecture: Never Trust, Always Verify
• Video Microsoft GCC High: Disadvantages Driving Defense Contractors Toward Smarter Advantages
• Blog Post How to Secure Classified Data Once DSPM Flags It
• Blog Post Building Trust in Generative AI with a Zero Trust Approach
• Video The Definitive Guide to Secure Sensitive Data Storage for IT Leaders