The company calls the problem confirmed and has promised an out-of-band fix. Until it ships, administrators who use linked servers to reach Oracle, PostgreSQL or other external databases should watch connection counts on both sides of the link.
What Microsoft confirmed
Windows release health describes the problem this way: after Windows updates released October 13, 2026, and later are installed on server devices, connections created by SQL Server linked server queries might remain open after the queries complete. As additional queries are performed, connections to external databases can accumulate instead of closing as expected. This can slow or degrade server performance after prolonged run time.
The issue is limited to one path. Microsoft says this issue affects SQL Server linked server queries that use OLE DB providers to connect to external databases. Oracle and PostgreSQL connections are among those known to be affected. The words "among those" matter. Microsoft has not said that Oracle and PostgreSQL are the only affected targets, so admins with other OLE DB providers should not assume they are safe.
BleepingComputer was first with the wider story. It reported that Microsoft has tied Windows updates released since the October 2026 Patch Tuesday to SQL Server performance and stability problems. The symptom Microsoft tells admins to look for is an increasing number of open connections to external databases, even when the associated SQL Server linked server queries are no longer running.
In short: this is a slow connection leak in linked-server traffic that uses OLE DB. It does not mean SQL Server is broken on every system.
Affected Windows versions and originating updates
BleepingComputer summarized the scope as Windows 10, Windows 11 and Windows Server 2012 and later. Microsoft's release-health pages are more specific. On the client side, they list Windows 11, version 26H1; Windows 11, version 25H2; Windows 11, version 24H2; Windows 11, version 23H2; Windows 10, version 1809; Windows 10 Enterprise LTSC 2019. On the server side, they list Windows Server 2025; Windows Server 2022; Windows Server, version 1809; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012.
The originating updates from Microsoft's release-health entries are below:
| Platform | Originating KB (Oct. 13, 2026) | Build, where listed |
|---|---|---|
| Windows 11, version 26H1 | KB5127646 | 28000.3231 |
| Windows 11, versions 25H2 / 24H2 | KB5127648 | 26200.9711 / 26100.9711 |
| Windows 11, version 23H2 | KB5126653 | 22631.7652 |
| Windows 10 1809 / LTSC 2019 / Server 2019 (version 1809) | KB5126651 | 17763.9376 |
| Windows Server 2025 | KB5126646 | — |
| Windows Server 2022 | KB5126655 | 20348.5761 |
| Windows Server 2016 | KB5126868 | — |
| Windows Server 2012 R2 | KB5126836 | — |
| Windows Server 2012 | KB5126835 | — |
Release-health pages give the builds for OS Build 28000.3231 KB5127646 on 26H1, OS Build 22631.7652 KB5126653 on 23H2, OS Build 20348.5761 KB5126655 on Server 2022, and OS Build 17763.9376 KB5126651 on version 1809. Microsoft's Windows 11 release calendar gives the 24H2 and 25H2 builds for KB5127648.
Windows 11 version 26H2 is not on the list. The Register noted that the technical glitch affects every version of Windows except Windows 11 26H2, stretching back to Windows 10 1809 and LTSC 2019, and Windows Server from 2025 back to 2012. Our check of Microsoft's own Windows 11 release calendar found something odd: it lists KB5127648 as the October 13 update for 26H2 as well, at build 26300.9711. That is the same KB number that is flagged for 24H2 and 25H2. Microsoft hasn't explained why 26H2 is excluded. Treat its absence as "not currently listed," not as proof that 26H2 is immune.
November Patch Tuesday does not fix it
Microsoft's wording, "October 13, 2026, and later," means the November 10 cumulative updates still carry the bug. A third-party knowledge-base tracker for the November 26H1 update, KB5132059, still lists the linked-server issue as Confirmed. Microsoft last updated it 2026-11-11 15:12 PT. Every affected platform's release-health entry still shows an empty "Resolved KB" field. Installing this month's patches will not make the problem go away.
Temporary measures and their risks
Microsoft offers two stopgaps: If idle connections can be identified, it is possible to manually close them in order to temporarily relieve server load. It is also possible to temporarily restore system stability by restarting the SQL service.
Both carry risk. As BleepingComputer reported, either step can also kill active queries and may not fully address the issue, as it will resurface again after some time. A restart resets the leak, and then it starts building again.
Microsoft also has a third option that isn't public. Organizations can reach out to Microsoft Support for Business for a mitigation that can address the issue until a fix is available. Microsoft has not published what that mitigation is, so there's nothing to reverse-engineer.
The permanent fix is on the way: "We will address this issue with an out-of-band update that will be released in the next few days. We will update this documentation once the update is released." That was Microsoft's plan as of November 11. No fixed KB number has been published yet.
A practical playbook for admins
The steps below are general operational practice, not a procedure Microsoft has published.
- Check whether you're exposed. Find which SQL Server instances use linked servers. The
sys.serverscatalog view lists them on each instance. Then check which of those use OLE DB providers to reach non-SQL Server databases such as Oracle or PostgreSQL. - Confirm the patch level. Compare each host's Update history or build number with the table above. Any build from October 13 onward on a listed platform should be considered in scope.
- Watch the remote end. Leaked connections are usually easiest to see on the target database, for example in PostgreSQL's
pg_stat_activityor Oracle'sV$SESSION. A steady climb in idle sessions from your SQL Server host's account is the warning sign. - Plan restarts carefully. If you need to restart SQL Server for relief, do it in a maintenance window, after draining long-running jobs and distributed transactions.
- Call support if it's critical. If the workload can't tolerate scheduled restarts, open a case with Microsoft Support for Business and ask for the mitigation.
- Install the out-of-band update once it ships. Test it first on a host that actually uses linked servers. A test box without linked servers won't show whether the leak is fixed.
What about rolling back the October update? Each later cumulative update includes the same change, and it also includes security fixes, including the November rollup's large batch of CVE fixes. Uninstalling to fix a slow leak would trade a performance problem for a security problem. For most organizations, monitoring and scheduled recycling until the fix arrives is the better choice.
Why linked servers are especially exposed
Linked servers let SQL Server send distributed queries to outside data sources through an OLE DB provider. That provider must be installed on the same host as the SQL Server instance. Organizations commonly use them for nightly ETL jobs that pull from Oracle, reporting views that join PostgreSQL tables, and SQL Agent jobs that poll a remote system every few minutes.
That repeated traffic is what turns a small leak into a problem. The Register put it simply: SQL Server normally can open a connection to grab data, and close it again when the query is complete. A job that runs every five minutes would add 288 connections a day if none of them closed. Eventually the remote database runs into session limits, or the SQL Server host runs short of resources.
Microsoft has not given a threshold, a time to failure or a size for the performance hit. How long a server lasts before it slows down depends on how often linked-server queries run.
A rough patch for Windows-hosted SQL Server
This isn't the only recent servicing problem affecting SQL Server on Windows. In September, Microsoft shared a temporary workaround for SQL Server crashes on some Windows Server 2025 machines that have the Lock Pages in Memory policy enabled. Those crashes were linked to memory-management changes. Separately, Microsoft confirmed that November 2026 security updates are failing to install on Windows 11 machines that already have the October preview update, with error codes 0x80070306, 0x800f0989 or 0x800f0993. The Register also noted that the October 2026 Windows Server update left some Exchange Servers wobbling until either a Registry edit was made or a fix was applied as part of the November update.
These are separate bugs. Taken together, they show that application servers should not get Windows cumulative updates as soon as they're released. Use staged rings and add a soak test that runs real cross-database workloads, rather than only checking that the server boots and the service starts.
Bottom line: if your SQL Server instances use OLE DB linked servers to reach Oracle, PostgreSQL or other external databases, watch connection counts on both ends, schedule any restarts carefully, and install Microsoft's out-of-band fix once it ships. If they don't use linked servers, Microsoft's description doesn't indicate this specific bug affects you.