Microsoft published CVE-2026-42990 on July 14, 2026, identifying an elevation-of-privilege vulnerability in the Microsoft ODBC Driver for SQL Server. The immediate job for administrators is to inventory every deployed copy of the driver—not merely patch SQL Server hosts—because ODBC is a client component frequently bundled with applications, management systems, integration services, and automation workers.
The vulnerability is documented in Microsoft’s Security Update Guide as CVE-2026-42990, with a publication timestamp of July 14 at 7:00 a.m. Pacific time. Microsoft had not supplied a modification date in the material available at publication, and the advisory details provided do not establish a known-exploitation status, affected version list, CVSS score, attack prerequisites, or fixed driver build.
That missing detail matters. An elevation-of-privilege classification tells defenders the security boundary being crossed, but it does not by itself show whether exploitation begins with a local user, a compromised application, a malicious SQL endpoint, or specially constructed data processed by the driver. Administrators should avoid filling those gaps with assumptions while still treating the driver as a patching target.
Microsoft ODBC Driver for SQL Server is a native data-access component used by software connecting to SQL Server, Azure SQL Database, Azure SQL Managed Instance, Microsoft Fabric, and related services. Microsoft describes the driver as a single dynamic-link library providing runtime support for applications that use native ODBC APIs, although languages and platforms above that layer can also rely on it.
That architecture means the vulnerable code can reside on a Windows application server, administrator workstation, reporting node, scheduled-task host, or developer machine. It does not have to be installed on the database server that ultimately receives the connection.
ODBC Driver 17 and ODBC Driver 18 can also exist side by side. Updating one branch therefore does not prove that every application has moved to a protected build; an older program may continue loading Driver 17 while a newer service uses Driver 18 on the same computer.
This is the distinction IT teams need to preserve during remediation: a fully patched SQL Server instance does not necessarily protect a separate machine running a vulnerable client driver. Conversely, updating the standalone driver should not be treated as a substitute for installing SQL Server’s own cumulative updates and General Distribution Releases.
Microsoft’s documentation listed ODBC Driver 18 version 18.6.2.1, released March 31, 2026, as the latest generally available 18.x release before the July advisory. It separately listed Driver 17 version 17.11.1.1, released April 30, 2026, as the current 17.x build at that point. Those dates provide useful inventory baselines, but administrators should not infer that either version fixes CVE-2026-42990 unless Microsoft explicitly maps the CVE to those builds or publishes newer packages.
The x64 and ARM64 ODBC Driver 18 installers can install both 64-bit and 32-bit drivers, which creates another potential inventory trap. A 64-bit administration tool may show the expected configuration while a 32-bit legacy application continues using a different registered driver or data source.
A practical response should include these checks:
Enterprises should also look beyond conventional servers. ODBC drivers can appear in golden images, virtual desktop pools, developer workstations, self-hosted CI/CD runners, data-migration appliances, and utility machines used for
In this case, Microsoft’s publication confirms that the vendor recognizes the vulnerability. It does not automatically reveal how much technical information is available to attackers, whether exploit code has been published, or whether Microsoft has observed attacks.
Administrators should therefore keep three separate questions in their tracking ticket: whether the vulnerability is vendor-confirmed, whether exploitation has been demonstrated publicly, and whether exploitation has been detected in the wild. Treating those as interchangeable can produce either unnecessary alarm or dangerous complacency.
The elevation-of-privilege label also should not be translated into “remote administrator access” without supporting details. Privilege escalation typically requires an attacker to possess some initial execution or interaction path, but the exact starting privileges and affected security boundary depend on the vulnerable code path. Microsoft’s full attack-vector and prerequisite fields should govern exposure ranking when available.
Until then, systems deserve higher operational priority when they combine the driver with untrusted users, exposed application tiers, shared Windows hosts, high-privilege service identities, or connections influenced by customer-controlled input. A tightly controlled workstation using the driver only for an internal database is not necessarily equivalent to a multi-tenant integration server, even if both carry the same package version.
Where Microsoft supplies fixed packages for both maintained branches, the lowest-risk response is normally to update applications within the driver family they already use. A major-version migration should remain a separately tested project unless Microsoft states that upgrading branches is required for protection.
Change owners should test authentication through Microsoft Entra ID, Windows integrated authentication, certificates, encrypted connections, connection pooling, failover behavior, DSNs, and application-specific connection strings. Services that retain the driver in memory may need to be restarted even when the installer does not force a full Windows reboot.
Endpoint and server-management teams should watch for Microsoft publishing revised download packages, release notes, Knowledge Base articles, or an updated advisory record. The fixed version numbers and affected-product table are the decisive details still needed to turn CVE-2026-42990 from an inventory exercise into a verifiable remediation campaign.
For now, the concrete consequence is straightforward: do not limit the search to SQL Server machines. Find every endpoint that loads Microsoft ODBC Driver 17 or 18, preserve the exact version data, and be ready to deploy Microsoft’s mapped security builds as soon as the CVE record identifies them.
The vulnerability is documented in Microsoft’s Security Update Guide as CVE-2026-42990, with a publication timestamp of July 14 at 7:00 a.m. Pacific time. Microsoft had not supplied a modification date in the material available at publication, and the advisory details provided do not establish a known-exploitation status, affected version list, CVSS score, attack prerequisites, or fixed driver build.
That missing detail matters. An elevation-of-privilege classification tells defenders the security boundary being crossed, but it does not by itself show whether exploitation begins with a local user, a compromised application, a malicious SQL endpoint, or specially constructed data processed by the driver. Administrators should avoid filling those gaps with assumptions while still treating the driver as a patching target.
The Vulnerable Component May Be Far from SQL Server
Microsoft ODBC Driver for SQL Server is a native data-access component used by software connecting to SQL Server, Azure SQL Database, Azure SQL Managed Instance, Microsoft Fabric, and related services. Microsoft describes the driver as a single dynamic-link library providing runtime support for applications that use native ODBC APIs, although languages and platforms above that layer can also rely on it.That architecture means the vulnerable code can reside on a Windows application server, administrator workstation, reporting node, scheduled-task host, or developer machine. It does not have to be installed on the database server that ultimately receives the connection.
ODBC Driver 17 and ODBC Driver 18 can also exist side by side. Updating one branch therefore does not prove that every application has moved to a protected build; an older program may continue loading Driver 17 while a newer service uses Driver 18 on the same computer.
This is the distinction IT teams need to preserve during remediation: a fully patched SQL Server instance does not necessarily protect a separate machine running a vulnerable client driver. Conversely, updating the standalone driver should not be treated as a substitute for installing SQL Server’s own cumulative updates and General Distribution Releases.
Microsoft’s documentation listed ODBC Driver 18 version 18.6.2.1, released March 31, 2026, as the latest generally available 18.x release before the July advisory. It separately listed Driver 17 version 17.11.1.1, released April 30, 2026, as the current 17.x build at that point. Those dates provide useful inventory baselines, but administrators should not infer that either version fixes CVE-2026-42990 unless Microsoft explicitly maps the CVE to those builds or publishes newer packages.
Inventory Comes Before a Blind Upgrade
Organizations should begin by locating the installed Microsoft ODBC drivers and identifying which applications consume them. On Windows, administrators can review installed applications, deployment-platform inventory, MSI package data, ODBC Data Source Administrator entries, and the registered driver information visible through PowerShell or the registry.The x64 and ARM64 ODBC Driver 18 installers can install both 64-bit and 32-bit drivers, which creates another potential inventory trap. A 64-bit administration tool may show the expected configuration while a 32-bit legacy application continues using a different registered driver or data source.
A practical response should include these checks:
- Administrators should identify every installed Microsoft ODBC Driver for SQL Server major version and record its complete product and file version.
- Application owners should map services, scheduled tasks, websites, reporting tools, and integration jobs to the driver name in their connection strings or DSNs.
- Security teams should search software inventories for both
msodbcsql17andmsodbcsql18, including copies deployed inside application images or build environments. - Linux and macOS systems should also be reviewed where Microsoft’s cross-platform ODBC packages are used, unless the final advisory explicitly limits the affected scope to Windows.
- Patch validation should confirm which driver DLL an application actually loads rather than relying only on the presence of a newer installer entry.
Enterprises should also look beyond conventional servers. ODBC drivers can appear in golden images, virtual desktop pools, developer workstations, self-hosted CI/CD runners, data-migration appliances, and utility machines used for
sqlcmd or bcp. Systems that do not host databases may still have broad database access and privileged service accounts, making a client-side privilege-escalation flaw operationally significant.The Generic Confidence Text Is Not an Exploit Report
The metric description accompanying the submitted advisory explains how confidence can range from an uncorroborated vulnerability report to vendor confirmation with established technical details. That is generic scoring guidance, not evidence that CVE-2026-42990 is being exploited or that a public proof of concept exists.In this case, Microsoft’s publication confirms that the vendor recognizes the vulnerability. It does not automatically reveal how much technical information is available to attackers, whether exploit code has been published, or whether Microsoft has observed attacks.
Administrators should therefore keep three separate questions in their tracking ticket: whether the vulnerability is vendor-confirmed, whether exploitation has been demonstrated publicly, and whether exploitation has been detected in the wild. Treating those as interchangeable can produce either unnecessary alarm or dangerous complacency.
The elevation-of-privilege label also should not be translated into “remote administrator access” without supporting details. Privilege escalation typically requires an attacker to possess some initial execution or interaction path, but the exact starting privileges and affected security boundary depend on the vulnerable code path. Microsoft’s full attack-vector and prerequisite fields should govern exposure ranking when available.
Until then, systems deserve higher operational priority when they combine the driver with untrusted users, exposed application tiers, shared Windows hosts, high-privilege service identities, or connections influenced by customer-controlled input. A tightly controlled workstation using the driver only for an internal database is not necessarily equivalent to a multi-tenant integration server, even if both carry the same package version.
Patch the Driver Without Breaking the Data Path
ODBC upgrades require testing because applications can depend on connection behavior as well as binary compatibility. Driver 18 introduced encryption-related defaults and other behavior changes compared with older branches, so replacing Driver 17 with Driver 18 is not the same exercise as applying a supported security build within the existing major version.Where Microsoft supplies fixed packages for both maintained branches, the lowest-risk response is normally to update applications within the driver family they already use. A major-version migration should remain a separately tested project unless Microsoft states that upgrading branches is required for protection.
Change owners should test authentication through Microsoft Entra ID, Windows integrated authentication, certificates, encrypted connections, connection pooling, failover behavior, DSNs, and application-specific connection strings. Services that retain the driver in memory may need to be restarted even when the installer does not force a full Windows reboot.
Endpoint and server-management teams should watch for Microsoft publishing revised download packages, release notes, Knowledge Base articles, or an updated advisory record. The fixed version numbers and affected-product table are the decisive details still needed to turn CVE-2026-42990 from an inventory exercise into a verifiable remediation campaign.
For now, the concrete consequence is straightforward: do not limit the search to SQL Server machines. Find every endpoint that loads Microsoft ODBC Driver 17 or 18, preserve the exact version data, and be ready to deploy Microsoft’s mapped security builds as soon as the CVE record identifies them.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: learn.microsoft.com
Download ODBC Driver for SQL Server - ODBC Driver for SQL Server | Microsoft Learn
Download the Microsoft ODBC Driver for SQL Server to develop native-code applications that connect to SQL Server and Azure SQL Database.learn.microsoft.com - Official source: support.microsoft.com
Description of the security update for Microsoft ODBC Driver 17 for SQL Server: April 9, 2024 | Microsoft Support
Description of the security update for Microsoft ODBC Driver 17 for SQL Server: April 9, 2024support.microsoft.com - Official source: techcommunity.microsoft.com
