Hackers Are Now Chaining Two SharePoint Bugs to Take Over Servers
A public proof-of-concept turned into live attacks within a day, and researchers are watching the full two-step break-in play out in honeypots.

Key points
- Attackers are chaining two Microsoft SharePoint flaws, CVE-2026-55040 and CVE-2026-63520, to run their own code on unpatched servers.
- Security firm Defused saw the first flaw exploited within a day of a public proof-of-concept being posted on August 11.
- By August 25, Defused reported both flaws being used together against its decoy servers.
- Shadowserver counts more than 8,700 SharePoint servers reachable from the open internet.
- CISA ordered US federal agencies on August 18 to patch the first flaw, and has since confirmed a separate SharePoint bug is being used in ransomware attacks.
Microsoft SharePoint, the platform companies run to share internal documents, is under active attack again. Criminals are stringing together two separate bugs to break in and run whatever code they like on servers that haven't been patched.
The warning comes from threat intelligence firm Defused, which watched the attacks land in its honeypots, decoy servers built to attract hackers so defenders can study them. First reported by BleepingComputer, the activity started almost immediately after researchers published working exploit code online.
How does the attack actually work?
Two flaws, used back to back: one gets attackers through the door, the other lets them own the server.
The first bug, CVE-2026-55040, sits in the way SharePoint validates JSON Web Tokens, the small signed passes that prove a user is logged in. Someone with no account at all can trick the server into treating them as a site user or administrator. The lock exists; the key check is broken.
The second, CVE-2026-63520, lives in Business Connectivity Services, a SharePoint feature that pulls data from external business systems. Chain it after the first flaw and an attacker can run arbitrary code on the server, which is what remote code execution means in practice.
Rapid7 researcher Stephen Fewer published working exploit code for CVE-2026-55040 on August 11. VulnCheck's Jonathan Peterson released equivalent code for CVE-2026-63520 on August 24. Defused says Fewer's code was being fired at real servers within 24 hours. By August 25 Defused was seeing the full chain probed against its honeypots, with the token bypass followed by heavy admin enumeration and probing of the Business Connectivity Services sink. No confirmed code execution yet, but the scaffolding is clearly in place.
Who is at risk?
Any organisation running its own SharePoint server that's reachable from the internet. Shadowserver, a non-profit that scans the public internet, currently counts more than 8,700 exposed SharePoint instances, though how many are already patched or are themselves honeypots isn't known.
CISA told federal agencies on August 18 to secure their SharePoint servers against attacks using the first flaw. We've tracked SharePoint vulnerabilities since 3 July, and this is the eighth story in that run. Microsoft has flagged CVE-2026-63520 as an attractive target but hasn't marked it as exploited in the wild.
What should IT teams do now?
Patch, and stop putting SharePoint on the open internet if you can avoid it. That's CISA's blunt guidance, and it applies directly here.
| Bug | What it does | Public exploit released |
|---|---|---|
| CVE-2026-55040 | Bypasses login checks on SharePoint | August 11 |
| CVE-2026-63520 | Runs attacker code via Business Connectivity Services | August 24 |
| CVE-2026-45659 | Separate SharePoint flaw, now used in ransomware | Exploited since early July |
Since November 2021, CISA has flagged 15 SharePoint flaws as actively exploited, eight of them also picked up by ransomware gangs. On Tuesday CISA confirmed CVE-2026-45659, a separate SharePoint bug, has now been folded into ransomware campaigns too.
Should MFA have protected anyone here?
No. CVE-2026-55040 forges the token that proves a user is already signed in, which comes after multi-factor authentication has finished its job. This one lands entirely on patching and network exposure, not on the login screen.



