What’s the issue?
A linked server is a SQL Server configuration object that defines a connection to another data source, allowing distributed queries, remote stored procedure calls, and cross-server joins to be executed against the remote source as if it were local. Linked servers can target other SQL Server instances, other database platforms through OLE DB providers, files, and various external systems.Each linked server has a security context configuration that determines how queries against it are authenticated. Options include impersonating the calling user (mapped through Windows authentication), using a fixed remote login and password, mapping specific local logins to specific remote logins, or making no connection at all for unmapped logins.
This finding identifies instances where one or more linked servers are configured.
Why is this a problem?
The most significant concern with linked servers is the security context used for the remote connection. When a linked server is configured to connect to the remote system using a fixed login that has elevated privileges, any local user who can use the linked server inherits those privileges on the remote system, regardless of what their own permissions would normally allow.The most extreme case is a linked server configured to connect using sa or another sysadmin-equivalent account on the remote system. In this configuration, any user able to query through the linked server effectively has full administrative control over the remote instance, even if they have no direct access to it. This is a privilege escalation path that bypasses the normal permission model entirely. sp_CheckSecurity classifies this as level 1, “High – action required,” because the consequences of leaving such a configuration in place are severe.
Linked servers are also a known SQL injection amplifier. An injection vulnerability in an application connecting through a linked server can extend the attack to the remote system, potentially exfiltrating data, executing commands, or pivoting to additional systems through chained linked servers. The blast radius of any single compromise grows with each linked server that carries elevated remote credentials.
The condition is also worth attention because linked server configurations are often deployed once and rarely revisited. Credentials configured years ago for a since-retired use case may still be active, with the linked server providing an attack path that no current team member is aware of. Reviewing existing linked servers periodically catches these forgotten configurations before they are exploited.
What should you do about this?
Review each linked server with the application owners to confirm it is still required and that the security context is appropriate. Linked servers that are no longer used should be dropped, removing both the linked server definition and any associated login mappings.For linked servers that must remain, eliminate any use of sa or other sysadmin-equivalent accounts as the remote credential. Replace these with dedicated, least-privilege accounts on the remote system that have only the specific permissions required for the actual queries the linked server supports. The dedicated account should be specific to the linked server use case, with strong credentials managed through your secrets management system.
Where the use case allows, prefer Windows authentication with impersonation over stored credentials. This eliminates the credential-storage problem entirely and ensures that remote operations are performed with the calling user’s own permissions, preserving the normal permission model rather than bypassing it. Constrained delegation may be required to support impersonation across servers in some Active Directory configurations.