Loading story…
Researchers published a detailed analysis and proof-of-concept exploit for Microsoft bulletin MS16-063, showing how a flaw in Internet Explorer's jscript9.dll can be turned into code execution on Internet Explorer 11 running Windows 7. The vulnerability stems from improper handling of detached ArrayBuffer objects in TypedArray and DataView operations, creating a use-after-free condition when functions such as DirectGetItem, DirectSetItem, GetValue, and SetValue access freed backing memory after an ArrayBuffer is detached via postMessage.
The published research describes an exploitation path that converts the bug into arbitrary read/write primitives and then into shellcode execution through heap manipulation, a fake virtual function table, ROP, and VirtualProtect. A companion GitHub repository released a public HTML proof of concept that can be served over HTTP and opened in a vulnerable browser, although the authors noted it is not fully reliable. The researchers also reported that the demonstrated technique does not work on Windows 8.1 and later because Control Flow Guard blocks the indirect-call method used in the exploit.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
On 2016-06-27, Theori made a GitHub repository available for a proof-of-concept exploit targeting the jscript9.dll TypedArray/DataView memory corruption issue associated with MS16-063. The repository said the exploit was tested against Internet Explorer 11 on Windows 7 and provided basic reproduction steps.
On 2016-06-26, Theori published an analysis of Microsoft bulletin MS16-063 describing a use-after-free flaw in jscript9.dll involving detached ArrayBuffer handling in TypedArray and DataView operations. The write-up included a proof-of-concept and an Internet Explorer 11 on Windows 7 exploitation path using heap manipulation, a fake vtable, ROP, and VirtualProtect.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers published a detailed patch analysis and proof-of-concept exploit for **CVE-2016-0189**, a VBScript engine memory corruption flaw in **Internet Explorer 11** that had already been used in targeted attacks in South Korea. The analysis of Microsoft bulletin **MS16-051** found two patched issues in `vbscript.dll`: a missing `SafeArray` lock in the `AccessArray` function that can enable out-of-bounds read/write during array resizing, and an `IsUnsafeAllowed` logic flaw that bypasses VBScript safety checks. Chaining the bugs allows arbitrary memory read/write and modification of `COleScript` safety settings to enable unsafe script execution in IE11 on Windows 10. The accompanying GitHub repository released a public exploit for Windows 10 and IE11, lowering the barrier to reproducing the attack path. The researchers noted the exploit was not fully reliable and might require repeated page loads, but showed how the vulnerability could still be leveraged despite Internet Explorer Protected Mode. Their write-up also described using a localhost/Intranet trust-based technique, previously documented by Zero Day Initiative, to move from a Protected Mode context toward **Medium integrity** code execution.
Jul 24, 2026
Researchers detailed how **CVE-2019-1367**, a remote code execution flaw in Internet Explorer's legacy `jscript.dll`, was exploited in the wild through a use-after-free condition tied to improper garbage collection of JScript `VAR` structures. Analysis linked the bug to a broader recurring Internet Explorer JScript vulnerability class that also includes **`CVE-2018-8653`**, **`CVE-2019-1429`**, and **`CVE-2020-0674`**, with evidence that later flaws were variants or incomplete fixes of the same underlying issue. Google Project Zero later cited `CVE-2020-0674` as an example of an incompletely patched vulnerability and warned that several 2020 zero-days reused previously known bug classes and exploit techniques. Traffic and exploit-chain analysis tied successful `CVE-2019-1367` exploitation to the **Magnitude Exploit Kit**, which used a base64-encoded landing page, a second-stage script, and a `JScript.Encode` payload to force **IE8 compatibility mode** so the browser would load the vulnerable legacy engine instead of `jscript9.dll`. Reporting also connected earlier targeting to **North Korea-linked** activity and open-source reporting associated some exploitation with **DarkHotel APT**, while later campaigns targeted South Korean users and ultimately delivered ransomware. Microsoft patched the flaw and advised disabling `jscript.dll`, particularly in environments where legacy compatibility mode could still expose the vulnerable code path.
Aug 15, 2026
Microsoft released fixes for **CVE-2020-0674**, a memory corruption flaw in the Internet Explorer scripting engine that could let an attacker execute arbitrary code in the context of the current user. The company said the vulnerability had been **publicly disclosed and exploited in the wild**, and warned that systems where users hold administrative privileges could be fully compromised. Microsoft also published mitigations and a workaround that restricts access to `JScript.dll`, noting that **IE11, IE10, and IE9** typically use `Jscript9.dll`, which is not affected, and that exposure is tied to sites invoking the legacy JScript engine. Microsoft’s related guidance on **Internet Explorer Enhanced Security Configuration (IE ESC)** highlights defensive measures for Windows Server environments that reduce exposure to web-based attacks. IE ESC hardens browser security zones, restricts scripting, ActiveX, downloads, and third-party extensions, and reinforces Microsoft’s recommendation to minimize web browsing from servers and tightly control trusted and intranet site assignments. The guidance also warns that incorrectly adding Internet sites to the Local intranet zone can automatically send user credentials, increasing risk during browser-based exploitation attempts.
Aug 15, 2026