Category: Security

Marlon Ribunal reads some guidance:

Security on your SQL Server is important. That doesn’t need any explaining. But where do you start when evaluating the security of your SQL Server? If you are like me, and probably for many DBAs, that’s the hardest part. You know security matters, but without a structured baseline, it’s easy to overlook configuration issues that could expose your environment to unnecessary risk. Starting with a proven checklist gives you a clear way to identify gaps before they become problems.

And how do you even implement the principle of least privilege on the instance and database level?

Read on to see what the US Department of Defense recommends. Also, I like pointing out Tracy Boggiano’s dbachecks updates that include CIS security auditing, though that is a few years old at this point so I’m not 100% sure how well it works.

Fabiano Amorim explains a reason for the July SQL Server patch cycle:

CVE-2026-47295 is a SQL Server vulnerability that lets a maliciously crafted database backup execute attacker-controlled code with sysadmin privileges during a routine RESTORE DATABASE operation.

The flaw lives in the internal replication cleanup procedure sys.sp_MSremovedbreplication_internal, which builds a dynamic procedure name from the restored database’s name using QUOTENAME(). Because the destination variable is only nvarchar(255), a carefully crafted database name — one packed with closing square brackets — causes the generated name to be silently truncated into a different, attacker-controlled procedure name.

SQL Server then executes that procedure under an elevated internal restore context. The proof of concept detailed in this article demonstrates full instance compromise: a restored backup creates a new SQL Server login and adds it to the sysadmin fixed server role, with no application input, no visible SQL injection syntax, and no chance for an administrator to review the database first.

As mentioned in my lead-in, the July 2026 SQL Server patches fix this vulnerability, so it’d be a good idea to install that and then check out what you could do to an unpatched instance.

Emad Al-Mousa describes a denial of service mechanism:

Denial of service attack is one of the common cyber security attacks that will cause interruption, outage and potentical finanicial and operational damages. So, its very nasty attack that attackers use for damage intent.

The main problem here is that any sql server database login (user) can create temporary tables in TEMPDB database and no specific permission is required to be granted to this account in the first place. Also, there is no way (I am currently aware off) that restricts a database login from temporary tables creation.

Prior to SQL Server 2025, I’m not sure of a great way to prevent this attack, assuming the attacker has access to run arbitrary queries against your instance.

Vlad Druma slides some data past the bouncer:

In this post I cover how an attacker can take advantage of SQL Server 2025’s sp_invoke_external_rest_endpoint to exfiltrate data from a compromised instance.

In my previous post I used sp_invoke_external_rest_endpoint to get some data about internet-exposed SQL Server instances.
While doing that, I realized that, similarly to xp_cmdshell, SQL Server 2025’s sp_invoke_external_rest_endpoint can be used by an attacker to exfiltrate data from SQL Server.

Click through to see how.

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.

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.