MS KB2269637 insecure library loading is a Nessus finding (plugin 48762) raised when Windows is not configured to stop applications loading DLLs from an untrusted current working directory. Fix it by setting the REG_DWORD value CWDIllegalInDllSearch under HKLMSYSTEMCurrentControlSetControlSession Manager to 2 or 0xFFFFFFFF, installing KB2264107 first on Windows 7, Server 2008 R2 and older.
What the scanner is actually detecting
This is a missing mitigation, not a missing security patch for one specific bug. In 2010 Microsoft published Security Advisory 2269637 about “binary planting” or “DLL preloading”: an application calls LoadLibrary with a bare DLL name, Windows searches a list of folders, and one of those folders is the current working directory. If a user opens a document from a network share, that share becomes the working directory, and a planted DLL with the right name can be loaded into the application.
| Scanner | Finding title | ID |
|---|---|---|
| Nessus (Tenable) | MS KB2269637: Insecure Library Loading Could Allow Remote Code Execution | Plugin 48762 |
Plugin 48762 is a local, credentialed check in the Windows family. It needs registry access over SMB and reports that the host “is missing Microsoft KB2264107 or an associated registry change”. KB2264107 is the update that taught the Windows loader to honor a new value, CWDIllegalInDllSearch. The update ships with protection disabled, so installing it alone changes nothing. Tenable’s solution text says the same thing: the patches must be combined with the registry setting to have any effect.
KB2264107 was released for Windows XP, Server 2003, Vista, Server 2008, Windows 7 and Server 2008 R2. There is no KB2264107 package for later Windows versions, so on current hosts the registry value is the only thing to change.
How serious is it in practice?
Tenable rates the plugin High with a CVSS v2 base score of 9.3. That score describes the worst case: a vulnerable application, a user tricked into opening a file from an attacker-controlled SMB or WebDAV location, and code running with that user’s rights. Microsoft’s own advisory lists the limits. Only applications that load libraries insecurely are affected, the user has to open a file from the remote location, and SMB is usually blocked at the perimeter firewall. Safe DLL search mode, on by default since Windows XP SP2, already puts the current directory behind the application, system and Windows folders, so a planted DLL only wins when the application asks for a library that is not found in those earlier locations.
Microsoft also notes a local variant: someone who can already write to a folder may use a preloading bug in an elevated application to raise privileges. The honest summary is that this is a cheap, fleet-wide hardening control against a whole class of application bugs, worth deploying, but not an emergency on its own. It also only touches the working directory. It does nothing about writable application folders or writable directories in PATH.
Confirm it on the host
Check the system-wide value from an elevated prompt:
reg query "HKLMSYSTEMCurrentControlSetControlSession Manager" /v CWDIllegalInDllSearch
“ERROR: The system was unable to find the specified registry key or value.” means the value is not set, which is the default state and the reason for the finding. List any per-application overrides as well:
reg query "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options" /s /v CWDIllegalInDllSearch
On Windows 7, Server 2008 R2 or older, confirm the update is present:
Get-HotFix -Id KB2264107
wmic qfe get HotFixID | findstr 2264107
If you read the value from PowerShell, note that Get-ItemProperty shows a DWORD of 0xFFFFFFFF as -1. That is the same value, not a misconfiguration.
How to fix it
Pick a value
Microsoft’s KB2264107 defines these values for applications started from a local folder such as C:Program Files:
| Value | Effect on DLL loads from the current working directory |
|---|---|
| 0, missing, or any other value | Default search order, no protection |
| 1 | Blocked when the working directory is a WebDAV folder |
| 2 | Blocked when the working directory is a remote folder (WebDAV or UNC) |
| 0xFFFFFFFF | Working directory removed from the default DLL search order entirely |
Microsoft’s MSRC team wrote that 2 set system-wide blocks network-based attacks, and that 0xFFFFFFFF also covers local vectors such as a malicious DLL on a USB drive or in an extracted ZIP attachment. One caveat from the KB: with value 2, an application that was itself started from a remote share can still load DLLs from a remote working directory. A practical plan is 2 as the fleet baseline and 0xFFFFFFFF on hosts where testing shows no breakage.
Windows 7, Server 2008 R2 and older
Install KB2264107 first. Without it the registry value is ignored and plugin 48762 will keep firing, correctly. These versions are long out of support, so treat the finding as one more item on the retirement list.
Single host with reg.exe
rem Baseline: block CWD DLL loads from WebDAV and UNC paths
reg add "HKLMSYSTEMCurrentControlSetControlSession Manager" /v CWDIllegalInDllSearch /t REG_DWORD /d 2 /f
rem Strict: remove the working directory from the search order
reg add "HKLMSYSTEMCurrentControlSetControlSession Manager" /v CWDIllegalInDllSearch /t REG_DWORD /d 0xffffffff /f
Exempting one application
The KB is explicit that the per-application entry always overrides the system-wide setting. That lets you keep a strict global value and relax it for one binary. The key name is the executable file name only, not a path:
reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution OptionsLegacyApp.exe" /v CWDIllegalInDllSearch /t REG_DWORD /d 2 /f
Setting the per-application value to 0 restores the default search order for that executable alone.
Group Policy for many hosts
The simplest way to push the value is a Group Policy Preferences registry item. In the Group Policy Management Editor go to Computer Configuration > Preferences > Windows Settings > Registry and create a new Registry Item:
- Action: Update
- Hive: HKEY_LOCAL_MACHINE
- Key Path: SYSTEMCurrentControlSetControlSession Manager
- Value name: CWDIllegalInDllSearch, Value type: REG_DWORD
- Value data: 2, or ffffffff with Base set to Hexadecimal
Add per-application exemptions as extra registry items under the Image File Execution Options path. Link the GPO to a pilot OU first. Microsoft’s advisory also lists two complementary workarounds: disabling the WebClient service where WebDAV is not needed, and blocking TCP 139 and 445 at the perimeter firewall.
Verify the fix and rescan
- Run gpupdate /force if you used Group Policy, then re-run the reg query. Expect a line such as CWDIllegalInDllSearch REG_DWORD 0x2 or 0xffffffff.
- KB2264107 does not list a restart requirement for the value. To be sure you are testing the new behavior, restart the applications you are testing, or reboot the pilot host.
- Run a credentialed Nessus scan. The plugin needs registry access over SMB (ports 139 and 445), and plugin 48762 should no longer be reported.
A clean rescan proves the value exists. It does not prove your applications still work, which is the next section.
What can break and how to roll back
Anything that legitimately loads a DLL by bare name from the folder it was launched from, or from a share it works in, can fail with “module could not be found” style errors. Documented cases include:
- The Outlook 2002 address book, mentioned by MSRC as a compatibility report.
- Veeam Backup & Replication, where users on Veeam’s forum reported VeeamAgent.exe failing under 0xFFFFFFFF and fixed it with a per-application value of 2.
- IBM Cognos services failing to start, per an IBM support alert about this change.
Before tightening a server, Microsoft’s DLL security guidance suggests Process Monitor: filter on CreateFile and LoadImage operations with paths containing .dll, exclude successful results, then launch the application the way users do and look for DLL lookups in the working directory or on a share.
Prefer a per-application exemption over a global rollback. If you must revert, the KB states that setting the value to 0 undoes the change:
reg add "HKLMSYSTEMCurrentControlSetControlSession Manager" /v CWDIllegalInDllSearch /t REG_DWORD /d 0 /f
If you deployed through a GPP Update item, deleting the value locally is overwritten at the next refresh, and unlinking the GPO leaves the value in place. Change the item’s action to Delete (or set it to 0), or tick “Remove this item when it is no longer applied” on the Common tab before deploying.
Common false positive reasons
- Update missing on legacy Windows. The value is set, but KB2264107 is not installed. That is a true positive, because the value has no effect without the update.
- Only per-application values. Exemptions under Image File Execution Options do not set the system-wide value that the finding is about.
- Wrong type or location. Microsoft’s examples create a DWORD directly under Session Manager. A typo in the name or a value under a subkey such as Session ManagerEnvironment will not count, and a REG_SZ value may not be read the way you expect. Recreate it as REG_DWORD.
- Value set to 0. Zero is the documented default behavior, so the host is still unprotected.
- Stale results. The GPO has not applied yet, or the report predates the change. Rescan with credentials.
Once the fleet is clean, add the value to your build standard, for example in a Windows Server hardening checklist, so rebuilt servers do not bring the finding back.
FAQ
Is KB2269637 a patch I can install?
No. 2269637 is the number of Microsoft’s security advisory. The installable update for older Windows is KB2264107, and the protection itself is the CWDIllegalInDllSearch registry value.
Which value should I choose?
Use 2 as a broadly compatible baseline that blocks WebDAV and UNC working directories. Move to 0xFFFFFFFF where testing allows, and exempt individual applications that break.
Do Windows 10, Windows 11 or Server 2019 need KB2264107?
No. The update was only released for Windows XP through Windows 7 and Server 2008 R2. On newer versions, setting the registry value is what clears the finding.
Does this fix DLL hijacking in general?
No. It only changes how the working directory is searched. Writable application folders and writable PATH directories need their own permission fixes, and developers should load libraries with full paths or the LOAD_LIBRARY_SEARCH flags.
Tracking this finding across many hosts
Plugin 48762 tends to appear on every Windows host in a scan, so the real work is confirming each one closed. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results via uploaded .nessus exports), can have its AI draft a host-specific registry script that its Windows agents deploy only after human approval, and can retest individual Nessus findings to verify closure.
Sources
- Tenable: Nessus plugin 48762, MS KB2269637: Insecure Library Loading Could Allow Remote Code Execution
- Microsoft Security Advisory 2269637: Insecure Library Loading Could Allow Remote Code Execution
- Microsoft KB2264107: A new CWDIllegalInDllSearch registry entry is available (archived copy)
- MSRC blog: An update on the DLL-preloading remote attack vector
- Microsoft Learn: Dynamic-Link Library Security