{
	"id": "9d4a08d6-2fac-4386-ab9d-908892522ec3",
	"created_at": "2026-04-06T00:08:47.609348Z",
	"updated_at": "2026-04-10T03:21:38.869104Z",
	"deleted_at": null,
	"sha1_hash": "969804e5f27afc5e5565361662b04ac7a4b58be5",
	"title": "Microsoft Security Advisory 2269637 Released",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 37725,
	"plain_text": "Microsoft Security Advisory 2269637 Released\r\nBy MSRC\r\nPublished: 2010-08-21 · Archived: 2026-04-05 20:28:08 UTC\r\nToday we released MicrosoftSecurity Advisory 2269637. This is different from other Microsoft Security\r\nAdvisories because it’s not talking about specific vulnerabilities in Microsoft products. Rather, this is our official\r\nguidance in response to security research that has outlined a new, remote vector for a well-known class of\r\nvulnerabilities, known as DLL preloading or “binary planting” attacks. We are currently conducting a thorough\r\ninvestigation into how this new vector may affect Microsoft products. As always, if we find this issue affects any\r\nof our products, we will address them appropriately.\r\nAdditionally, today we are providing a defense-in-depth update that customers can deploy that will help protect\r\nagainst attempts to exploit vulnerable applications through this newly identified vector. Finally, we are using our\r\nstrong connections with researchers and partners in the industry to help address this new class of vulnerability.\r\nOur Microsoft Vulnerability Research program has been working to coordinate communication between the\r\nresearcher who first brought this new vector to us and other application developers who are affected by this issue.\r\nWhat this new research demonstrates is a new remote vector for DLL preloading attacks. These attacks are not\r\nnew or unique to the Windows platform. For instance, PATH attacks that are similar to this issue constitute some\r\nof the earliest class of attacks against the UNIX operating system. The attack focuses on tricking an application\r\ninto loading a malicious library when it thinks it’s loading a trusted library. For this to succeed, the application has\r\nto call the trusted library by name instead of properly using its full path (for example, calling dllname.dll rather\r\nthan C:\\Program Files\\Common Files\\Contoso\\dllname.dll). The attacker then has to place a malicious copy of the\r\nlibrary in a directory that the system will search to locate the library and have that be a directory it will search\r\nbefore the directory where the trusted library actually is. For example, if an attacker knows that the application\r\nsimply calls for dllname.dll (rather than using the full path) and it will look for dllname.dll in the current working\r\ndirectory before looking in C:\\Program Files\\Common Files\\Contoso\\. Then if the attacker can plant a malicious\r\ncopy of dllname.dll in the current working directory, the application will load it first executing the attacker’s code\r\nin the application’s security context.\r\nPATH or DLL preloading attacks have so far required the attacker to plant the malicious library on the local client\r\nsystem. This new research outlines a way an attacker could levy these attacks by planting the malicious library on\r\na network share. In this scenario, the attacker would create a data file that the vulnerable application would open,\r\ncreate a malicious library that the vulnerable application would use, post both of them on a network share that the\r\nuser could access, and convince the user to open the data file. At that point, the application would load the\r\nmalicious library and the attacker’s code would execute on the user’s system.\r\nBecause this is a new vector, rather than a new class of vulnerability, the existing best practices that protect against\r\nthis class of vulnerability, automatically protect against this new vector: ensuring that applications make calls to\r\ntrusted libraries using full path names.\r\nhttps://msrc-blog.microsoft.com/2010/08/21/microsoft-security-advisory-2269637-released/\r\nPage 1 of 2\n\nWhile the best protection is following best practices, we are able to provide an additional layer of defense by\r\noffering a tool that can be configured to disable the loading of libraries from network shares. In particular, because\r\nthis is altering functionality, we encourage customers to evaluate this tool before deploying it. As part of your\r\nevaluation, we encourage you to review the information at the Security Research and Defense (SRD) blog.\r\nWe will continue our work with the researchers and the industry to identify and address vulnerable applications.\r\nAnd as always, we will update you with any new information we have through our security advisories, security\r\nbulletins and the MSRC weblog as appropriate.\r\nAdvisory\r\nSecurity\r\nVulnerability\r\nSource: https://msrc-blog.microsoft.com/2010/08/21/microsoft-security-advisory-2269637-released/\r\nhttps://msrc-blog.microsoft.com/2010/08/21/microsoft-security-advisory-2269637-released/\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://msrc-blog.microsoft.com/2010/08/21/microsoft-security-advisory-2269637-released/"
	],
	"report_names": [
		"microsoft-security-advisory-2269637-released"
	],
	"threat_actors": [],
	"ts_created_at": 1775434127,
	"ts_updated_at": 1775791298,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/969804e5f27afc5e5565361662b04ac7a4b58be5.pdf",
		"text": "https://archive.orkl.eu/969804e5f27afc5e5565361662b04ac7a4b58be5.txt",
		"img": "https://archive.orkl.eu/969804e5f27afc5e5565361662b04ac7a4b58be5.jpg"
	}
}