Microsoft published a new elevation-of-privilege vulnerability in its ODBC Driver for SQL Server on July 14, 2026. The advisory, tracked as CVE-2026-42990, arrived without a security patch, a list of fixed driver versions, or details on how an attack would actually play out. That missing information transforms the immediate response from a simple update to a sweeping inventory of every machine that might be carrying the vulnerable code—which often means far more than just database servers.

The Silent Spread of ODBC Drivers

ODBC Driver for SQL Server is a client library. It lets applications—whether custom in-house tools, reporting services, or enterprise management consoles—talk to Microsoft’s database platforms. That architecture means the driver gets installed on developer workstations, scheduled-task hosts, application servers, administrator desktops, golden images, and even build agents. None of those endpoints need to host a SQL Server instance to be at risk. If they connect to a database anywhere, they probably have the driver on board.

Both ODBC Driver 17 and ODBC Driver 18 can coexist on the same computer. Older software might keep loading Driver 17 even after you update Driver 18, leaving a hidden exposure. The drivers also install in both 64-bit and 32-bit variants on x64 and ARM64 systems, so checking only one registry location or looking at a single “Programs and Features” entry gives an incomplete picture.

What We Know—and Don’t Know—About CVE-2026-42990

Microsoft confirmed the vulnerability and classified it as an elevation-of-privilege flaw. That tells defenders a security boundary was crossed—but not where the attacker starts. Is this exploitable by a local user with a basic account? Through a compromised web application that makes database calls? By a malicious server responding to a client connection? The advisory doesn’t say yet.

The advisory also includes a generic confidence-metric description that explains how Microsoft rates the certainty of a vulnerability’s existence. Some readers scanned that text and interpreted it as evidence of active attacks; it is not. It’s a boilerplate explanation that sits on many CVE pages until the vendor supplies concrete temporal scores. As of publication, the record shows no exploitation detected, no public proof-of-concept, and no attack vector.

What we do know: Microsoft ODBC Driver 17 and ODBC Driver 18 are the affected components. The latest generally available releases before the July advisory were version 18.6.2.1 (March 31, 2026) and version 17.11.1.1 (April 30, 2026). Neither is confirmed to fix CVE-2026-42990. Administrators should not assume any existing build is safe unless Microsoft explicitly links a CVE fix to that version number.

Why This Vulnerability Is Tricky to Pin Down

Elevation-of-privilege bugs are often chained with other exploits. An attacker who already has some foothold—say, a low-privileged user session or a compromised application component—could use this flaw to gain higher rights on the same box. Until Microsoft publishes prerequisites, a cautious triage looks at every combination of driver and privilege level.

A tightly controlled workstation running a single internal database app might be low-priority. The same driver version on a multi-tenant integration server, a terminal server with dozens of concurrent user sessions, or a CI/CD runner that connects to production databases under a service account is a different story. Administrators should assign higher operational priority to systems where the driver coexists with untrusted users, exposed network services, high-privilege service identities, or customer-controlled input that could influence database queries.

Side-by-side driver installations create another blind spot. A machine may show ODBC Driver 18 registered as the default, but an older .NET application might be hard-coded to load “ODBC Driver 17 for SQL Server.” Until you check what each process actually loads—not just what’s installed—you haven’t fully mapped the exposure.

Who’s at Risk—And Who Should Act First

Home users and small businesses that only run off-the-shelf software are unlikely to face immediate danger. However, if you installed SQL Server Management Studio, Power BI Report Builder, or any tool that connects to a cloud database, you almost certainly have the driver. Your risk hinges on whether the machine accepts remote connections or runs services with elevated privileges. Keep the driver updated when a patch arrives, but for now, just note the version and watch for news.

Enterprise IT teams need to act. Every server, desktop, virtual desktop image, and automation node in the environment should be inventoried for msodbcsql17 and msodbcsql18. Don’t overlook developer machines, data-migration appliances, or utility boxes used for sqlcmd and bcp. If you manage Linux or macOS hosts with Microsoft’s cross-platform ODBC packages, include them in the scan—unless Microsoft later limits the affected scope to Windows.

