Microsoft's May 2026 cumulative update for SQL Server 2025 (CU4, KB5089899) did two things on the same day. It closed a remote code execution hole, CVE-2026-40370, and it quietly tightened how the engine validates linked server connections. The first one got the headline. The second one is the one that broke things.
If you run linked servers over the OLE DB Provider for ODBC, ie., MSDASQL, with a provider string, then any login that is not a member of sysadmin can suddenly get bounced. Nothing about your linked server changed. Nothing about your login mappings changed. The query just stops.
Msg 7416, Level 16, State 1, Line 1 Access to the remote server is denied because no login-mapping exists.
Ironically, the same security update that hardened the engine is the one rejecting your connection.
Three Things Have to Be True
The new validation check fires under a specific shape. All of these have to be true:
| Condition | Detail |
|---|---|
| Provider | Linked server uses MSDASQL (OLE DB Provider for ODBC Drivers) |
| Provider string | The definition specifies '@provstr' |
| Login | The executing login is NOT in the 'sysadmin' fixed server role |
What makes it crazy is that nothing is misconfigured. The linked server is right and the login mappings are right -- but the query still dies. A stricter connection validation check in the Database Engine now rejects connections that earlier builds allowed. Full stop. And since sysadmin logins are exempt from that check, the problem hides from you until a non-sysadmin application login runs a query.
Microsoft does not document the internals beyond calling it a stricter connection validation check, so the honest answer stops at what they assert: the issue hits logins that are not members of the sysadmin fixed server role, it occurs even when the linked server and login mappings are configured correctly, and it is tied to MSDASQL definitions that carry a provider string. The fix is the tell. Adding 'User ID' to '@provstr' clears it, so the check is satisfied once the provider string carries an explicit user credential.
This is not unique to SQL Server 2025. The validation change rolled out across the spring 2026 servicing stream.
| Version | Update | KB |
|---|---|---|
| SQL Server 2025 | CU4 / CU5 | KB5089899 / KB5084896 |
| SQL Server 2022 | CU25 | KB5081477 |
| SQL Server 2019 | CU32 | KB5090407 |
SQL Server 2025 CU4 lands the engine at build 17.0.4040.1. If you are at or past these builds and a linked server job started failing in April or May, this is your first suspect.
The Setup That Breaks
Here is the shape that trips the check. An MSDASQL linked server defined with a provider string, queried by a non-sysadmin login.
EXEC master.dbo.sp_addlinkedserver
@server = N'ODBC_LINK',
@srvproduct = N'',
@provider = N'MSDASQL',
@provstr = N'Driver={ODBC Driver 18 for SQL Server};Server=REMOTESRV;Database=AppDB;';
GO
Run a query against it under a non-sysadmin login and the engine says no right away.
SELECT TOP (10) * FROM OPENQUERY(ODBC_LINK, 'SELECT * FROM dbo.Orders'); GO
Msg 7416, Level 16, State 1, Line 1 Access to the remote server is denied because no login-mapping exists.
The Fixes
You might be thinking about uninstalling the update, but that update closed an RCE. Rolling it back to fix a linked server is like trading a flat tire for a brake failure. Microsoft documents three workarounds:
1. Add User ID to the provider string
This is the cleanest fix. The login still has to supply 'UID' in the provider string, which is exactly what the stricter check now wants to see. Drop and recreate the linked server with 'User ID' included.
EXEC master.dbo.sp_addlinkedserver
@server = N'ODBC_LINK',
@srvproduct = N'',
@provider = N'MSDASQL',
@provstr = N'Driver={ODBC Driver 18 for SQL Server};Server=REMOTESRV;Database=AppDB;User ID=AppReader;';
GO
2. Drop @provstr entirely
If the provider string is not pulling its weight, get rid of it. Push the connection target into '@datasrc' and let 'sp_addlinkedsrvlogin' carry the security, instead of stuffing everything into a string the engine now scrutinizes.
EXEC master.dbo.sp_addlinkedserver
@server = N'ODBC_LINK',
@srvproduct = N'',
@provider = N'MSDASQL',
@datasrc = N'MyOdbcDsn';
GO
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname = N'ODBC_LINK',
@useself = N'False',
@locallogin = NULL,
@rmtuser = N'AppReader',
@rmtpassword = N'********';
GO
3. Grant the login sysadmin (not recommended)
It works because sysadmin skips the check. It is also a privilege escalation you are doing to yourself, on purpose, to undo a security patch. Microsoft lists it, then tells you not to do it. Listen to the second half of that sentence.
The Takeaway
Security hardening and 'no changes were made' failures arrive in the same box more often than vendors like to admit. When a linked server that ran for years dies right after a CU, the mappings are usually fine. Check the build, check the provider, and check whether the login carrying the query is a sysadmin or a mere mortal... The fix is very often just a User ID away.
More to Read
SQL Server 2025 Known Issues
SQL Server 2022 Release Notes (workarounds spelled out)
Cumulative Update 4 for SQL Server 2025 (KB5081495)
KB5089899 - Security update for SQL Server 2025 CU4 (CVE-2026-40370)