In my previous article, I described a privilege escalation scenario involving Azure Arc-enabled SQL Server and a database-level DDL trigger created by a database-scoped principal. This database-level DDL trigger was later fired by a highly-privileged Azure Arc operation.
The situation raises a question I’ve been thinking for a while: why does SQL Server allow trigger code to inherit the privileges of whichever principal happens to fire it?
The problem: trigger code inherits the caller’s privileges
By default, SQL Server executes both DML (data manipulation language) and DDL (data definition language) triggers under the security context of the user whose statement