SharePoint Vulnerabilities: Why Active Exploitation Now Demands a Hardening Sprint

SharePoint vulnerabilities jumped to the top of the July 15, 2026 security agenda when BleepingComputer reported that attackers are actively exploiting three flaws against internet-exposed on-premises Microsoft SharePoint servers. This matters right now because the target set is not a niche dev tool or a forgotten lab appliance. It is a collaboration platform that still sits close to identity, internal content, and administrative workflows in many organizations.

The immediate risk is not limited to one patch cycle. According to CISA's alert, the exploitation pattern includes remote code execution, theft of IIS machine keys, persistence, and malware deployment. If your team still has any internet-facing SharePoint Server estate, this is the kind of story that should trigger a hardening sprint, not a background ticket.

Key Takeaway: If you run on-prem SharePoint, the immediate priority is simple: patch fast, verify your defensive controls, and assume exposed servers may already need artifact hunting.

Why SharePoint vulnerabilities are different this week

The reason this story stands out is that it combines active exploitation, multiple affected CVEs, and post-exploitation guidance that goes far beyond "install the patch." CISA says the exploited set includes CVE-2026-32201, CVE-2026-45659, and CVE-2026-56164, with the newest KEV addition on July 14 and same-day reporting pressure on July 15.

That creates a more serious operational picture than a routine Patch Tuesday summary. The issue is not just that a SharePoint box might crash or leak data. The issue is that a compromised server can become a platform for machine-key theft, deserialization abuse, persistent access, and malware staging inside an environment that often already has trusted relationships to directory services, SQL back ends, and internal users.

Security teams should also notice the exposure pattern. This is about supported on-premises SharePoint Server versions, not Microsoft 365 SharePoint Online. That distinction matters because many organizations assume their Microsoft cloud footprint is their real SharePoint story while quietly carrying forward older internal farms for document management, intranet publishing, line-of-business integrations, or regulatory retention workflows.

This is why the lesson fits alongside Hexon's recent posts on ShareFile Storage Zone Controller threat, Gitea Docker image auth bypass, FortiBleed Fortinet VPN credentials leak, and Windows Netlogon active exploitation. Different products, same failure pattern: one trusted internal service becomes an outsized attack path because it stayed reachable, privileged, or under-hardened for too long.

Key Stat: BleepingComputer cited Shadowserver data showing nearly 10,000 internet-exposed SharePoint servers, with more than 800 still unpatched against at least part of the exploited set.

What is being exploited right now

CISA's alert is unusually useful because it describes both the vulnerable versions and the attacker behavior. The agency says threat actors are exploiting the SharePoint flaws to gain unauthorized access to Subscription Edition, SharePoint Server 2019, and SharePoint Server 2016 deployments. From there, attackers can move into post-exploitation activity that includes stealing IIS machine keys and using deserialization techniques to maintain access and deliver malware.

That matters because stolen machine keys change the incident-response problem. Once an attacker gets hold of them, simple patching is no longer enough to restore trust. A team may patch the CVE, restart services, and still leave behind the cryptographic material that allows replay or persistence through other application behaviors.

This is exactly why CISA tells defenders to hunt for intrusion artifacts before rotating machine keys. If you rotate first and investigate later, you risk missing how the attacker got in, what webshells or harvesters remain, and whether the environment is still exposed through other misconfigurations.

The picture becomes more serious when you add the neighboring bugs. Microsoft also patched CVE-2026-55040 and CVE-2026-58644 in July, and those are not known to be exploited yet, but they increase the urgency around patching and exposure reduction. The practical takeaway is simple: an internet-facing SharePoint farm should not be treated as a stable legacy collaboration tool this week. It should be treated as an active attack surface.

Common Mistake: Treating SharePoint as "just another Windows server." In reality, it is an application platform with web app exposure, admin interfaces, service accounts, database ties, and cryptographic state that all matter during containment.

Why internet exposure is the real risk multiplier

The technical details matter, but the main strategic lesson is about exposure. CISA explicitly recommends that organizations avoid exposing SharePoint servers directly to the internet unless absolutely necessary. Where access is required, the agency recommends putting SharePoint behind a Layer 7 reverse proxy or equivalent application-layer control that can authenticate, inspect, and filter requests.

That advice is easy to skim past, but it is probably the most useful line in the whole incident. Many teams have accepted a legacy publishing pattern where SharePoint is reachable because "that's how the intranet works remotely" or because some vendor integration needed the path years ago. Attackers love those arrangements because they create a bridge from the public internet into a platform that already knows how to talk to the rest of the environment.

If that sounds familiar, stop thinking only in terms of CVE remediation and ask harder questions:

