HowToFixMe
● High · CVSS 8.8 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2017-5070: Access of Resource Using Incompatible Type ('Type Confusion')

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 8.8 - High
Actively exploited?Yes, listed in CISA KEV (added 2022-06-08)
AffectedGoogle Chrome before 59.0.3071.86 (Linux, Windows, macOS) and before 59.0.3071.92 (Android). Root cause is in the bundled V8 JavaScript engine.
Fixed inChrome 59.0.3071.86 (Linux, Windows, macOS); Chrome 59.0.3071.92 (Android)
Type (CWE)CWE-843 Access of Resource Using Incompatible Type ('Type Confusion')

Exploitation status

CVE-2017-5070 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Google Chromium V8 Type Confusion Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: although a public exploit is not directly linked in this CVE’s primary references, its place on the CISA KEV catalog confirms working attack code is in active use in the wild, treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2022-06-08, federal due date 2022-06-22.

What is CVE-2017-5070?

CVE-2017-5070 is a type confusion flaw (CWE-843, Access of Resource Using Incompatible Type) in V8, the JavaScript engine that Google Chrome bundles. Per the MITRE record, the bug affects Chrome before 59.0.3071.86 on Linux, Windows, and macOS, and before 59.0.3071.92 on Android. A remote attacker who can get a victim to load a crafted HTML page can execute arbitrary code inside Chrome's renderer sandbox. Google fixed it in the Chrome 59 stable channel release on 5 June 2017.

Type confusion happens when code allocates or receives an object as one type and later operates on it as an incompatible type. In a JIT-compiling JavaScript engine like V8, that mismatch lets a script read and write memory outside the bounds the engine expected, which an attacker turns into a controlled read/write primitive and ultimately arbitrary code execution. There is no user action beyond visiting a page: the malicious JavaScript runs automatically when the page loads. That is why the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — network reach, low complexity, no privileges, and only the single click of opening a link required, for a base score of 8.8 (High).

This is a browser remote-code-execution bug, not a server-daemon or operating-system flaw. There is no Linux kernel package, no Windows KB, and no system service to restart. The only component you patch is the browser itself.

Why this CVE matters

CISA added CVE-2017-5070 to the Known Exploited Vulnerabilities catalog on 8 June 2022, under the title “Google Chromium V8 Type Confusion Vulnerability.” A KEV listing means working attack code has been seen in the wild, and the CISA SSVC assessment for this entry records Exploitation as active with a total technical impact. Browser RCE bugs are prime drive-by and watering-hole material: an attacker only needs to lure a user to a page, or compromise an ad network or a legitimate site, and any unpatched Chrome that renders it can be taken over.

Because the V8 codebase is shared, the same flaw lived in other Chromium-based browsers built on pre-59 Chromium until they merged the fix. The bug runs inside the renderer sandbox, which contains the initial code execution, but type-confusion primitives are routinely paired with a separate sandbox-escape bug to reach the host. Treat any Chrome older than 59.0.3071.86 (or 59.0.3071.92 on Android) as exploitable.

Am I affected?

Check the installed Chrome version. Open chrome://version in the address bar, or read it from the command line. If the build is below 59.0.3071.86 on desktop, or below 59.0.3071.92 on Android, you are running the vulnerable V8.

# Linux: query the installed Chrome build
google-chrome --version
google-chrome-stable --version
dpkg -s google-chrome-stable 2>/dev/null | grep -i '^Version'   # Debian / Ubuntu
rpm -q google-chrome-stable 2>/dev/null                         # RHEL / Fedora

