{"id":112314,"date":"2026-08-21T12:00:00","date_gmt":"2026-08-21T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=112314"},"modified":"2026-08-21T08:09:35","modified_gmt":"2026-08-21T08:09:35","slug":"draft-need-to-finalize-date-still-tbc-microsoft-recommends-that-you-dont-do-it-then-azure-arc-does-it","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/data-security-privacy-compliance\/draft-need-to-finalize-date-still-tbc-microsoft-recommends-that-you-dont-do-it-then-azure-arc-does-it\/","title":{"rendered":"How Azure Arc allows a DB admin to become SQL Server sysadmin – the vulnerability explained"},"content":{"rendered":"\n

Azure Arc-enabled SQL Server is designed to bring on-premises and multi-cloud SQL Server instances under centralized Azure management, but a newly documented privilege escalation technique shows how that same management workflow can be turned against the server it’s meant to protect. <\/strong><\/p>\n\n\n\n

By combining a database-level DDL trigger with the elevated identity the Azure Arc extension uses during onboarding and configuration, a login with nothing more than db_ddladmin<\/code> permissions in a single database can escalate to full sysadmin control over the entire SQL Server instance. The result? Complete server compromise.<\/strong><\/p>\n\n\n\n

In this investigative guide, Fabiano Amorim explains how the vulnerability works, how to reproduce it in a lab environment, why Microsoft classified it as Low severity, why that classification is disputed, and what mitigations are available today.<\/strong><\/p>\n\n\n\n

\n
\n\n

Disclosure note<\/strong> <\/p>\n\n\n\n

I reported this vulnerability to the Microsoft Security Response Center on June 8, 2026. Microsoft investigated it, classified it as Low severity, stated that it did not meet the bar for immediate service, and declined to issue a CVE. <\/p>\n\n\n\n

Microsoft’s position is that the demonstrated trigger-based escalation falls within SQL Server’s documented trigger security model and, given the permissions required to create or modify the trigger, does not cross a SQL Server security boundary. <\/p>\n\n\n\n

This article presents the demonstrated technical behavior, Microsoft’s assessment of that behavior, and the reasons I disagree with Microsoft’s security-boundary and severity conclusions.<\/p>\n\n<\/div>\n<\/div> \n\n\n

At this point, I hope you\u2019re already aware of SQL Server permission hijacking via triggers (if not, check out the articles below):<\/p>\n\n\n\n

\n
\n\n

Don’t Let Your Permissions be Hijacked!<\/a><\/p>\n\n\n\n

Official Microsoft documentation on managing trigger security<\/a><\/p>\n\n\n\n

How SQL Server maintenance becomes an attack path \u2013 and what to do about it<\/a><\/p>\n\n<\/div>\n<\/div> \n\n\n

In this article, I\u2019d like to disclose a privilege escalation vulnerability in the Azure Extension for SQL Server<\/a> used by Azure Arc-enabled SQL Server.\u00a0<\/p>\n\n\n\n

How does the Azure Arc SQL Server privilege escalation vulnerability work?<\/h2>\n\n\n
\n
    \n
  1. A login with db_ddladmin<\/code> (or equivalent permissions sufficient to create a database-level DDL<\/a> trigger) in one database creates a database-level DDL trigger. <\/li>\n<\/ol>\n<\/div>\n\n
    \n
      \n
    1. The Azure Arc SQL<\/a> extension connects to the SQL Server instance using a highly privileged identity. <\/li>\n<\/ol>\n<\/div>\n\n
      \n
        \n
      1. The extension enters the attacker-controlled database and executes database-level DDL commands. <\/li>\n<\/ol>\n<\/div>\n\n
        \n
          \n
        1. Those commands fire the attacker-created DDL trigger. <\/li>\n<\/ol>\n<\/div>\n\n
          \n
            \n
          1. The trigger executes under the privileged context supplied by the Azure Arc operation. <\/li>\n<\/ol>\n<\/div>\n\n
            \n
              \n
            1. The trigger performs server-level administrative actions. <\/li>\n<\/ol>\n<\/div>\n\n
              \n
                \n
              1. The original login becomes a member of the sysadmin<\/code> fixed server role<\/a>. <\/li>\n<\/ol>\n<\/div>\n\n\n

                The attacker can’t execute the server-level operation directly, but the escalation succeeds because the Azure Arc SQL extension enters the database while retaining a privileged server-level execution context. <\/p>\n\n\n\n

                The result of the attack – and Microsoft’s response<\/h2>\n\n\n\n

                The final result is complete compromise of the SQL Server instance.<\/strong> An attacker can access every database, create logins, change server configuration, disable auditing<\/a>, establish persistence<\/a>, modify data outside the original database, and perform any other operation available to a SQL Server system administrator. <\/strong><\/p>\n\n\n\n

                I\u2019ve reported this to Microsoft and they closed the case, classifying it as \u201cLow severity and does not meet Microsoft’s bar for immediate servicing\u201d. <\/em>You can read more details on the report timeline later in this article. <\/p>\n\n\n\n

                But, just to provide some details around my concern, I\u2019d like to start with some comments about it: <\/p>\n\n\n

                \n