Developers who build and deploy applications that bundle the ODBC driver must check their CI/CD pipelines and container images. A vulnerable driver copied into a container or an installer package is just as dangerous as a system-level installation, and it may be harder to discover after deployment.

How We Got Here: ODBC’s Long Security Timeline

ODBC isn’t a new surface. Microsoft has issued security updates for these drivers before—for example, the April 2024 hotfixes for ODBC Driver 17 that addressed remote code execution and information disclosure flaws. Driver 18, introduced in 2022, changed default encryption behavior and gradually became the recommended path for new development. Many organizations still maintain both branches because legacy apps resist migration.

Microsoft’s disclosure cadence typically places a CVE in the Security Update Guide first, sometimes days or weeks before a matching patch ships. The July 14 publication fits that pattern: get the vulnerability on the record, give IT teams time to assess, and deliver the fix later via a Patch Tuesday or an out-of-band release. The lack of a CVSS score and attack details is not unusual at this stage, but it creates a tension between the urgency of an elevation-of-privilege label and the uncertainty of its real-world impact.

Your Pre-Patch Action Plan

Before Microsoft releases fixed builds, you can’t seal the hole. You can, and should, prepare to do so the moment the update drops. Here’s where to start.

  1. Inventory every installation. Check “Apps & Features” or “Programs and Features” for entries named “Microsoft ODBC Driver 17 for SQL Server” and “Microsoft ODBC Driver 18 for SQL Server.” Don’t stop there. Run a PowerShell scan with Get-OdbcDriver | Where-Object Name -like “*ODBC Driver 1[78]*” to see registered drivers. Also inspect the file system for msodbcsql17.dll and msodbcsql18.dll in both C:\\Windows\\System32 and C:\\Windows\\SysWOW64. A single driver installer can put files in both spots.

  2. Map applications to drivers. Ask application owners to document connection strings and Data Source Names (DSNs) that reference “ODBC Driver 17” or “ODBC Driver 18.” A DSN configured in the ODBC Data Source Administrator (32-bit and 64-bit versions) may point to a driver that isn’t the system default. Capture both the product version from the installer metadata and the file version of the actual DLL loaded by running processes.

  3. Don’t forget non-Windows systems. If your environment uses the Microsoft ODBC driver on Linux or macOS, inventory those hosts using package managers (dpkg, rpm, or brew). Until Microsoft clarifies the affected platforms, treat them as potentially vulnerable.

  4. Prioritize based on privilege. Systems where the driver operates under a high-privilege account—a Windows service running as SYSTEM, a scheduled task with domain admin rights—deserve immediate attention. Multi-user hosts, web servers, and integration middlewares that process external input should be next.

  5. Prepare to test, not just patch. ODBC driver updates can alter encryption defaults, authentication flows, and connection pool behavior. Plan a testing cycle that covers Entra ID authentication, integrated Windows authentication, certificate-based connections, encrypted connections, failover configurations, and DSN connectivity. Applications that keep the driver loaded may need a service restart even if the installer doesn’t force a reboot.

Resist the temptation to switch a Driver 17 application to Driver 18 simply because you’ve heard Driver 18 is newer. A major-version migration is a separate project with its own testing requirements. The preferred path is to apply a security fix within the same major branch—unless Microsoft declares that only one branch will receive a patch.

What’s Next: Watching for the Real Fix

Microsoft will eventually revise the CVE-2026-42990 advisory. Watch for a modification date appearing on the Security Update Guide page, along with a table of affected products and fixed build numbers. Knowledge Base articles and updated download pages for ODBC Driver 17 and 18 will likely appear at the same time.

Once a patch ships, the job shifts from inventory to verification. Deploy the update, then confirm that running applications actually load the patched DLL. On Windows, tools like Process Explorer or the tasklist /m msodbcsql*.dll command can show which processes have the driver mapped. Only when the updated file is in memory is the system truly no longer vulnerable.

And one final note: updating the ODBC driver is not a substitute for applying SQL Server Cumulative Updates. The driver is a separate component with its own security boundaries. A patched client still connects to a vulnerable server, and vice versa. Both sides need independent attention.