…on a fully patched SQL Server 2014. And “fully” patched is why I’m writing this post.
You know the thriller movies where they keep looking for the creepy stalker type? The phone calls keep coming, the signs of stalking are there, and they do a bunch of digging and through the taps or traps they realize the calls are coming from inside the house.
I just spent an afternoon proving something I’ve been saying for years, and it landed exactly where I expected. It was one part exciting (I had to do some ugly stuff to get SQL Server 2014 to install, and I got to do a demo in some SQL which is a nice change from spreadsheets and Level 10 meetings…) And one part scary (What I keep shouting is proven true, in about 1 minute in the second part of this video:)
The SQL Server Vulnerability
Here’s what I did. I stood up a SQL Server 2014 instance. Service Pack 3, latest CU, latest security update (I’m not paying for the ESUs so I don’t know if this one is fixed already for those paying for the 2014 ESUs, they run out next year anyway, and they aren’t there for SQL Server 2012 and back.) Then I built a second instance to be my victim, patched it exactly the same way, and I restored a database backup to it that I created on the first. I added a stored procedure to a database on the souirce instance, made the DB a publisher in replication, added a schema and took a backup of it. That’s it. No password cracking. No malware. No clever network trickery. I restored a backup to the second instance, which is the single most routine thing a DBA or a sysadmin does in any given week. And when the restore finished, there was a brand new login sitting in the sysadmin role that I never created on that instance. I logged in as it. I owned the instance. Game over.
(If you want the deep technical walkthrough of how this actually works, go read Fabiano Amorim’s excellent post over at Redgate. He found this, he reported it to Microsoft, and he explains the mechanics far better than I’m going to here. I just followed his steps in my little lab (fixing one little typo – he needed an extra bracket in most scripts.) All the credit is his.
The short version: it’s CVE-2026-47295, Microsoft rates it an 8.8, and the trick behind it is a tricky one. An attacker crafts a database with a deliberately bizarre name (a big pile of closing brackets in this case), adds a simple stored procedure inside it with a schema with the same bizarre name as the database, backs the whole thing up, and hands you the .bak. When SQL Server restores that backup and runs its normal replication cleanup when you restore a DB to a new instance, an old internal procedure builds a name, runs out of room in the variable it’s stuffing that name into, and winds up running the attacker’s cleverly named schema.procedure instead. As the highest privileged user that could exist in SQL Server – internal to the system…. During the restore. Before you’ve even had a chance to look at the thing you just restored. (And he could have gotten more creative also – make a job that does things, add more logins, add some steps, exfiltrate data, unlock other doors, etc.)
Microsoft Not Patching an Unsupported Version Does NOT Mean It’s Safe!!!
Microsoft fixed this on July 14th, 2026. They fixed it on SQL Server 2016 (Service Pack 3), 2017, 2019, 2022, and 2025. They did not fix it on 2014 (unless they did with the ESUs – not a subscriber there..) They did not fix it on 2012 or back. It would be very easy to skim that list and think “well then, the old ones must not be affected.” That read is exactly backwards. Those older versions didn’t get the fix because they’re out of support. Out of support means the patches stop coming. It does not mean the bugs politely stopped existing.
And this code is old. The whole replication cleanup path this bug lives in has been kicking around SQL Server since, as near as I can tell from poking at it, the 2005 era (that appears to be the last time that proc was changed – I didn’t have the time to test all versions but if this one doesn’t impact older versions – but isn’t SQL Server 2014 old enough?!? – the next one may anyway..) Replication itself goes back further than that. Nobody introduced this in some shiny recent feature release. It’s old plumbing that’s been sitting inside just about every version you’ve ever run, quietly, for the better part of two decades, until somebody finally looked at it hard enough to notice.
This is Why I Keep Shouting UPGRADE YOUR SQL SERVERS!
The vulnerabilities getting found and patched month after month are usually not in the brand new stuff. They’re in the old surface area. The plumbing that’s been there forever and nobody scrutinized until now. Which means when one of these gets discovered and published, the odds are very good it was already sitting inside your unsupported instance the entire time, just waiting for someone to walk up to it. And the odds are close to certain that more are on the way, because the folks hunting for these things (both the good-faith researchers chasing bug bounties and the bad actors who are very much not chasing bug bounties) are burning through tokens looking for them just as fast as Microsoft’s team is fixing them. It’s a steady drip. Every patch month. On and on.
You Can Harden SQL Server… But Is That Enough?
So let me be fair here, not all FUBAR on you. This particular bug? You can absolutely harden against it. And you should, today, on every instance you’ve got, supported or not… This is just some good advice with or without this one:
- Don’t restore backups you didn’t create onto anything that matters. Treat a vendor’s .bak or a customer’s .bak the way you’d treat a random .exe you found on the internet. No amount of paranoia is too much here.
- Use an isolated, throwaway lab instance for restoring anything that came from outside your walls.
- Alert on RESTORE operations. Most shops watch queries all day and never once watch restores. A restore is a privileged event and it deserves eyes on it.
- Alert on new logins, and especially on new members of the sysadmin role.
- Go hunting for databases and schemas with strange names (long runs of brackets are a dead giveaway with this one).
- Run a security sweep with a tool like SP_CheckSecurity on the regular.
- Setup auditing and actually read the audits regularly.
Do all of that. It’s good best practice and it helps you with a lot more than just this one CVE.
But here’s what hardening can’t do for you. It can’t protect you from the one you haven’t read about yet that finds some new flaw we aren’t auditing. Or maybe it exploits you and you can read all about it, tomorrow or on Monday. Running on software that gets updates means that Microsoft is on your security team at least in some fashion… They are finding and fixing the exploits that you are buying time against with the best practices. Hardening buys you time on the bugs you know about and the ones that eventually get fixed. Being on unsupported software means you are out there on your own longer than you’d like to be.
Count The Cost
Which brings us to the only question that actually matters to the person signing the checks. What does it cost to stay?
There are two doors, and honestly I don’t love either one of them for you.
Door one is ESU. Microsoft’s Extended Security Updates program will happily sell you critical patches for 2016 (and 2014’s paid window is nearly shut now too). But you pay through the nose for the privilege, and you only ever get the updates that Microsoft decides are “critical.” and I’m sure their lawyers made the agreement you sign be in their favor – it’s probably best effort, no guarantee. You and I don’t get a vote on that definition. And Microsoft is a very busy company these days, trying to keep Fabric up, fixing the bugs that the AI bug hunters are finding and worrying about the cloud. Your ten or 12 year old database engine isn’t where their major focus is. I would not want to bet my clients’ data on how much attention an out-of-support version is going to get.
Because here’s the thing a lot of folks have never actually checked: Insurers are starting to carry conditions about running supported, patched software. Running an end-of-life database engine can hand your insurer a very clean reason to reduce or flat-out deny a claim
Door two is worse. Door two is the breach you weren’t covered for. Because here’s the thing a lot of folks have never actually checked: Insurers are starting to carry conditions about running supported, patched software. Running an end-of-life database engine can hand your insurer a very clean reason to reduce or flat-out deny a claim. And when that claim gets denied, the remediation, the breach notifications, the lawsuits, the settlements with your Credit Union members, patients, banking clients, SaaS subscribers, manufacturing customers, etc. all come out of your company’s pocket, and the numbers involved are the kind that decide whether a company is still around next year. It’s also the meeting where everybody in the room slowly starts looking around for the one person who decided to stay on the old version.
Upgrading is cheaper than either door. Over Time – It’s not even close.
And upgrading is not the monster you’re picturing in your head right now. I’ve been doing SQL Server work for a long time, and I still treat every single upgrade with care and a healthy dose of paranoia. But with some real planning, a clean build, honest testing, and the compatibility mode settings that exist precisely so this goes smoothly, we move shops onto a supported version all the time. (Just don’t get me started about in-place upgrades… Let us help you do a simple migration upgrade.) For the simplest of environments it can be as little as 20 hours of work. We do dozens to scores of these a year for our clients. It’s become almost second nature, which is exactly what you want an upgrade to feel like.
So that’s my plea. If you’re on 2014, or you’re on 2016 without paying Microsoft’s toll, or (I see you out there….) something older still, please go build a plan. This week’s demo is just ONE bug. There will be another one next month, and it’ll probably be in old code too, and the fix will land on the supported versions and skip right over yours.
If you want a hand, reach out. Even if all you want is a second set of eyes and a straight answer about what your upgrade path would actually look like. I’m glad to point you in the right direction whether you ever become a customer or not.