SQL Server 2022 CU27 Known Issues: What to Check Before You Patch

Microsoft released SQL Server 2022 CU27 and SQL Server 2025 CU9 on 15 September 2026. Both builds fix real problems, and both ship with the same three documented known issues. If you run a SQL Server estate, the SQL Server 2022 CU27 known issues are the first thing to review, because this is a release most estates want: it fixes a transaction rollback corruption bug and a long list of security defects. That combination makes patching a risk decision rather than a routine task. You want the fixes. You also need to know whether SESSION_CONTEXT, MSDASQL linked servers, or your monitoring tooling breaks the day you apply it.

What shipped on 15 September

SQL Server 2022 CU27 takes the engine to build 16.0.4295.3 with 41 fixes on top of CU26. SQL Server 2025 CU9 lands on 17.0.5005.3 with 44 fixes, under KB5122048. DBA Services have published detailed walkthroughs of CU27 and CU9, and in both cases security hardening dominates the fix lists. CU27 closes query optimiser memory-disclosure paths, memory corruption in Extended Events, and crashes triggered by crafted XML during bulk import. CU9 fixes an authenticated TDS buffer overflow that could terminate the SQL Server process outright. Downloads no longer require registration; both updates are on the Microsoft Download Centre.

First, confirm what you are actually running:

SELECT
    SERVERPROPERTY('ProductVersion') AS Build,
    SERVERPROPERTY('ProductLevel') AS Level,
    SERVERPROPERTY('ProductUpdateLevel') AS CULevel;

Anything below 16.0.4295.3 on SQL Server 2022, or 17.0.5005.3 on SQL Server 2025, means the update applies to you.

The corruption fix that makes CU27 hard to skip

Fix 2796714 is the one to know about. Rolling back a user transaction could corrupt the database, with DBCC CHECKDB reporting Page Free Space (PFS) page errors. It only bites where Accelerated Database Recovery (ADR) is disabled, and ADR is off by default in SQL Server 2022. Unless someone turned it on deliberately, your databases qualify.

Check:

SELECT name
FROM sys.databases
WHERE is_accelerated_database_recovery_on = 0
  AND name NOT IN ('master', 'tempdb', 'model', 'msdb');

Every database that query returns is exposed to the rollback corruption bug CU27 fixes. That is the strongest single argument for patching this cycle. Whether you can patch safely is what the rest of this post works through.

The three known issues, in both builds

Microsoft documented the same three known issues against CU27 and CU9. None are exotic, which is exactly the problem: each one touches things real estates rely on.

SESSION_CONTEXT under parallel plans

Queries using SESSION_CONTEXT can return wrong results or throw access violation dumps when they execute in parallel plans, particularly when the session is reused from a connection pool. This is a correctness bug, not just a crash risk. Row-level security implementations routinely pass tenant or user context through SESSION_CONTEXT, so wrong results here can mean rows returned to the wrong tenant. The documented workaround is forcing serial execution with OPTION (MAXDOP 1) on affected queries, which is a plaster, not a fix.

MSDASQL linked servers fail with error 7416

Linked server queries that use the MSDASQL OLE DB provider with a provider string fail after patching with Msg 7416: "Access to the remote server is denied because no login-mapping exists." Stricter connection validation rejects configurations that worked fine on earlier builds. If any reporting, ETL or application integration pulls data through an ODBC linked server, that path breaks the day the CU goes on.

sys.dm_exec_requests during recovery can kill the instance

Querying sys.dm_exec_requests while a database is recovering, during a RESTORE, startup recovery, or before an availability group replica comes online, can trigger an access violation and dump the SQL Server process. Monitoring tools poll that DMV continuously, often every few seconds. A poll that happens to land inside a recovery window can terminate the instance mid-restore. This is the known issue most likely to catch people out, because it is one of the most commonly polled DMVs in third-party monitoring.

Four checks to run before you patch

These cover all three known issues plus the corruption exposure. They are read-only and safe to run in production:

-- Databases with ADR off: exposed to the rollback corruption bug CU27 fixes
SELECT name
FROM sys.databases
WHERE is_accelerated_database_recovery_on = 0
  AND name NOT IN ('master', 'tempdb', 'model', 'msdb');

-- Code that uses SESSION_CONTEXT: test against parallel plans on the new build
SELECT OBJECT_SCHEMA_NAME(object_id) AS SchemaName,
       OBJECT_NAME(object_id) AS ObjectName
FROM sys.sql_modules
WHERE definition LIKE '%SESSION_CONTEXT%';

-- MSDASQL linked servers with a provider string: error 7416 risk
SELECT name, provider, provstr
FROM sys.servers
WHERE is_linked = 1
  AND provider = 'MSDASQL'
  AND provstr IS NOT NULL
  AND provstr NOT IN ('');

-- Agent job steps that poll sys.dm_exec_requests: recovery-window crash risk
SELECT j.name AS JobName, s.step_name
FROM msdb.dbo.sysjobs AS j
JOIN msdb.dbo.sysjobsteps AS s
  ON s.job_id = j.job_id
WHERE s.command LIKE '%sys.dm_exec_requests%';

The Agent job query only covers jobs. Check your monitoring platform's collection queries too; most tools let you export their definitions.

CU9 also fixes a monitoring bug worth knowing about

SQL Server 2025 CU9 includes fix 5504681: the Buffer cache hit ratio performance counter has been stuck at zero in Performance Monitor. Any alerting or capacity planning built on that counter has been producing junk. If a dashboard has shown a flat zero for months, the server was probably fine and the counter was not. After patching, the counter reports real values again, so review any thresholds that reference it. An alert that has been quietly disabled by a broken counter waking up again is its own small incident.

Two timing notes for the patch window

If you are migrating from SQL Server 2019 to 2022, fix 5558709 addresses an upgrade hang during the replicated_model database upgrade phase on instances hosting contained availability groups. Have CU27 in hand before you start the upgrade, not after. And if part of the estate is still on SQL Server 2016, extended support ended on 14 July 2026; the upgrade decisions are laid out in our SQL Server 2016 end of support guide.

The security volume is the other half of the risk decision. Deferring a release that closes memory-disclosure paths and a process-termination bug is a risk you take knowingly. Make that call consciously rather than by calendar habit.

The verdict

Patch, but patch deliberately. The sequence that works:

• Inventory build levels across the estate with SERVERPROPERTY.
• Run the four checks above and record what comes back. Every hit is a specific thing to test.
• Stand up the new build in non-production and exercise your SESSION_CONTEXT paths and MSDASQL linked servers against it.
• Suppress sys.dm_exec_requests polling for the patch window and the first recovery afterwards.
• Book the window. For most estates the corruption fix and the security hardening outweigh the known issues, provided you know in advance whether each one applies to you.

If you would rather not run that inventory by hand across dozens of servers, our SQL Server health check covers build levels and configuration drift as standard. And if patching keeps slipping because nobody owns the estate calendar, our piece on going from reactive to proactive is the place to start.