Category: Security

Fabiano Amorim shares some advice:

SQL Server is often marketed or perceived as secure by default, but real-world testing shows that default installations and default permissions still expose several attack surfaces. With this in mind, “secure by default” does not mean “safe without review.” 

Many risks come from legacy behavior, backward compatibility, broad permissions granted to the public role, system procedures, implicit trust boundaries, and administrative convenience features. 

The risk appears when they are combined: a database user with more permissions than necessary, a maintenance job running as a highly privileged owner, an unexpected trigger, or an impersonated module that changes how permissions are evaluated. 

Click through for a depiction of how the attack path works and things you can do to prevent systems compromise.

Leave a Comment

Vlad Drumea does some sleuthing:

In this post I dig through some data that Shodan provides for internet-exposed SQL Server instances, their versions and locations.

I occasionally check Shodan for SQL Server instances that are publicly exposed on the internet for anyone to poke at. I make a LinkedIn post about it (like this one) and then just leave it at that.
So, this time, I’ve decided to dig a bit more into that data and document it here.

Click through to see what Vlad was able to find.

Leave a Comment

Mike Lynn provides a heads-up:

In July 2026 Microsoft is making a change that may impact your environment. The change being implemented will make your environment more secure by no longer accepting the RC4 algorithm for the Kerberos protocol by default. The problem though is it could cause authentication failures, services to not start, and Kerberos to stop working. Microsoft has been working to implement this change since January 2026, and July 2026 is the final phase.

Click through to see what this means and what you can do to make sure it doesn’t affect you.

Comments closed

Fabiano Amorim digs into a fixed issue:

What makes this case particularly interesting is not just that the vulnerability exists in a trusted system object, but how it works: the injection bypasses a REPLACE-based sanitization attempt through a subtle Unicode character conversion that happens silently during a variable assignment.

The vulnerability was reported to Microsoft and they have since fixed it, but it’s still worth exposing and explaining given how intricate it is. So, that’s what I’ll do in this article.

Click through to see how it works. And of course this database mirroring stored procedure is still hanging around long after database mirroring itself was deprecated. But that’s the downside to deprecation without subsequent removal.

Comments closed