SharePoint CVE-2026-50522: Machine Key Theft Means Patching Alone Won't Evict the Attacker

Last verified: July 23, 2026. Facts about active exploitation can change daily, so check Microsoft's advisory and CISA's KEV entry for the latest.

On July 22, 2026, CISA added CVE-2026-50522 to its Known Exploited Vulnerabilities catalog and gave federal civilian agencies until July 25 to remediate. A three-day deadline is the kind of signal CISA uses when exploitation is not theoretical.

The facts, briefly. CVE-2026-50522 is a CVSS 9.8 deserialization-of-untrusted-data flaw in on-premises Microsoft SharePoint Server. Microsoft patched it in its July security update, and public exploitation moved quickly after proof-of-concept details appeared. Offensive-security firm watchTowr reported successful honeypot compromises during the exploitation wave.

By at least one count this is the fourth SharePoint Server vulnerability confirmed under active exploitation in the past month. The exact count may shift as advisories update, but the pattern is clear: on-premises SharePoint is being hit repeatedly, and attackers are moving faster than normal patch windows.

Why this one is worse than a normal 9.8

The exploitation risk does not stop at code execution. Attackers may use SharePoint exploitation to obtain ASP.NET machine keys, the cryptographic material SharePoint uses to sign and validate authentication state. Once that material is exposed, the incident becomes more than a software patching problem.

A stolen password is revoked with a reset. A stolen machine key can allow forged authentication material that the server trusts, and that capability can survive the patch if the keys are not rotated. You can apply the update and still leave a persistence path behind.

That is why the right response is patch, rotate, hunt, and then reduce exposure. The vulnerability is a software bug. The aftermath is an identity persistence and exposure problem.

Do these now, in this order

1. Patch. Apply the July 2026 security update for your SharePoint version. Nothing below substitutes for this. Federal agencies should treat the CISA KEV deadline as the clock.
2. Rotate machine keys. If your servers were internet-reachable and unpatched during the exploitation window, assume key exposure. Microsoft documents machine-key rotation through Update-SPMachineKey or the Central Administration rotation job, followed by IISReset.
3. Hunt. Review IIS logs for suspicious requests to SharePoint authentication endpoints, look for newly written .aspx files and web shells, and treat confirmed pre-patch exposure as a compromise investigation, not a ticket closure.
4. Reduce the exposure that made this possible. That is the posture change for the next SharePoint CVE.

The pattern behind repeated SharePoint exploitation

Step back from the individual CVE and look at the shape of the campaign. These attacks depend on an on-premises SharePoint endpoint being reachable over the network during the vulnerable window. If that endpoint is directly internet-facing, exploit traffic can reach SharePoint before any user identity, MFA policy, or conditional access decision is involved.

SharePoint Online customers are insulated differently because Microsoft operates and patches the service. On-premises SharePoint remains common for data residency, compliance, integration, and legacy workflow reasons. Those reasons are real, but they make direct exposure risky when exploit-to-compromise timelines are measured in hours.

The posture fix: stop letting anonymous traffic reach SharePoint

The zero-trust answer for an on-premises web application like SharePoint is an identity-aware reverse proxy in front of it. Every request authenticates against your identity provider, such as Microsoft Entra ID or Okta, and passes MFA at the proxy before anything is forwarded to SharePoint. This is the access-layer pattern behind Datawiza Access Proxy, and Datawiza has a SharePoint on-premises Entra ID SSO and MFA integration guide for the deployment pattern. The same access-proxy pattern can also work with other identity providers, including Okta, Ping, Cisco Duo, Google Identity, and others.

• Anonymous exploitation dies at the proxy. An unauthenticated request from the internet does not reach the vulnerable SharePoint endpoint because the proxy requires a valid, MFA-verified identity session first.
• Your exposure window shrinks. The dangerous period between disclosure and patch deployment stops being an open door to the entire internet.
• Incident review changes shape. Instead of asking which anonymous internet traffic reached the endpoint, access logs are tied to named, IdP-verified identities.
• Conditional access applies to an older app. Device, location, and risk policies from Entra ID or Okta can govern access to a platform that predates those controls.

What the proxy honestly does not do

• It does not patch the vulnerability. Patch first, always.
• It does not invalidate stolen machine keys. If your keys were exposed before you put controls in place, only rotation revokes them.
• It does not stop an attacker who already holds valid, MFA-passing credentials for your IdP. It removes the anonymous path, which is the path broad exploitation campaigns depend on.
• It only helps if it is the only door. Firewall the SharePoint servers so they accept traffic solely from the proxy. A proxy in front of a server that is still directly reachable is a decoration.

Patch, rotate, hunt, and then make sure the next SharePoint CVE lands on a server the internet cannot talk to anonymously.

Related reading

• An Alternative to Entra App Proxy: When Datawiza Access Proxy Is the Better Fit
• What Is No-Code MFA?
• Datawiza SharePoint on-premises Entra ID SSO and MFA integration guide The same access-proxy pattern can also work with other identity providers, including Okta, Ping, Cisco Duo, Google Identity, and others.

See how Datawiza adds Entra ID or Okta SSO and MFA in front of on-premises SharePoint in a 30-minute demo.

Book a demo

Frequently asked questions

Does CVE-2026-50522 mean patching is enough?

No. Patching closes the software flaw, but if machine keys were exposed before the patch, rotation is required to revoke the forged-token persistence path. Patch first, rotate keys, then reduce exposure.

Can a reverse proxy replace the SharePoint security update?

No. A proxy is exposure reduction and a compensating control. It should never be used as a substitute for applying Microsoft security updates.

How does access-layer MFA help on-premises SharePoint?

Access-layer MFA requires a valid identity session before traffic reaches SharePoint. That removes the anonymous internet path and lets teams apply IdP policies to older SharePoint deployments without changing SharePoint application code.

What should teams do after patching SharePoint?

Rotate machine keys, restart IIS, hunt for evidence of exploitation, then restrict SharePoint so inbound traffic reaches it only through the approved proxy or gateway path.