Breach · Access Control

Swiss Government SharePoint Breach Compromised Around 200 Accounts

August 7, 2026 · 5 min read

Switzerland's Federal Office for Information Technology and Telecommunication, known as FOITT or BIT, disclosed on August 4, 2026 that attackers had compromised approximately 200 user and technical accounts on its on-premises Microsoft SharePoint servers. The agency manages around 50,000 workstations and over 1,000 applications for Swiss federal government workers, which puts this incident in the category of a breach worth paying close attention to regardless of where your own SharePoint instances live. The window between Microsoft's July 14 Patch Tuesday and confirmed in-the-wild exploitation was measured in days, and FOITT's experience illustrates exactly how quickly that window closes.

What actually happened

FOITT security specialists first detected anomalies on the SharePoint servers on July 28, 2026. By July 31, the scope was clear: roughly 200 accounts had been compromised. Public disclosure followed on August 4, 2026, with FOITT confirming it was working alongside the Swiss Federal Office for Cyber Security (NCSC) and Microsoft to investigate and remediate. The attackers are described as previously unknown actors, and no threat group or nation-state attribution has been confirmed as of this writing.

The attack is believed to have exploited vulnerabilities that Microsoft disclosed and patched on July 14, 2026, as part of its Patch Tuesday release that month, a release that addressed 622 vulnerabilities in total. Two CVEs are suspected based on timing and attack profile, though FOITT has not officially confirmed which specific flaws were used. CVE-2026-56164 is a missing-authentication privilege escalation flaw in SharePoint Server that Microsoft confirmed was actively exploited in the wild and that CISA added to its Known Exploited Vulnerabilities catalog on July 14. CVE-2026-50522 carries a CVSS score of 9.8, exploits deserialization of untrusted data for remote code execution, and enables attackers to steal SharePoint machine keys via a single HTTP request. CISA added CVE-2026-50522 to KEV on July 22, requiring federal civilian agencies to remediate by July 25. WatchTowr's global honeypot network observed active exploitation of that flaw on July 20, hours after a public proof-of-concept was released.

CISA issued its initial SharePoint hardening alert on July 14, 2026, citing active exploitation of multiple CVEs including CVE-2026-56164, and updated the alert on July 22 to include CVE-2026-50522.

On the day anomalies were detected, FOITT reset passwords for all affected accounts and blocked external internet access to the SharePoint environment. A full reinstallation of the compromised servers is underway. Investigations found no evidence that data was exfiltrated beyond the compromised credentials themselves, and FOITT policy prohibits storing confidential or sensitive personal data on the affected platform. The agency also shared technical indicators of compromise with Swiss critical infrastructure operators through the NCSC's platform.

Why this should matter to you even if you don’t run Microsoft SharePoint

If your organization runs on-premises SharePoint, or any on-premises Microsoft workload for that matter, this incident should prompt a direct question about your patch deployment timeline. The gap between Microsoft's disclosure on July 14 and FOITT's detection of anomalies on July 28 is fourteen days. That is roughly the window organizations have before unpatched critical SharePoint flaws become active attack surface, based on what we saw here. Public proof-of-concept code appeared within days of the patch, which compressed that window further for anyone monitoring threat feeds but had not yet applied the fix.

The machine key theft angle on CVE-2026-50522 deserves specific attention. When an attacker steals SharePoint machine keys, they can forge authentication tokens and maintain persistent access even after passwords are reset and patches are applied. That is a forensic and recovery problem that goes well beyond a standard patch-and-move-on response, and it is part of why FOITT chose full server reinstallation over remediation in place. If you manage on-premises SharePoint and have not audited your machine keys recently, that is worth doing regardless of whether you believe you were targeted.

FOITT manages infrastructure at a scale most private organizations will not reach, but the underlying exposure is identical. On-premises SharePoint installations require the same patch discipline, the same network segmentation, and the same account monitoring as any other externally reachable server. The fact that FOITT had a policy against storing sensitive data on this particular platform limited the blast radius considerably. Organizations that have not made explicit decisions about what data lives where on their collaboration platforms are carrying a risk they may not have fully priced in.

The control that would have blunted it

The control that would have blunted this attack most directly is a disciplined, time-bound patch management process with explicit SLAs for critical and actively exploited vulnerabilities. That sounds obvious, but the operational reality is that on-premises SharePoint patching is often slower than cloud-managed equivalents because it requires scheduled maintenance windows, regression testing, and coordination across teams. Those friction points are real and understandable, but they need to be factored into your risk posture explicitly rather than treated as background noise. A patch that Microsoft releases on a Tuesday alongside 621 other fixes can look like one item in a long queue. When CISA simultaneously flags active exploitation, it belongs in a separate, accelerated queue with a named owner and a deadline measured in days.

Beyond patch velocity, the access control piece here is worth examining. Approximately 200 accounts were compromised, described as a mix of user and technical accounts. Technical accounts, meaning service accounts and application accounts, often carry elevated permissions and are less likely to have behavioral monitoring applied to them than human accounts. Mapping out what permissions your SharePoint service accounts hold, and enforcing least privilege on them, limits what an attacker can do after gaining initial access through a vulnerability like CVE-2026-56164. Cyber insurers increasingly ask about privileged access management and least-privilege enforcement as underwriting criteria, and this is exactly the scenario those questions are probing for.

Network segmentation also played a role in FOITT's response: blocking external internet access to SharePoint was one of the first containment actions taken. If your SharePoint environment is reachable from the internet and that exposure is not a documented, deliberate decision with compensating controls attached to it, that is worth revisiting. Reducing the attack surface by restricting external access to collaboration platforms, or fronting them with a properly configured reverse proxy and multi-factor authentication, raises the cost of exploitation materially. None of these controls are free in terms of administrative overhead and potential friction for end users, but they are the kind of layered approach that makes the difference between a contained credential compromise and a broader environment-wide incident.

If you want to understand where your SharePoint environment and broader cloud workload posture stand relative to current attacker techniques and insurer expectations, our Cloud Security Assessment is designed to give you that picture with specific, actionable findings rather than a generic scorecard.