No hearing, or breathing… No movement, no colors… Just silence…
Sounds peaceful. Sounds serene. And in a world where entropy didn’t exist, it could even stay that way. That’s not our world, though. Our SQL Servers (in whatever flavor they exist) don’t live in utopia. They live in a world where bad actors are trying every single day to find and exploit a perfect vulnerability. Someone wants your data. They want leverage over you. And they won’t stop until they can get it. Why help them out? Let’s continue the SQL Server regret series…
A Thought That Never Changes Remains a Stupid Lie
“Why do we need to patch for this? We’ve not deployed any updates in the past several months, so we shouldn’t have a vulnerability.” – That’s the gist of what I heard back from a couple folks who received our notice about the recently released SQL Server vulnerability I posted about before this one.
At first, I was a bit shocked, but then I realized it actually makes sense and it matches a regret I hear far too often from folks who call us too late: “If we don’t change too much, we’re safe.”
Sadly, nothing can be further from the truth. When a software vendor releases a fix for a vulnerability, it certainly could be caused by a recent patch or update – but more often than not that fix is for a longstanding issue that has been until recently unknown to the world.
How do these vulnerability fixes come out?
- Software vendors pay folks bounties to find security holes.
- Governments try to break software and claim they’ve done it (unless it helps them spy on us or each other).
- Ethical hackers spend time trying to crack into systems so they can report it.
- And the bad folks? – they never stop – they are always trying to find new approaches, or take the efficient way out and read the vulnerabilities and exploit them before you patch.
This is how a critical security update comes out. Either someone was attacked (the exploit is wild), or someone found a vulnerability and is fixing it before an exploit can happen.
The key takeaway?
Old systems break as much as new ones. The longer a product remains in use, the greater the risk that previously undiscovered exploits will surface. When it does, it could take you down or put you in the headlines.
YOU.NEED.TO.PATCH.
With apologies to Neal Pert (and the NO/JD theme of the Regret Series) – if you choose not to decide to patch your SQL Servers, you still have made a choice.
The Path We Cannot Take
it’s inaction.. It’s that darn simple!!!
We cannot:
- Avoid upgrading – We need to pay attention to product lifecycles. For that most recent vulnerability, any client on SQL Server 2014 and earlier may be at risk, but there will never be a fix for them. As of Q3 2026, the same will apply to those on SQL Server 2016. (And bugs/hotfixes/code breaks are still found – but you don’t get those fixes anymore unless you are on SQL Server 2022 or higher, as of February of 2025, when SQL Server 2019 went End of Mainstream Support…)
- Ignore Patching – I get it – you don’t want downtime. But here’s the deal – downtime isn’t off the table by not patching – unplanned downtime is.. When you plan your patch, you keep your environment secure, and you plan the downtime. Instead of the bug or exploit causing it when you are trying to enjoy your vacation.
- Avoid Best Practices – Have you run a security scan of your SQL Server lately? You can use our free community tool sp_checksecurity to conduct a comprehensive security check right now. You can stay on top of best practices with other free tools from us and from experts like Brent, who offers the First Responder toolkit. Alternatively, you can call us in an emergency and pay to get help that can hopefully get you out of it, but save the money and focus on preventing that!
- Avoid Monitoring and Maintenance – Regular maintenance, monitoring, and reviews of your SQL Servers can help you stay ahead of issues before they escalate.
In Summary
It’s pretty simple. You have full control here of what you do with your SQL Servers in all their various flavors. You can choose to ignore the lack of support for your version, avoid patching, and avoid all the stuff above, and gamble… Or you can invest in your databases. You can invest in best practices, security, and monitoring, and keep things ahead of the entropy that exists.
Patch your SQL Servers, upgrade, and always be on a supported version. The bad actors don’t stop. They don’t have quiet weekends; they are always working, trying to stay ahead of you.
Take concrete steps to not be an easy target, stay current, know your SQL Servers, and send the hackers a note, saying, “Why don’t you just piss off…” and frustrate their efforts. Don’t be an easy target.
This sounds like a pretty good weekend for a DBA, and doing the work to stay current can make it so:
No alert texts, no panicked e-mails from the CEO… Just nothing…
As always, we can help. We support 120 clients today as their Senior DBA team through our proactive DBA as a Service offering. We monitor and send alerts and a daily health snapshot. We identify and address critical vulnerabilities, dedicating our weekends and nights to patching them – we stay ahead of the game. Reach out if we can be of help. Let us know if you have any questions, and stay current.
