Category: Security

Emad Al-Mousa tests some permissions:

I was exploring SQL Server Text Indexes, and while exploring it I stumbled upon the function sys.dm_fts_index_keywords.

According to the “current” version of the documentation (up to 1 September 2026): https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-objects/sys-dm-fts-index-keywords-transact-sql?view=sql-server-ver17

sysadmin role is required to run this function, I found out that this is not true !

Click through for the test. Granted, this does require CONTROL on the database, so not something that J. Rando db_datawriter can do.

Leave a Comment

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.

Comments closed

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.

Comments closed