# SharePoint Is On Fire Again — And This Time the Exploit Is Already Public
When a proof-of-concept drops for a SharePoint remote code execution chain, the clock doesn't just start — it was already running. Security teams have hours, not days, before commodity actors absorb the technique and fold it into their toolchains.
That's the situation defenders are staring at right now. Hackers are actively targeting a chained exploit path in Microsoft SharePoint Server that achieves full remote code execution, and the PoC code has made its way into the open. The combination is one of the most predictable escalation patterns in enterprise security — and one that organizations consistently fail to outpace.
## Two Bugs, One Very Bad Day
What makes SharePoint RCE chains particularly ugly is the architecture of how they're built. Attackers aren't typically exploiting a single catastrophic flaw. They're threading together bugs that, in isolation, look manageable — an authentication bypass here, a privilege escalation or deserialization flaw there — and stacking them until the result is unauthenticated code execution on a server that sits at the center of enterprise document management and internal workflows.
That's what's happening here. The chain typically requires an attacker to first abuse an authentication-adjacent weakness to gain a foothold or elevated access, then trigger a second vulnerability to execute arbitrary code. The end result: full control over the SharePoint server process, access to documents, credentials, internal integrations, and in many cases a pivot point into the broader network.
The authentication bypass piece is what makes this particularly alarming. When exploitation doesn't require valid credentials, the attack surface expands from "compromised insider or phished employee" to "anyone who can reach the server." For organizations with SharePoint exposed to the internet — and there are a lot of them — that's a problem.
## The PoC Effect
There's a moment in the lifecycle of every serious vulnerability when everything changes: when working exploit code becomes publicly available.
Before a PoC, exploitation is limited to sophisticated actors — nation-state groups and well-resourced ransomware operators who develop their own tooling. After a PoC, the barrier drops to near zero. Script kiddies, opportunistic ransomware affiliates, and automated scanning infrastructure all pick up the capability within days. CISA's known exploited vulnerabilities catalog is littered with examples of this acceleration pattern.
The SharePoint RCE chain now has a working PoC in the wild. That means organizations that haven't patched are no longer racing against sophisticated attackers — they're racing against everyone.
## Who's Exposed
SharePoint Server — the on-premises version — is the primary target here. Microsoft's cloud-hosted SharePoint Online operates under a different architecture and update model, and Microsoft has already patched its own infrastructure. The exposure is concentrated in organizations running on-prem SharePoint deployments, which skews toward specific sectors:
The patching gap is well-documented. Enterprise organizations running SharePoint on-premises typically carry patch cycles measured in weeks to months, not days. The combination of patch complexity (SharePoint updates are notoriously involved), testing requirements, and change control processes means that even security-conscious organizations may be exposed for longer than they'd like to admit.
## What Attackers Do After They're In
SharePoint isn't just a document repository. In most mature enterprise deployments, it's deeply integrated — connected to Active Directory, linked to Teams, feeding workflows, storing sensitive business documents, and sometimes serving as a portal for internal applications.
An attacker with code execution on a SharePoint server has a remarkable set of options. They can harvest credentials from memory, pivot to connected services, establish persistence through web shells (a tactic that has historically been very effective against SharePoint), and exfiltrate documents at scale. The server's network position often makes it a natural jumping-off point for lateral movement.
Ransomware groups have been particularly drawn to SharePoint compromises in the past precisely because of this positioning. You hit SharePoint, you're often deep inside the enterprise network with access to files that actually matter.
## What Defenders Need to Do Now
Patch. Immediately. There's no softer version of this advice.
Microsoft released fixes for the underlying vulnerabilities in its patch cycle. Organizations running affected versions of SharePoint Server need to apply those updates on an emergency basis — not next patch Tuesday, not after the next change control meeting. Now.
Beyond patching, the response playbook for active exploitation:
Verify your exposure. Determine which SharePoint versions are running in your environment and whether they're internet-facing. Anything directly accessible from the public internet without a VPN or network-level access control is at immediate risk.
Check for web shells. Attackers who've already exploited the chain will likely drop persistence. Hunt for anomalous .aspx files in SharePoint directories, unusual outbound connections from the SharePoint server, and unexpected processes spawned from SharePoint application pools.
Review your network logs. Look for scanning patterns targeting SharePoint endpoints — the PoC going public will trigger automated scanning that's relatively easy to detect. Unusual POST requests to SharePoint API endpoints are worth investigating.
Isolate if you can't patch immediately. If emergency patching isn't feasible, consider pulling the SharePoint server off the internet and requiring internal network access until you can apply the fixes.
Monitor Microsoft's guidance. The company has posted mitigation recommendations alongside patches. Apply both.
---
## HackWire Analysis
This incident fits a pattern that's worth naming directly: the enterprise software vendor vulnerability lifecycle has a structural flaw, and organizations continue to pay for it.
Microsoft SharePoint has been a recurring target for over a decade. The platform's complexity — its deep integration with identity systems, its document hosting role, its network centrality — makes it high-value for attackers and difficult to defend. CVE-2019-0604 was exploited by APT actors including groups tied to nation-state operations. The 2023 SharePoint RCE chain involving CVE-2023-29357 and CVE-2023-24955 was flagged by CISA after active exploitation in the wild. The pattern hasn't changed: high-value target, complex patching, slow enterprise response, someone gets burned.
What's missing from most coverage of this story is honest accounting for the cloud migration question. Organizations still running on-premises SharePoint have made an increasingly difficult tradeoff — control and compliance at the cost of being responsible for their own patching. Microsoft patches its cloud infrastructure centrally; on-prem customers have to do it themselves. As RCE chains targeting on-prem deployments continue to emerge, the security calculus for that tradeoff shifts more decisively toward cloud.
There's also a less-discussed risk: SharePoint's integration surface. Even organizations that patch the server quickly may fail to check whether an attacker got in before the patch and left something behind. Web shell persistence in SharePoint environments can be remarkably durable. Detection teams should treat "we patched" and "we're clean" as two separate questions — because they are.
The PoC going public is the accelerant, but the underlying combustion is slow enterprise patching on a platform that has never stopped being a priority target. That's the problem that doesn't get solved by this week's patch.
— *HackWire Editorial*
---
## Related Coverage