ToolShell, SharePoint – and the Convenience of Losing Control
Katrin Peter 4 Minuten Lesezeit

ToolShell, SharePoint – and the Convenience of Losing Control

Why security vulnerabilities are not just technical risks but should provoke political decisions

Why security vulnerabilities are not just technical risks but should provoke political decisions

The newly discovered security vulnerability CVE-2025-53770, known in expert circles as “ToolShell”, once again reveals a fundamental dilemma of modern IT: the growing discrepancy between technical feasibility and strategic dependency. This time, Microsoft’s SharePoint is affected – specifically the On-Premise versions Enterprise Server 2016 and Server 2019. The cloud variants? Of course not.

And here begins the real problem.


A Systemic Vulnerability – Technical, Economic, Strategic

The vulnerability allows Remote Code Execution via manipulated HTTP requests. An attacker doesn’t need to compromise a user or bypass authentication – a targeted request is enough. The result: full access to the server, theft of ASP.Net Machine Keys, persistence through forged tokens. It hardly gets more critical.

Microsoft has provided patches for some versions, but not for SharePoint 2016 – even though this version is still in use in many government agencies, medium-sized companies, and institutional environments. Even where updates are available, additional measures are necessary: Key rotation, IIS restart, manual compromise checks.

And yet, it’s not just the technical complexity that raises questions. It’s the – by now almost ritualized – realization that Microsoft’s cloud offerings regularly “coincidentally” remain unaffected by these problems.


“The Cloud is Secure” – Says the Provider of the Vulnerability

In Microsoft’s communication about the ToolShell vulnerability, there is a remarkable sentence:

“Microsoft’s cloud offerings are not affected.”

A statement that is technically correct – but strategically significant. Because while On-Prem customers struggle with updates and workarounds, while systems are compromised and forensic teams must be activated, Azure presents itself as an island of stability. Secure, low-maintenance, worry-free.

But this security comes at a price. And that is too often overlooked in the debate.


The Silent Migration into Lock-In

What the industry celebrates as “modernization” or “cloud-first strategy” is often nothing more than a strategically orchestrated loss of control. Step by step, IT decision-makers lose sovereignty over their systems. First comes dependency on the patch cycle. Then on the platform. Then on the provider’s roadmap. And finally on its legal framework.

Because what runs in Azure is not subject to the GDPR – but to the CLOUD Act. And at the latest since Microsoft had to admit under oath that no protection against US access can be guaranteed, it should be clear: The cloud is not the better data center. It is another country – with different laws, different interests, and different accesses.

Those who migrate into this world do not just give up maintenance. They also give up sovereignty.


Why Alternatives are Not Just “Well-Intentioned”

Yet they already exist: German providers operating containerized platforms, focusing on security, traceability, and control. Managed Kubernetes. Self-Hosted GitOps. Service meshes for isolation and tenant protection. All available, all proven. And: all under European jurisdiction, auditable, traceable – sovereign.

But these providers lack a billion-dollar marketing apparatus, no event budgets for CIO summits, no budgets for incentives. They convince with substance instead of symbolism. And precisely because of this, they run the risk of being overlooked – by those who confuse short-term relief with long-term dependency.


The True Core of the Debate

ToolShell is not an isolated incident. It is an example of a systemic problem:

Security vulnerabilities are one danger. The reaction to them is another.

When patches are delayed. When cloud solutions are overemphasized, alternatives ignored, and risks relativized. Then no secure digital state emerges – but a vulnerable one. One that cares more about scalability than sovereignty. One that no longer decides for itself but is dependent on platforms that could withdraw access at any time.


Conclusion: Those Who Want Responsibility Must Retain Control

IT security is not a product. It is an architectural question. A question of responsibilities. And a question of whether we design our digital infrastructure so that it still functions when political, economic, or regulatory interests change.

Microsoft’s cloud offerings may seem convenient – but convenience is rarely a good advisor for resilience.

Because in the end, the central question remains:

Who owns our digital future – and to whom are we ultimately at the mercy?