Introduction
Microsoft's November 10, 2026 SQL Server updates close a SQL injection path in replication that lets a user who is only supposed to synchronize a database subscription get SQL Server to run database commands well outside what replication is meant to do. For organizations that use replication to move data between sites, branch offices, or downstream databases, an account scoped to synchronization could become a route to elevated database privileges, which is why the issue scores 8.8 under CVSS v3.1 despite requiring authentication.
The initial CVE record lists the vendor as unknown, but the MSRC advisory confirms this is Microsoft SQL Server, with fixes for SQL Server 2017, 2019, 2022 and 2025 across both CU and GDR servicing branches.
Technical information
Root cause
Microsoft classifies the weakness as CWE 89: Improper Neutralization of Special Elements used in an SQL Command. At the weakness level, SQL injection happens when untrusted input becomes part of executable SQL syntax rather than staying data. CISA and the FBI describe the underlying problem as mixing database queries with user-supplied data.
The MSRC FAQ narrows this down considerably. The flaw is reachable by an authenticated user who has permission to synchronize a database subscription. That user can send a specially crafted request that causes SQL Server to run database commands "beyond the intended replication functionality." So the bug sits in how SQL Server replication builds and executes SQL from inputs that a subscriber can influence.
What the release notes reveal
SQL Server is closed source, so there is no public commit or diff. The November release notes describe the change only in general terms, but they are informative. The SQL Server 2017 GDR notes (KB5132749, bug 5731767) and the SQL Server 2025 GDR notes (KB5132748, bug 5731763) both contain this entry:
Fixes an elevation of privilege vulnerability in SQL Server merge replication. Replication system procedures now reject batch separators in subscriber validation expressions.
Merge replication lets subscribers supply filter or validation expressions that are later inserted into dynamically built Transact SQL. If such an expression contains a batch separator, it can terminate the intended statement and begin a new one, and that new statement runs with the privileges of the replication procedure. The fix rejects batch separators before the expression is concatenated into SQL, instead of trusting it as plain predicate text.
The KB summaries do not name CVE-2026-118120, though. Their CVE lists stop at nearby IDs such as CVE-2026-118116. Tying this specific bug entry to this CVE is our inference, based on how closely it matches the MSRC FAQ description. The authoritative mapping of the CVE to packages is the MSRC advisory table.
The same packages also carry a number of other replication hardening changes, such as better handling of object, column and conflict table names in merge replication stored procedures, and stricter role checks for replication subscription checks. That pattern suggests Microsoft reviewed replication's dynamic SQL broadly rather than patching a single call site.
Attack flow
Based on Microsoft's description, the documented sequence is:
- The attacker authenticates to an affected SQL Server instance over the network.
- The attacker holds permission to synchronize a database subscription.
- The attacker sends a specially crafted request. Per the release notes, the likely vector is a subscriber-supplied validation expression carrying a batch separator.
- Replication procedures concatenate that input into dynamic Transact SQL, and the injected statement executes with the replication procedure's privileges, giving the attacker database commands beyond the intended replication functionality. No other user needs to take any action.
This is a database privilege escalation scenario. It is not a documented unauthenticated attack, and the advisory does not establish operating system administrator access or remote code execution at the operating system level.
Severity scoring
Microsoft supplies the following vector, which NVD reproduces:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- AV:N: reachable over the network
- AC:L: low attack complexity
- PR:L: existing low-level privileges required
- UI:N: no user interaction
- S:U: scope unchanged
- C:H / I:H / A:H: high potential impact to confidentiality, integrity and availability
PR:L does not mean any authenticated login qualifies. Microsoft's FAQ adds the subscription synchronization permission as a specific prerequisite. Microsoft also publishes a temporal score of 7.7 (E:U/RL:O/RC:C): exploit maturity Unproven, an Official Fix available, and report confidence Confirmed. Microsoft's own severity rating is Important. That rating and the CVSS score come from different rating systems and do not conflict. NVD displays the Microsoft CNA score and had not provided its own assessment at the time of review.
What is not public
The reviewed records do not name the exact vulnerable procedure, parameter, request format, payload, or the final database role obtained. That supports prerequisite and outcome analysis, but not a reproducible exploit chain.
Patch information
Microsoft fixed CVE-2026-118120 in its November 10, 2026 SQL Server security updates, and the advisory sets the CVSS Remediation Level to Official Fix.
Fixed packages and builds (from MSRC)
- SQL Server 2025 CU10 + GDR: KB5129299, fixed build 17.0.5045.3, applies to 17.0.4006.2 through 17.0.5035.5
- SQL Server 2025 RTM + GDR: KB5132748, fixed build 17.0.1155.3, applies to 17.0.1000.7 through 17.0.1145.4
- SQL Server 2022 CU27 + GDR2: KB5129300, fixed build 16.0.4315.2, applies to 16.0.4003.1 through 16.0.4305.5
- SQL Server 2022 RTM + GDR: KB5132747, fixed build 16.0.1220.3, applies to 16.0.1000.6 through 16.0.1210.3
- SQL Server 2019 CU32 + GDR: KB5132745, fixed build 15.0.4510.2, applies to 15.0.4003.23 through 15.0.4500.2
- SQL Server 2019 RTM + GDR: KB5132751, fixed build 15.0.2210.4, applies to 15.0.2000.5 through 15.0.2200.2
- SQL Server 2017 CU31 + GDR: KB5132746, fixed build 14.0.3570.2, applies to 14.0.3006.16 through 14.0.3560.2
- SQL Server 2017 RTM + GDR: KB5132749, fixed build 14.0.2150.2, applies to 14.0.1000.169 through 14.0.2140.2
Picking the right package
SQL Server has two servicing tracks:
- GDR: security and other critical fixes only.
- CU: all accumulated fixes for the release, including those security fixes.
Find the current build (for example with SELECT SERVERPROPERTY('ProductVersion')), locate the range that contains it, and install that package. Avoid switching tracks by accident. Packages are cumulative within their track. MSRC lists the earlier servicing release each one rolls up (for example, KB5129300 includes everything through KB5126934, the October CU27 GDR). Updates are available through Windows Update or Microsoft Update, the Microsoft Update Catalog, and the Download Center. For SQL Server on Linux, use the configured CU repository.
Deployment note: recovery query regression
KB5129300 (SQL Server 2022 CU27) has a known issue: querying sys.dm_exec_requests while a database is still recovering can cause an access violation and a memory dump. This can occur during a RESTORE, during startup recovery, or while an availability group replica is coming online. Our briefing notes that the SQL Server 2025 CU10 update (KB5129299) documents the same issue. Until Microsoft ships a fix, the published options are:
- Enable trace flag 4696 to opt out of the change that causes it. The trade-off is that monitoring queries on secondary replicas may return error 976 or 978 again, as they did before the update.
- Avoid querying that DMV against recovering databases.
- Uninstall the update.
The first two are mitigations for the regression, not for the CVE. Uninstalling the update also removes the security fix, so it cannot be treated as remediation. If monitoring jobs poll sys.dm_exec_requests, plan for this before deployment.
Detection methods
Microsoft has not published exploitation signatures for this CVE: no IoCs, YARA, Sigma, Snort or Suricata rules, and no log patterns. In practice, detection here means exposure detection: finding instances still on a vulnerable build and identifying where the vulnerable feature is in use. A version check tells you a server is exposed, not that it was compromised.
1. Build number checks
Read the build on every instance without changing anything, using the query suggested by a public SQL Server tracker:
SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion, SERVERPROPERTY('ProductLevel') AS ProductLevel, SERVERPROPERTY('Edition') AS Edition;
The same source warns that availability group replicas and cluster nodes can sit on different builds during maintenance windows, so query every node, not just the primary. Compare ProductVersion against the MSRC ranges in the Patch information section. Because CU and GDR tracks have different fixed builds, a number that is patched on one track can still be vulnerable on the other.
NVD's affected product data, taken from Microsoft's CNA record, expresses the same picture as "affected below fixed build" ranges, with a few lower bounds that differ slightly from MSRC (for example 17.0.4006.0 vs 17.0.4006.2 for 2025 CU10, and 17.0.1050.2 vs 17.0.1000.7 for 2025 GDR). Either way, the fixed build is the number to test against. Microsoft also notes that a version missing from its table does not by itself mean that version is unsupported, so investigate outliers instead of skipping them.
2. Do not rely on Windows hotfix inventory
Senserva points out that these are SQL Server packages, not Windows components, so the PowerShell cmdlet that lists Windows hotfixes will not show them. Dashboards built on Windows hotfix lists can report SQL Server as unpatched when it is patched, or miss the gap entirely. Senserva suggests Intune or Defender inventory to confirm whether KB5129299, KB5129300, KB5132745, KB5132746, KB5132747, KB5132748, KB5132749 or KB5132751 are present on affected hosts, but the SQL build number should be the final word. Commercial scanners such as Rapid7 also list this CVE, so authenticated scanning is another option for large estates, although their public entry does not describe how the check works.
3. Prioritize replication
Because exploitation requires permission to synchronize a database subscription, instances that participate in replication, and the logins allowed to synchronize subscriptions, are where exposure matters most. Inventory them, confirm the synchronization accounts are expected and tightly scoped, and patch those servers first. Any hunting around replication activity (unusual principals starting synchronization, replication sessions running commands outside their normal pattern) is your own baselining work. No public source offers a vetted rule.
4. Verify after patching
Run the same SERVERPROPERTY query again and confirm ProductVersion is equal to or higher than the fixed build for the instance's servicing branch, on every replica and cluster node.
Affected systems and versions
Per the MSRC advisory, the following Microsoft SQL Server builds are affected (inclusive ranges):
- SQL Server 2025 CU10 branch: 17.0.4006.2 through 17.0.5035.5 (fixed in 17.0.5045.3)
- SQL Server 2025 RTM/GDR branch: 17.0.1000.7 through 17.0.1145.4 (fixed in 17.0.1155.3)
- SQL Server 2022 CU27 branch: 16.0.4003.1 through 16.0.4305.5 (fixed in 16.0.4315.2)
- SQL Server 2022 RTM/GDR branch: 16.0.1000.6 through 16.0.1210.3 (fixed in 16.0.1220.3)
- SQL Server 2019 CU32 branch: 15.0.4003.23 through 15.0.4500.2 (fixed in 15.0.4510.2)
- SQL Server 2019 RTM/GDR branch: 15.0.2000.5 through 15.0.2200.2 (fixed in 15.0.2210.4)
- SQL Server 2017 CU31 branch: 14.0.3006.16 through 14.0.3560.2 (fixed in 14.0.3570.2)
- SQL Server 2017 RTM/GDR branch: 14.0.1000.169 through 14.0.2140.2 (fixed in 14.0.2150.2)
NVD records some lower bounds differently (for example 14.0.0, 15.0.0 and 16.0.0 for the GDR branches, 17.0.4006.0 for 2025 CU10, and 17.0.1050.2 for 2025 GDR), but the fixed builds match.
Vulnerable configuration: exploitation requires an authenticated principal with permission to synchronize a database subscription, so instances using replication (the release notes point specifically to merge replication) with such logins present the relevant exposure.
Vendor security history
The most cited historical SQL Server incident is SQL Slammer, which targeted SQL Server 2000 and MSDE 2000. Microsoft says it first patched the underlying vulnerability in July 2002, followed by cumulative patches through October 2002, and reported business disruption but no customer data corruption. NETSCOUT's retrospective adds that early patches caused production problems and some were issued and withdrawn, and that the worm later compromised roughly 75,000 vulnerable servers within minutes, peaking at 55 million scans per second.
Slammer was a buffer overflow, not SQL injection, and nothing suggests CVE-2026-118120 will follow that path. The lesson that carries over is operational. A fix being available is not the same as a fix being deployed, and the documented recovery query regression in the November CU packages is exactly the kind of friction that delays rollouts. For this CVE, Microsoft published prerequisites, an exploitability assessment and a full build matrix, and credited Krishna Badiger with Trellix Database Security for the report.
References
- NVD: CVE-2026-118120
- CVE Record: CVE-2026-118120
- MSRC Security Update Guide: CVE-2026-118120
- MSRC CVRF data, November 2026
- KB5129300: Security update for SQL Server 2022 CU27
- KB5132749: Security update for SQL Server 2017 GDR
- KB5132748: Security update for SQL Server 2025 GDR
- KB5129299: Security update for SQL Server 2025 CU10
- KB5132747: Security update for SQL Server 2022 GDR
- KB5132745: Security update for SQL Server 2019 CU32
- KB5132751: Security update for SQL Server 2019 GDR
- KB5132746: Security update for SQL Server 2017 CU31
- Microsoft Learn: Updates to the Microsoft Update detection logic
- Microsoft Learn: Securing SQL Server
- Microsoft Learn: What is SQL Server?
- SQL Server vulnerabilities tracker
- Senserva: KB5129299
- Senserva: CVE-2026-118120
- Rapid7 Vulnerability Database: CVE-2026-118120
- VulDB: CVE-2026-118120
- MITRE CWE 89: Improper Neutralization of Special Elements used in an SQL Command
- OWASP SQL Injection Prevention Cheat Sheet
- CISA and FBI Secure by Design Alert: Eliminating SQL Injection Vulnerabilities in Software
- CISA Known Exploited Vulnerabilities Catalog
- DB Engines Ranking
- DB Engines Ranking Method
- NETSCOUT: Remembering SQL Slammer
- Microsoft Statement on the Slammer Worm Attack
