ID AKB:F1FF517B-6FF7-4972-9CA6-6F009CD86E66
Type attackerkb
Reporter AttackerKB
Modified 2020-06-30T05:02:06


Type confusion in V8 in Google Chrome prior to 80.0.3987.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

Recent assessments:

tekwizz123 at 2020-03-09T02:14:27.296939Z reported: This is a decent vulnerability that was found by István Kurucsai and Vignesh S Rao of Exodus Intelligence and was detailed at Metasploit now has a fully working exploit for this vulnerability that grants RCE provided a user browses to an attacker controlled web page. However, as it stands the current module requires the sandbox to be disabled for its shellcode to work properly (see

Overall its likely that most people will be automatically updating this vulnerabilty, however I will note that it is theoretically possible to make this bug easier to exploit by targeting older versions of the Windows OS such as Windows 7 and prior whereby exploiting a win32k bug may allow the attacker to go from running inside the Chrome render process to running as SYSTEM within the context of the Windows kernel. This is something that has been done in the past (see for an example).

Note however that since newer versions of the Windows operating system introduced win32k system call filtering, which Chrome takes advantage of, unless an attacker has a vulnerability in some other core component accessible from the Chrome sandbox they wouldn't be able to exploit this vulnerability. Whilst vulns still do exist, the reduction in the attack surface (since win32k is a primary source of privilege elevation vulnerabilities) does make this particular vulnerability a lot harder to exploit on modern Windows systems, however it may pose a higher threat for those organizations who are still running legacy systems in their environment.

Overall not a bad bug but unless paired with a sandbox escape bug on an older system, chances are that most people will either be up to date, or running on a system that limits their attack surface. Main target will likely be those running legacy systems were software updates aren't as easily applied and/or as regular.

Assessed Attacker Value: 4 Assessed Exploitability: 3 J3rryBl4nks at 2020-03-04T16:42:19.907959Z reported: You would have to chain this vulnerability with a working sandbox escape in order to get full value. While there are no doubt working sandbox escapes, this is only one piece of the exploit chain that is necessary to get a reliable foothold on a machine.

Often times there are full chain exploits published which include the code exec, sandbox escape, and a valid privesc but I have been unable to find a full chain for this exploit.

For the average attacker, this hill would be too high to climb to make this useful.

Assessed Attacker Value: 4 Assessed Exploitability: 1 kevthehermit at 2020-03-04T16:01:25.8812Z reported: This is an RCE in the Chrome Javascript engine. There are Proof of Concepts that target both Linux and Windows environments.

The existing POCs are not chained with a Sandbox escape which makes successful exploitation just using the existing code impractical.

The Current CVE lists any version of Chrome below 80.0.3987.122 as vulnerable during testing the existing POC would not exploit on versions below 80. This is likely to do with the way the exploit is constructed to target the specific test environment rather than older versions not being vulnerable.

From an attacker perspective, if this exploit could be chained with a sandbox escape it could be very valuable for Watering Hole attacks.

Google Chromes automated update system should protect most users, however, Organisations with version pinned installations may be at a higher risk.

Resources: - -

Edited: To correct upper version number

Assessed Attacker Value: 5 Assessed Exploitability: 1