What’s the issue?
Extended stored procedures are functions written in C or C++, compiled into a DLL, and registered in SQL Server with sp_addextendedproc. Once registered, they are called like any other stored procedure but execute as native code inside the SQL Server process rather than as T-SQL.
They were the original mechanism for extending SQL Server beyond what T-SQL could do, predating CLR integration. Microsoft deprecated them years ago in favor of CLR, which provides comparable capability with a managed runtime and a permission model.
Why is this a problem?
The DLL loads native code into the SQL Server process, where it runs with no permission checks. Anything the code does, including memory access, file system operations, network calls, and process creation, happens under the SQL Server service account with the full authority of the engine process.
A defect in the code can destabilize the entire instance. Unlike CLR assemblies, which run in a managed runtime that contains most failures, an extended stored procedure that corrupts memory or throws an unhandled exception can crash SQL Server outright or cause corruption that surfaces later.
Registering a procedure requires sysadmin, so an unexplained entry pointing at a DLL on the host is a strong signal that someone with elevated access placed code there deliberately, and it will continue to be callable across restarts.
What should you do about this?
Review the registered procedures by querying sys.extended_procedures, capturing the procedure name and the DLL path for each. Confirm with your organization that each entry corresponds to a known vendor product or an internally developed component that is still in use.
Remove entries that are no longer needed with sp_dropextendedproc, and delete the associated DLL from the host after confirming nothing else depends on it. Treat any entry that cannot be attributed as suspicious and investigate the DLL before removing it, since it may indicate a broader compromise.
For procedures that must remain, confirm the DLL is from a trusted source, that its location on the host is restricted to prevent replacement, and that the vendor still supports it. Where an equivalent CLR implementation exists, plan a migration, since extended stored procedures are deprecated and slated for removal.