# Windows: read the Chrome version from the installed binary
(Get-Item "$env:ProgramFiles\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion
(Get-Item "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion
# Per-user install:
(Get-Item "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

Any value such as 58.x or an earlier 59.0.3071 build below .86 is affected. 59.0.3071.86 and later (desktop) or 59.0.3071.92 and later (Android) carry the fix.

How to fix CVE-2017-5070

The fix is to update Chrome to 59.0.3071.86 (Linux, Windows, macOS) or 59.0.3071.92 (Android), or any later release, then relaunch the browser so the patched binary is actually running. Chrome auto-updates by default, but the update only takes effect after a restart, and managed or offline machines often have auto-update disabled.

Fastest path (any desktop platform)

  1. Open chrome://settings/help. Chrome checks for an update and downloads it automatically.
  2. When it shows “Nearly up to date,” click Relaunch. The update does not apply until Chrome restarts every window.
  3. Reopen chrome://version and confirm the version is 59.0.3071.86 or higher.

Windows

# Chrome ships its own updater (Google Update / GoogleUpdate.exe).
# Force an update check, then relaunch Chrome.
$gu = "$env:ProgramFiles\Google\Update\GoogleUpdate.exe"
if (-not (Test-Path $gu)) { $gu = "${env:ProgramFiles(x86)}\Google\Update\GoogleUpdate.exe" }
Start-Process $gu -ArgumentList '/ua /installsource scheduler' -Wait

# Verify the on-disk binary is patched
(Get-Item "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

If you deploy Chrome with an MSI (the enterprise bundle), push the current Chrome Enterprise MSI from your software-distribution tool instead; it replaces the application binaries with the patched build.

macOS

# Trigger Google Software Update for Chrome, then relaunch
"/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent" -runMode oneshot

# Confirm the installed version
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version

Linux (Debian/Ubuntu and RHEL/Fedora)

On Linux, Chrome is installed from Google's own apt/yum repository, so a normal package update pulls the patched build. Update the google-chrome-stable package — not any system or kernel package — then restart the browser.

# Debian / Ubuntu
sudo apt-get update
sudo apt-get install --only-upgrade google-chrome-stable
google-chrome-stable --version    # expect 59.0.3071.86 or later

# RHEL / Fedora / Rocky
sudo dnf upgrade --refresh google-chrome-stable
rpm -q google-chrome-stable

If your distribution ships Chromium rather than Google Chrome, update the chromium (or chromium-browser) package to a build whose Chromium base is 59.0.3071 or later; Red Hat and Gentoo issued advisories (RHSA-2017:1399, GLSA-201706-20) for their Chromium packages covering this V8 fix.

Android

Open the Google Play Store, search for Chrome, and tap Update until it reads Open. The patched mobile build is 59.0.3071.92. Confirm by opening chrome://version in the mobile browser.

Container or kiosk images

# Any image that bundles Chrome / Chromium for headless rendering or kiosk use
# must be rebuilt from a base that ships the patched browser.
docker pull <your-registry>/chrome-base:<patched-tag>   # Chrome >= 59.0.3071.86
docker build -t <your-app>:patched .
docker stop <your-app> && docker rm <your-app>
docker run -d --name <your-app> <your-app>:patched

Updating Chrome across an enterprise fleet

For managed estates, do not rely on each user clicking Relaunch. Enforce the minimum version through Chrome Enterprise policy.

If you can't update immediately

Updating Chrome is the only real fix; there is no registry toggle or feature flag that removes this V8 bug. Until the patched build is deployed, reduce the chance of a crafted page reaching the vulnerable browser:

How to verify the fix worked

Confirm the running browser, not just the installed package, is on a fixed build. The update only counts once every Chrome window has been relaunched.

# Linux / macOS
google-chrome-stable --version       # Linux, expect >= 59.0.3071.86
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version   # macOS

# Windows: on-disk binary version
(Get-Item "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

In the browser itself, load chrome://version and read the Google Chrome line; it must show 59.0.3071.86 or later on desktop, or 59.0.3071.92 or later on Android. For a managed fleet, run an authenticated vulnerability scan and confirm the scanner no longer reports CVE-2017-5070 against any host.

Frequently asked questions

Which Chrome version fixes CVE-2017-5070?

Chrome 59.0.3071.86 on Linux, Windows, and macOS, and Chrome 59.0.3071.92 on Android. Any build older than those carries the vulnerable V8 engine. Open chrome://settings/help to update, then relaunch the browser so the new binary loads.

Does the V8 sandbox stop CVE-2017-5070?

No. The MITRE description states the attacker executes arbitrary code inside the renderer sandbox. The sandbox limits the blast radius compared with a full system compromise, but it does not block this bug, and type-confusion primitives like this are routinely chained with a sandbox-escape bug. Update to 59.0.3071.86 or later instead of relying on the sandbox.

How do I update Chrome across an enterprise fleet?

Push the target version through Google Chrome Enterprise policy (TargetVersionPrefix and the auto-update settings via group policy ADMX or the Google Admin console), or rebuild any container or VM image that bundles Chrome from a patched base. Confirm with chrome://version on a sample of endpoints.

Are Chromium-based browsers like Edge, Brave, or Opera affected?

Any browser built on the pre-59 Chromium/V8 codebase inherited the same type-confusion bug until it picked up the fix. Update each Chromium-based browser to a build that ships V8 from Chromium 59.0.3071 or later, using that browser's own update channel.

References

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Additional nearby issues sensible to fix in the same maintenance window:

People also ask

Which Chrome version fixes CVE-2017-5070?

Chrome 59.0.3071.86 on Linux, Windows, and macOS, and Chrome 59.0.3071.92 on Android. Any build older than those carries the vulnerable V8 engine. Open chrome://settings/help to update, then relaunch the browser so the new binary loads.

Does the V8 sandbox stop CVE-2017-5070?

No. The MITRE description states the attacker executes arbitrary code inside the renderer sandbox. The sandbox limits the blast radius compared with a full system compromise, but it does not block this bug, and type-confusion primitives like this are routinely chained with a sandbox-escape bug. Update to 59.0.3071.86 or later instead of relying on the sandbox.

Are Chromium-based browsers like Edge, Brave, or Opera affected?

Any browser built on the pre-59 Chromium/V8 codebase inherited the same type-confusion bug until it picked up the fix. Update each Chromium-based browser to a build that ships V8 from Chromium 59.0.3071 or later, using that browser's own update channel.