The July 2026 alerts around Microsoft SharePoint are a reminder of a lesson security teams learn repeatedly: a patch closes the door, but it does not automatically erase what may already have been stolen. For internet-facing SharePoint instances, the priority is therefore not only to install the update. Teams also need to determine whether attackers may have obtained secrets that let them return.

CERT-FR and CERT-EU have warned about several critical vulnerabilities affecting SharePoint Server, including CVE-2026-50522 and CVE-2026-58644. These flaws can enable remote code execution on vulnerable on-premise versions. The most worrying detail is operational: active exploitation has been observed, with a risk that ASP.NET machine keys may have been stolen.

Why machine keys matter

In many incidents, teams follow a simple reflex: identify the vulnerable server, apply the patch, restart it and confirm that the vulnerability scanner turns green. That is necessary, but insufficient when application secrets may have left the server.

ASP.NET machine keys help protect and validate some state, ticket and cryptographic mechanisms used by .NET applications. If an attacker obtains them, they may be able to preserve a path back even after the vulnerability has been patched. That is why CERT-FR recommends changing secrets, including machine keys, when compromise is suspected.

The logic is the same as with an administrator password or API key. Fixing the bug that enabled theft does not make the stolen secret useless. The secret has to be replaced.

The scope to handle

The first step is to inventory affected SharePoint servers: version, internet exposure, role in the farm, last patch date, service accounts, connected systems, access to file shares, SQL databases, directories and sensitive document repositories.

A SharePoint instance is not just a web server. It often sits at the center of document flows, internal workflows and older authentication patterns. A compromise can therefore extend beyond the site itself: confidential documents, service identities, tokens, maintenance scripts, exports and history.

Servers directly reachable from the internet should come first. If exposure is still required, it should be justified again. In many organizations, on-premise SharePoint remains exposed because it has always been exposed, not because a current risk review says it should be.

What to do after patching

After applying Microsoft updates, verify the actual binary versions, not only the Windows Update state. Also confirm that every node in the farm has been treated. A partially patched farm remains fragile.

Then comes secret rotation. ASP.NET machine keys should be replaced according to Microsoft procedures for the environment. Service accounts, application secrets and exposed credentials should also be reviewed. This is inconvenient, but it avoids assuming that a cleaned server is controlled while a compromised secret is still circulating.

Compromise assessment should cover IIS logs, SharePoint logs, abnormal processes, web shells, scheduled tasks, new accounts, configuration changes and unusual outbound connections. Preserve evidence before cleanup, especially if the incident may have regulatory or contractual impact.

The legacy-server trap

On-premise SharePoint illustrates a broader problem: historical applications remain critical long after they stop appearing in the roadmap. They host important documents, but daily operations may depend on knowledge scattered across former teams, vendors and outdated procedures.

When a critical vulnerability arrives, that operational debt becomes visible. Who knows how to apply the patch? Who understands the dependencies? Who can cut external access without breaking a business process? Who knows how to restore? Who owns the secrets? These questions should be answered before the incident.

The pragmatic response

The realistic response fits into five actions: patch quickly, remove unnecessary exposure, perform compromise assessment, rotate secrets and document what was done. Everything else depends on context, but these five points avoid the most dangerous mistake: treating a patch as if it erased the incident.

The SharePoint vulnerabilities of July 2026 are not only a Microsoft issue. They show that the security of an exposed service depends as much on post-exploitation response as on patch speed.