Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
3 events from the most recent confirmed update back to the earliest known activity.
A GitHub repository from theori-io published a proof-of-concept exploit for CVE-2016-0189 targeting IE11 on Windows 10. The repository included exploit files and usage instructions, while noting the exploit was not fully reliable.
Microsoft's MS16-051 update patched CVE-2016-0189, a VBScript engine memory corruption vulnerability in Internet Explorer that had been used in targeted attacks in South Korea. The patch addressed issues in vbscript.dll that enabled out-of-bounds read/write and bypassed VBScript safety checks.
Theori published a technical analysis reconstructing exploitation of CVE-2016-0189 and explaining how two patched flaws could be chained to achieve arbitrary memory read/write and unsafe script execution in IE11 on Windows 10. The write-up also noted that Internet Explorer Protected Mode still constrained direct process execution.
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 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.
Jul 24, 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
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