SerpApi.Org
Microsoft today published manual remediation guidance — KB5121986 — for IT administrators whose production Windows Server Update Services servers remain unable to sync with Microsoft Update, eight days after a server-side metadata accumulation problem knocked enterprise patch pipelines offline and left two actively exploited zero-days undeployed across thousands of corporate networks.
The manual fix arrives with urgency attached: the vulnerabilities held hostage by the WSUS outage are among the most dangerous in July 2026's record-breaking Patch Tuesday release — and one of the two federal remediation deadlines has already passed.
The incident underscores a structural risk that has been compounding for more than a year. July's failure is the fourth WSUS synchronization outage in fourteen months — and it is occurring on a product Microsoft officially deprecated in September 2024, meaning no engineering investment in reliability improvements is planned.
What Broke — and Why
By default, WSUS syncs once daily with Microsoft Update servers to pull fresh metadata for available Windows patches. That metadata — covering product categories, update classifications, applicability rules, supersedence relationships, and detectoid logic — accumulates in a SQL database called SUSDB (SQL Server Update Services Database). On servers affected by this incident, that accumulated metadata load exceeded the ceiling that Microsoft's IIS-hosted WsusPool application pool could process per sync request, causing operations to time out or fail entirely.
The result: on impacted WSUS servers, administrators were unable to discover, approve, or distribute new patches through WSUS or through Microsoft Configuration Manager, which uses WSUS as its upstream catalog source.
Microsoft confirmed the scope in its Windows release health dashboard: organizations might experience increased synchronization times or sync operation timeouts on WSUS servers, with heightened impact observed starting July 13, 2026 — one day before July's Patch Tuesday releases began to flow. Administrators running WSUS hierarchies saw failures cascade from parent servers to replicas, since the sync pipeline runs at every level.
Unlike some prior WSUS incidents, this failure did not originate on client machines or stem from a faulty cumulative update. The defect was entirely on Microsoft's publishing infrastructure: excess metadata accumulated on the service side and within existing WSUS installations, making synchronization increasingly expensive until it failed.
Two Exploited Zero-Days Waiting on the Other Side
The timing could not have been worse. July 14 — one day after the WSUS outage intensified — Microsoft released what its own tracking confirms as the largest Patch Tuesday in the program's history: 622 CVEs, including three zero-days.
Two of those zero-days are confirmed as actively exploited before patches were available, and both have been added to CISA's Known Exploited Vulnerabilities catalog.
CVE-2026-56164 affects on-premises SharePoint Server — covering the 2016, 2019, and Subscription Edition builds — and allows an unauthenticated attacker to escalate privileges over the network with no credentials and no user interaction required. Microsoft scored it 5.3 (Moderate), a rating the security industry has uniformly rejected: the National Vulnerability Database independently assessed it at 9.8 (Critical). CISA added it to the Known Exploited Vulnerabilities catalog on July 14 and set a federal remediation deadline of July 17 — a deadline that has already passed.
CVE-2026-56155 affects Active Directory Federation Services (AD FS), the service that issues and signs authentication tokens trusted by every application federated to it. An attacker who exploits it gains local administrative control over the AD FS host — and from there, the ability to forge tokens that impersonate any user across every connected service. Microsoft's own Detection and Response Team (DART) — the company's incident-response unit — is credited with discovering it, a detail that signals it was found during live attack investigations. The federal remediation deadline for CVE-2026-56155 is July 28.
For organizations relying on WSUS to distribute patches, both vulnerabilities remained undeployed while the sync pipeline stayed broken. That is the specific injury the manual guidance released today is designed to remedy.
How the Partial Fix Left Production Servers Behind
Microsoft moved on July 18 to address the issue — but with a significant limitation. The service-side mitigation restored normal synchronization performance for newly installed or rebuilt WSUS servers only. Production WSUS servers with years of accumulated metadata — the vast majority of enterprise deployments — were left waiting.
Microsoft confirmed that synchronization had been restored for new WSUS installations and rebuilds, but said it was working on guidance to help customers safely remove the problematic metadata from existing servers — a promise it delivered today.
Rebuilding a production WSUS server is not a straightforward remediation for most organizations. A full rebuild can erase years of configured computer groups, approval rules, and downstream SCCM deployment relationships if not carefully documented and restored. The manual cleanup path — confirmed safe by Microsoft — is the practical route for the majority of affected environments.
Manual SUSDB Cleanup: What Administrators Must Do
Microsoft's KB5121986 guidance requires completing three core operations in sequence before synchronization can resume normally.
First, back up all SUSDB databases — every database in the WSUS hierarchy, including replica servers — before making any changes. SUSDB is the backbone of a WSUS deployment; an unchecked operation against it warrants a recovery point.
Second, run the cleanup query from SQL Management Studio against all SUSDB instances. The query targets detectoid metadata — the applicability-rule entries that have accumulated without pruning — and removes rows that are safe to delete without affecting existing patch approvals or deployment configurations.
Third, update the MaxXMLPerRequest registry value back to its default setting. This value governs how much XML the IIS WsusPool application pool will process per sync request; a prior workaround may have changed it, and the cleanup removes the need for that adjustment.
After completing those three steps, Microsoft directs administrators to reindex SUSDB, run the WSUS Server Cleanup Wizard, and then run IISReset or recycle the WsusPool application pool to clear cached catalog state. The first Windows Update scan after cleanup may take longer than usual; subsequent scans will normalize. Administrators should also know that the client-side DataStore.edb file does not shrink automatically after detectoids are removed — this is expected behavior and does not affect scan performance.
Administrators managing WSUS hierarchies must execute the cleanup against every SUSDB in the environment, including all replica servers. Running it only against the top-level server and expecting downstream resolution will not work.
Four Incidents in Fourteen Months: Why This Keeps Happening
This week's incident is the fourth WSUS synchronization failure in fourteen months. Microsoft addressed similar WSUS outages in May 2025, July 2025, and August 2025 — each requiring intervention at the infrastructure level and each delaying enterprise patch deployment during the period.
What makes the pattern significant is not any single incident but what the accumulation implies. Microsoft deprecated WSUS on September 20, 2024, announcing it would no longer develop new features or accept feature requests for the product. Security updates will continue to arrive through the WSUS channel, and WSUS will keep functioning for the foreseeable future — but no engineering investment in reliability or architectural improvements is planned. Microsoft's recommended migration path is to cloud-native tools: Windows Autopatch and Microsoft Intune for client endpoint management, and Azure Update Manager for server workloads.
What four incidents in fourteen months demonstrates is that deprecated does not mean stable. An infrastructure Microsoft is not actively developing is also an infrastructure Microsoft is not actively hardening against the kinds of metadata accumulation and synchronization scalability problems that July's incident exposed. Organizations that remain on WSUS are accepting a recurring operational risk that will not diminish as long as they stay on a product Microsoft has walked away from strategically.
The compounding factor in July's case is the upstream origin of the failure. Unlike incidents that may involve local database corruption or a faulty update package, this failure originated entirely from Microsoft's own publishing metadata service. There was nothing administrators could have done to prevent the initial outage. The manual cleanup now required of every affected production server is remediation work organizations did not create and cannot avoid.
What Administrators Need to Do Now
Organizations with existing WSUS servers experiencing sync failures should follow KB5121986 through the backup, cleanup query, and MaxXMLPerRequest reset steps in order. Do not skip the backup step. Run the cleanup against every SUSDB in the hierarchy, not just the primary server.
Forcing repeated manual synchronizations before completing the cleanup will not resolve the underlying problem and wastes time that could be spent on remediation. The cleanup must come first.
After sync is restored, treat deployment of the July 2026 cumulative updates as the immediate priority. CVE-2026-56164 patches should be applied to every on-premises SharePoint Server instance, prioritizing internet-facing deployments. CVE-2026-56155 patches should be applied to all AD FS infrastructure. For AD FS, the July 28 federal remediation deadline is still approaching — meaning organizations still have time to meet it if cleanup proceeds promptly.
Organizations considering whether WSUS is the right long-term path should treat this incident as data, not as an anomaly. Microsoft's cloud-native replacements — Intune with Windows Update for Business policies, Windows Autopatch, and Azure Update Manager — do not carry the same server-side metadata accumulation risk because they do not depend on a locally hosted SQL catalog. The migration decision is not urgent, but the pattern of recurrent outages is now documented enough to inform it.
Frequently Asked Questions
What is the WSUS sync fix Microsoft published today, and is it safe to run?
Microsoft's KB5121986 guidance instructs administrators to back up their WSUS SQL database (SUSDB), run a targeted SQL query that removes accumulated detectoid metadata safely, and reset the MaxXMLPerRequest registry value to its default. Microsoft confirmed the metadata targeted by the cleanup can be safely removed from existing installations. The cleanup does not affect existing update approvals, computer groups, or deployment configurations — only obsolete metadata entries that have been causing synchronization timeouts.
Why did the July 18 fix only work for new WSUS servers, not existing ones?
Microsoft's July 18 service-side mitigation addressed the problem at the source: it prevented new or rebuilt WSUS servers from accumulating the problematic metadata going forward by cleaning the server-side publishing pipeline. But existing production servers had already accumulated the problematic metadata in their local SUSDB databases before the service-side fix was deployed. Those databases needed separate, local cleanup — which is what today's KB5121986 guidance provides.
Which vulnerabilities were blocked from deployment by the WSUS outage, and how serious are they?
The most critical are CVE-2026-56164, an actively exploited SharePoint Server flaw that allows unauthenticated remote privilege escalation (independently scored CVSS 9.8 by the NVD despite Microsoft's 5.3 rating), and CVE-2026-56155, an actively exploited AD FS vulnerability that grants local administrator control over the authentication token-signing infrastructure. Both were added to CISA's Known Exploited Vulnerabilities catalog on July 14 with federal remediation deadlines. The SharePoint deadline (July 17) has already passed; the AD FS deadline (July 28) is still upcoming.
Should organizations start migrating away from WSUS after this incident?
Microsoft deprecated WSUS in September 2024, meaning no new engineering investment is planned. This incident is the fourth WSUS synchronization outage in fourteen months (prior incidents in May 2025, July 2025, and August 2025). Each required manual intervention and disrupted patch deployment windows. Microsoft's recommended replacements — Microsoft Intune with Windows Update for Business for client devices, and Azure Update Manager for server workloads — do not rely on a locally hosted SQL metadata store and are not susceptible to the same class of failure. Migration carries upfront cost and configuration work, but the recurring pattern of WSUS outages now constitutes documented operational risk that any migration cost estimate should be measured against.
Related Articles
