I'm in Italy right now, which is why I've been quiet for a couple of weeks. MSFT picked yesterday to ship the biggest Patch Tuesday on record. SecurityWeek counts 974 CVEs, and 62 of them land in Microsoft's SQL bucket. That's a lot of patching to sort through, but one of them caught my attention for a completely different reason.
CVE-2026-65669 has a CVSS score of 9.6, and MSFT titles it Microsoft SQL Server Elevation of Privilege Vulnerability. Reading that title, I would naturally expect to be looking for a vulnerable SQL Server build -- but I wouldn't be. The vulnerability is in SQL Copilot inside SSMS 22, which means the affected software could be sitting on a DBA's workstation rather than on a SQL Server at all.
That's where this one gets interesting.
Your SQL Server Can Be Fully Patched
Every step of my normal SQL Server patch process starts with a server. I pull the build, check the servicing path, determine what applies, prioritize it, schedule the work and eventually verify that the instance was patched. A vulnerability scanner working against the server estate is doing essentially the same thing from a different direction.
CVE-2026-65669 can completely escape that process because the affected product isn't necessarily installed on any of the servers I'm checking. The SQL Server itself can be current, the vulnerability scan can report it clean, and both statements can be accurate while a vulnerable copy of SSMS is sitting on a completely separate workstation used to administer the SQL Server(s).
The compliance report isn't wrong. It answered the questions we asked -- we just didn't ask about the machines running SSMS.
The Permissions Are the Bigger Story
According to Automox's analysis, an attacker can convince a user to submit specially crafted instructions to SQL Copilot, allowing the assistant to bypass its intended read-only restrictions and perform database activity using the permissions of the account already connected through SSMS. ZDI describes the same basic chain: get the user to submit specially crafted instructions to SQL Copilot, and the resulting database access occurs at that user's permission level.
That last part matters more to me than the 9.6 score. This vulnerability doesn't grant permissions. It uses the ones already on the connection. If somebody opens SSMS against production as db_owner, that's the authority sitting behind the session. If they connect with an account limited to the SELECT permissions actually required for their work, the potential impact is very different.
We've been talking about least privilege since long before anybody put Copilot in Management Studio. The difference now is that the person at the keyboard is no longer the only factor we have to consider when deciding how much authority an interactive connection should have.
The Patch Doesn't Fix the Permission Problem
Obviously, the affected copies of SSMS need to be updated. That's the immediate remediation for this vulnerability. What the patch doesn't change is the permission model behind those connections.
If DBAs and developers routinely connect to production with write permissions when they're only there to query data, those permissions will still exist after SSMS is patched. The CVE didn't create that exposure; it just gave us a very good reason to look at it more closely.
Find Out Who Is Connecting Through SSMS
You can't inventory the SSMS version installed on somebody's workstation from T-SQL, but SQL Server can tell you about the Management Studio sessions currently connected to it. Run this during normal working hours, because sys.dm_exec_sessions only tells you what is connected now:
SELECT
s.login_name,
s.program_name,
s.host_name,
COUNT_BIG(*) SessionCount,
MIN(s.login_time) EarliestLogin
FROM sys.dm_exec_sessions s
WHERE s.is_user_process = 1
AND s.program_name LIKE N'%Management Studio%'
GROUP BY
s.login_name,
s.program_name,
s.host_name
ORDER BY
s.login_name,
s.host_name;
GO
There is an important caveat here. program_name is supplied by the client, so this is useful inventory information, not something I would ever treat as a security control. What I want from the query is much simpler -- who is routinely pointing Management Studio at this SQL Server, and from which machines?
Those machines are now part of my SQL patching inventory.
Then Look at What Those Accounts Can Do
This is where I think the CVE becomes more useful than simply another item on the September patch list. Once I know which identities are being used for interactive SSMS connections to production, I want to know what authority those identities actually have.
And I don't mean just looking for db_owner. Effective access can come from server roles, database roles, direct grants, custom roles, Windows group membership and ownership. The useful question isn't whether a login belongs to one particular dangerous role. It's what can this identity actually do once it connects?
Don't Forget the Jump Box
The first place I'd look is the shared administrative server or jump box, if you have one. Those machines tend to sit in an awkward spot operationally. They're not SQL Servers, so the SQL Server patch inventory may not include them, and they're not normal end-user workstations either.
At the same time, they're often exactly where SSMS is installed, where production connections are saved, and where some of the most privileged database work in the environment takes place. If I'm looking for SSMS 22 installations that matter, I'm starting there.
What I'm Taking Away From This One
There are a lot of SQL-related CVEs to deal with this month, and the applicable SQL Server patches obviously still need to be evaluated, tested and deployed. But CVE-2026-65669 exposed something different in the way I normally think about SQL Server vulnerability management.
My process starts with the SQL Server. This vulnerability doesn't.
I could inventory every SQL Server, verify every build, install every applicable update and produce a completely accurate compliance report without ever examining the machine containing the vulnerable software. That's not really a patching failure. It's a scope failure.
So I'm adding another question to the process -- what tools are being used to administer SQL Server, where are they installed, and what permissions sit behind those connections?
Patch the SQL Servers and patch SSMS. Then take a look at the accounts people are using when they open SSMS against production. The CVE will eventually disappear from the vulnerability report. Those permissions won't.
More to Read
MSRC -- CVE-2026-65669
ZDI -- The September 2026 Security Update Review
Automox -- Patch Tuesday September 2026 CVE Analysis
SecurityWeek -- MSFT Patches Record 974 Vulnerabilities