IT Tips & Tricks
SharePoint Is Having a Rough Summer
Here’s What IT Needs to Know
Published 25 August 2026
If you’re responsible for an on-premises SharePoint® Server environment, summer 2026 has probably offered more “excitement” than anyone wanted.
There must be better ways to spend the lazy dog days of summer than reading security advisories over cold coffee, comparing SharePoint builds and wondering whether the words “remote code execution” are about to rearrange your week.
Are the words “remote code execution” about to rearrange your week?
Yet SharePoint security has demanded exactly that kind of attention.
Microsoft®, CISA and security researchers have documented a succession of serious SharePoint vulnerabilities during 2026. Some have been actively exploited. Others can become far more dangerous when combined.
For IT managers, MSPs and migration consultants, the practical message is simple: Patching matters, but understanding the environment around the patch matters too.
It’s Not Just Another Patch
Microsoft’s 9 June security update for SharePoint Server Subscription Edition addressed several security issues, including remote code execution (RCE) vulnerabilities.
Then July brought CVE-2026-55040. This vulnerability involves weak authentication in SharePoint Server. An attacker can exploit it over a network to bypass a security feature. Microsoft assigned it a Common Vulnerability Scoring System (CVSS) score of 9.1, placing it firmly in critical severity territory.
A critical CVSS score describes the severity of the vulnerability. It doesn’t mean every vulnerable server has been breached, but it does mean that “we’ll get to that next maintenance cycle” could be an uncomfortable attitude to explain later.
And then came August, and the picture became even more complicated.
Cybersecurity weaknesses have an unfortunate habit of making two plus two equal something much bigger than four.
Cybersecurity firm Rapid7 disclosed CVE-2026-63520, a SharePoint remote code execution vulnerability affecting supported versions of SharePoint Server. Successful exploitation can allow arbitrary code execution with the privileges of the Windows service account running the SharePoint site.
More importantly, Rapid7 demonstrated that CVE-2026-63520 can be chained with CVE-2026-55040 to create a critical unauthenticated remote code execution path.
That matters because security teams can’t always evaluate vulnerabilities as isolated entries in a spreadsheet. One weakness may open a door while another provides the route through the building. Cybersecurity weaknesses have an unfortunate habit of making two plus two equal something much bigger than four.
Some SharePoint Attacks Are Already Happening
The newly disclosed exploit chain also intersects with vulnerabilities already being used in real-world attacks.
In July, the Cybersecurity and Infrastructure Security Agency (CISA) warned that threat actors were actively exploiting several vulnerabilities affecting supported on-premises SharePoint Server versions. Reported activity included unauthorized access, remote code execution, theft of Internet Information Services (IIS) machine keys, persistence techniques and malware deployment.
On 18 August, CISA also added CVE-2026-55040 to its Known Exploited Vulnerabilities Catalog based on evidence of active exploitation.
CISA’s guidance goes well beyond “install the update.”
Organizations are advised to apply Microsoft’s latest patches, confirm that installation completed successfully and shorten patch cycles where possible. Administrators should also verify that appropriate security controls are enabled, review relevant telemetry and investigate signs that a vulnerable system may already have been compromised.
There’s a big difference between asking, “Are we patched now?” and asking, “What might have happened before we patched?”
The first is patch management. The second is security.
Why SharePoint Makes an Attractive Target
SharePoint is valuable because organizations have spent years making it valuable. A mature environment may contain contracts, financial information, engineering material, HR records, project histories, policies, procedures and intellectual property. It may also sit inside business processes that nobody thinks of as “SharePoint processes” anymore. Users simply know that this is where the work happens.
Avoid direct internet exposure for SharePoint Servers unless necessary.
Apps may depend on documents stored there. Teams may rely on long-established libraries. Spreadsheets may reference other files or data sources. Word documents can contain links to supporting files. Simple-looking workflows can hide a surprisingly elaborate web of dependencies.
That concentration of information and connectivity makes SharePoint useful to a business. It can also make a compromised server useful to an attacker.
Protecting SharePoint, therefore, means protecting more than just a web application. It means protecting part of the organization’s information architecture.
A Quick Note to MSPs (and IT Departments with Tech-Challenged Users)
For Managed Service Providers, one of the bigger risks isn’t that most clients misunderstand what a vulnerability is. It’s that they assume patching is the whole response. This same misconception can also cause problems for in-house IT departments who support a lot of inexperienced and “tech-challenged” users.
That usually shows up in behavior. If the first question is “Did the patch install?” but nobody is asking what was exposed before it went in, whether the SharePoint environment was internet-facing, whether logs were retained or whether anyone reviewed suspicious activity, the response may be too narrow.
The same is true if nobody can quickly answer which SharePoint servers are still in production, which web applications are externally reachable or whether the environment is running a supported build.
A useful MSP conversation should therefore go beyond “Are you patched?” Ask your client whether they can account for every SharePoint server in the environment, whether patch levels are consistent across nodes, whether security telemetry is available for the relevant period and whether there is a defined escalation path if evidence of compromise appears.
Then run the environment through the checks below.
What IT Teams Should Do Now
Start with the SharePoint environment itself.
Inventory every SharePoint server, web application, site collection and content database still in use. SharePoint Management Shell can help: Get-SPProduct reports on installed products and update versions, while Get-SPWebApplication, Get-SPSite and Get-SPContentDatabase help administrators inventory the web applications, site collections and content databases in the environment. Central Administration’s Upgrade and Migration pages can also show product and patch status across servers.
Don’t rely on a single SharePoint build number to confirm that the whole environment is fully patched. Check each server for missing updates, pending restarts or an upgrade-required status. Microsoft recommends keeping all servers in a SharePoint deployment at the same update and upgrade level.
A client may hear “the vulnerability is patched” as “the security incident is over.” But we both know those aren’t the same thing.
Next, verify the controls around the environment. Confirm that the Antimalware Scan Interface (AMSI) integration is enabled and functioning for supported deployments, and make sure antimalware protection is active rather than merely installed.
If compromise of ASP.NET machine keys is suspected, SharePoint supports rotating them through Central Administration or PowerShell using cmdlets such as Set-SPMachineKey and Update-SPMachineKey.
After patching, verify the deployment. Review SharePoint and IIS logs, confirm database upgrade status and check that service applications, sites and search are behaving normally. Pay attention to database synchronization issues and customizations that may not respond cleanly to an update.
CISA also recommends avoiding direct internet exposure for SharePoint Servers unless necessary. Where exposure is required, CISA recommends placing the server behind a Layer 7 reverse proxy or equivalent application-layer security control that requires authentication and can inspect and filter requests.
Finally, use the inventory to identify obsolete web applications, abandoned site collections, little-used content databases and servers that may no longer be needed.
That tells you what exists. Dependency analysis helps reveal what still depends on it. LinkFixer Advanced™ can expose file relationships, broken links and cross-file dependencies before a migration or cleanup creates user-facing problems.
Security Can Expose a Second Problem: Data Dependencies
Security remediation often leads to infrastructure change.
An organization may decide to retire a legacy server, consolidate sites, reorganize libraries, restore content or accelerate a planned migration. A security event can turn a leisurely modernization project into a much more urgent one. That creates another risk.
Security is more than constant patching.
Files don’t always live independently of one another.
Excel workbooks reference other workbooks. Documents contain hyperlinks to files elsewhere in the environment. OLE links, images and SharePoint content can depend on paths or locations that change when data moves. And on and on it goes.
A migration can therefore succeed at moving every file while damaging the relationships between those files. Everything arrived, but nothing’s connected the way it used to be.
That’s where LinkFixer Advanced fits into the broader conversation.
LinkFixer Advanced is designed to identify, protect and repair file links when files and folders are moved, renamed or migrated, including migrations involving SharePoint. It can help teams understand file relationships before a move, preserve working links through migration and automatically repair broken links afterward.
For migration consultants and MSPs, that visibility can uncover dependencies before users discover them the hard way.
None of this replaces security patching, threat detection or incident response. It solves a different problem.
Security asks whether your SharePoint environment is protected from unauthorized access. Dependency management asks whether the information inside that environment will continue to work when you change where it lives.
Large IT projects often need both answers.
“We Patched It” Shouldn’t End the Conversation
The recent SharePoint vulnerabilities are a reminder that familiar infrastructure can become easy to overlook. SharePoint may feel ordinary because people use it every day. The information stored inside it, however, is anything but ordinary.
For IT teams operating on-premises SharePoint, the immediate priorities are clear: Identify every exposed server, verify patch consistency across the deployment, confirm that AMSI and antimalware protections are functioning, inspect SharePoint and IIS telemetry for signs of exploitation, and rotate ASP.NET machine keys where compromise is suspected.
Then widen the lens.
Hopefully, you’ll never need it, but always have an emergency response plan in place.
Know what’s stored there. Know what still needs to be there. Know which files, applications and processes depend on one another. If security concerns lead to a migration or restructuring project, protect those relationships as deliberately as you protect the files themselves.
A patched server is better than an unpatched server. A secure, well-understood environment is better still. And if the phrase “critical SharePoint vulnerability” causes everyone in the room to look meaningfully at somebody else, there may be one final item to digest:
A critical vulnerability is a bad time to discover that “we’ll figure it out” is the SharePoint response plan.
By Ed Clark
LinkTek COO
Ed Clark
Feel free to share this article on your social media:
Recent Comments
- No recent comments available.
ChatGPT,
Gemini,
Claude and
Copilot
Leave a Comment