• Which SharePoint servers are reachable from the public internet right now?
• Which ones expose Central Administration or other sensitive paths externally?
• Which reverse proxies can actually inspect and filter malicious request patterns?
• Which farms still rely on exception rules created for remote work, contractors, or older partner access?

Those are not abstract architecture questions. They are the difference between patching an exposed platform and actually reducing exploitability.

The machine-key angle is what changes response urgency

When CISA warns about IIS machine-key theft, it is telling you the attacker objective is not only initial code execution. It is persistence and trust abuse after the first foothold. That makes this a worse business problem than a noisy crash or a single-file webshell incident because cryptographic state often outlives the first compromise window.

It also means SharePoint owners cannot handle this alone. This response belongs to application admins, Windows teams, security operations, and incident responders together. If your process still treats SharePoint as a narrow app-admin issue, this is where that model breaks.

Pro Tip: If you cannot quickly answer whether AMSI is enabled for every SharePoint web application, you are already behind the pace CISA expects for this incident.

What CISA and Microsoft want you to do now

The defensive guidance is more concrete than usual, which is useful. CISA says organizations should:

• apply the latest Microsoft patches and verify installation succeeded
• enable AMSI integration for each SharePoint web application
• use Full Mode request-body scanning where feasible
• monitor for suspicious SharePoint worker-process activity and anomalous requests
• hunt for webshells, machine-key harvesters, and other intrusion artifacts
• restrict or eliminate direct internet exposure
• block external access to SharePoint Central Administration

Microsoft's SharePoint Server hardening guidance gives the longer-term operational baseline behind those emergency steps. It is not a same-day document, and it should not be confused with the freshness gate, but it is the right supporting source because it helps teams translate the current alert into durable control changes.

The practical point is that a good response has two clocks:

1. The immediate clock for patching, monitoring, and exposure reduction.
2. The slower clock for reducing structural dependence on directly exposed, under-reviewed legacy SharePoint estates.

If you only satisfy the first clock, you may survive this week and still be back in the same position during the next SharePoint exploitation cycle.

A realistic hardening sprint for small and mid-sized teams

If you run a lean team, the phrase "hardening sprint" can sound bigger than it needs to be. You do not need a six-month platform transformation to make meaningful progress this week. You need a short list of high-leverage checks executed in the right order.

Start with exposure inventory. Confirm every public DNS name, reverse-proxy path, VPN exception, and directly reachable IP tied to SharePoint. Then verify patch status for each farm, not just the central one everyone remembers.

Next, validate AMSI coverage and logging depth. CISA's guidance is clear that request inspection and tailored telemetry matter here. If you cannot see suspicious request bodies, worker process anomalies, or indicators of machine-key harvesting, you are trying to defend blind.

After that, move to trust cleanup:

• rotate IIS machine keys only after artifact hunting
• remove or isolate unnecessary external exposure
• review service accounts and privileged integrations
• restrict farm-to-database communications to what is required
• lock down Central Administration access paths

Finally, decide whether any SharePoint workloads should be migrated, segmented, or decommissioned instead of repeatedly defended in place. This is where recent lessons from Oracle PeopleSoft zero-day extortion and other legacy-business-platform incidents become relevant. Old collaboration and ERP systems often stay online because retirement is inconvenient, not because the current risk is acceptable.

Key Takeaway: Your first goal is not perfect SharePoint security. It is cutting off the easiest exploit path, seeing what has already happened, and reducing the amount of SharePoint that can still surprise you next month.

The larger pattern behind this incident

The most important thing about this story is not the exact number of SharePoint CVEs. It is the recurring pattern of internet-reachable business infrastructure that quietly accumulates trust, exceptions, and administrative complexity until one wave of active exploitation turns it into a board-level problem.

That pattern keeps showing up because organizations are better at deploying collaboration software than retiring or hardening it. A platform that started as an intranet, portal, or document system eventually becomes a hub for workflows, identity assumptions, admin shortcuts, and historical integrations. Then it gets treated as too important to change and too familiar to scrutinize.

Attackers count on that. They do not need every exposed SharePoint server to be unpatched forever. They need enough of them to stay reachable, under-monitored, and woven into real business operations. This week's SharePoint vulnerabilities story is a reminder that the most dangerous systems are often the ones the business no longer thinks of as dangerous.

Final takeaway

If you run on-prem SharePoint, this is not a patch-and-forget week.

Treat SharePoint as a live attack surface. Patch it. Verify AMSI. Hunt before rotating keys. Pull it back from direct internet exposure wherever possible. And if your environment still depends on old, externally reachable SharePoint farms, use this incident as the forcing function to decide which ones still deserve that trust.