Loading story…
Researchers disclosed a technique that bypassed Microsoft’s Control Flow Guard (CFG) in Internet Explorer and Edge by abusing the Chakra JavaScript engine’s JIT compilation process. The method assumed an attacker already had a read-write memory primitive, then located Chakra’s temporary JIT native-code buffer, altered the generated code before it was copied into executable memory, and executed the modified result without directly violating CFG’s indirect-call protections.
Microsoft’s CFG is designed to restrict calls to valid control-flow targets in Win32 applications, but the reported bypass showed that JIT-generated code could be tampered with before finalization and still become an approved execution target. The technique was reported through Microsoft’s mitigation bypass bounty program, demonstrated against Internet Explorer 11 on Windows 10, and later addressed in MS16-119 and ChakraCore updates that added checksum validation before marking JIT entry points as valid CFG targets.
Get the actors, campaigns, and ATT&CK mapping behind it.
3 events from the most recent confirmed update back to the earliest known activity.
Microsoft later fixed the reported Chakra JIT Control Flow Guard bypass in security update MS16-119. ChakraCore was also changed to add checksum validation before marking JIT entry points as valid CFG targets.
Theori reported a technique for bypassing Microsoft Control Flow Guard in Internet Explorer and Edge through Microsoft's mitigation bypass bounty program. The bypass abused Chakra's temporary JIT encode buffer to alter native code before it was finalized as an executable CFG target.
Theori publicly disclosed technical details of the Chakra JIT CFG bypass and said it had demonstrated the technique against Internet Explorer 11 on Windows 10 using an adapted proof-of-concept exploit. The blog post explained how an attacker with a read-write memory primitive could tamper with JIT-generated code before it was copied into executable memory.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
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.
Microsoft Edge's Internet Explorer (IE) Mode was exploited by a mysterious threat actor who leveraged a zero-day vulnerability in the legacy Chakra JavaScript engine to gain unauthorized access to user devices. The attacks, which began at least as early as August 2025, involved social engineering tactics where users were tricked into reloading seemingly legitimate websites in IE Mode. This mode, designed to provide backward compatibility for older web applications, runs web pages using the outdated Internet Explorer engine within Edge. Attackers created clones of legitimate sites and used on-page prompts to convince users to activate IE Mode, thereby exposing them to the vulnerable Chakra engine. The exploit chain consisted of a zero-day vulnerability that enabled remote code execution, followed by a privilege escalation exploit that allowed attackers to take full control of the affected system. Microsoft did not release a CVE or a specific patch for the vulnerabilities but instead responded by overhauling the IE Mode feature. The company removed all dedicated buttons, context menu options, and menu items that allowed easy access to IE Mode, making it significantly harder for users to inadvertently activate the feature. Now, users must manually enable IE Mode through the browser's settings, adding a layer of friction and reducing the attack surface. The attacks were particularly concerning because they bypassed modern security protections in Chromium-based Edge by reverting to the less secure Internet Explorer environment. Microsoft has not disclosed the identity of the threat actor, the full scope of the attacks, or the technical details of the exploited vulnerabilities. The company’s response underscores the ongoing risks associated with maintaining legacy compatibility features in modern browsers. Security experts have highlighted that such backward compatibility can inadvertently introduce significant vulnerabilities, especially when legacy code is no longer actively maintained. The incident demonstrates the importance of minimizing legacy feature exposure and the need for organizations to review their reliance on outdated web technologies. Microsoft’s swift action to restrict access to IE Mode is intended to prevent further exploitation while a more permanent solution is considered. The event has raised awareness among enterprise users and IT administrators about the dangers of enabling legacy browser modes. Organizations are advised to audit their use of IE Mode and consider alternatives to legacy web applications. The attack chain also illustrates the effectiveness of combining social engineering with technical exploits to compromise even modern browser environments. This incident serves as a cautionary tale for software vendors about the security trade-offs involved in supporting legacy features.
Jun 29, 2026
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
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