CVE-2021-21224

What it actually does

This is a V8 JavaScript engine type-confusion memory corruption flaw in Google Chrome prior to 90.0.4430.85. A remote, unauthenticated attacker can cause V8 to treat an object as the wrong internal type through crafted JavaScript/HTML, corrupt memory, and execute attacker-controlled code in the Chrome renderer process. The documented execution context is inside the browser sandbox; full device compromise typically requires chaining with a separate sandbox escape or privilege-escalation vulnerability. The impact is high for confidentiality, integrity, and availability because successful exploitation can enable code execution, browser data access within the compromised context, and crash or takeover of the renderer process.

Why it matters to the business

The primary business risk is endpoint compromise through normal web browsing or links delivered by email, chat, ads, or compromised websites. Because this vulnerability is in CISA KEV, has known in-the-wild exploitation, and has a high EPSS score of 0.5624, it should be treated as an urgent legacy exposure even though the CISA remediation deadline of 2021-11-17 has long passed. Organizations with unmanaged browsers, embedded Chromium/V8 components, kiosk systems, or applications bundling affected browser engines may remain exposed. Consequences can include theft of browser-accessible data, session hijacking, malware staging, follow-on exploitation, and operational disruption if attackers chain this with other endpoint vulnerabilities.

How an attack unfolds

An attacker prepares a malicious web page containing JavaScript that triggers the V8 type-confusion condition. The attacker then drives a victim to the page through phishing, malvertising, watering-hole compromise, redirects, or links in documents and messages. When the vulnerable Chrome/V8 engine parses and executes the crafted page, memory corruption occurs and the attacker obtains code execution in the renderer sandbox. From there, the attacker may attempt to read data available to the renderer, manipulate page content, steal tokens or session material exposed to the browser context, or chain a second exploit to escape the sandbox and execute code on the underlying operating system. The vulnerability is cataloged as exploited in the wild, so incident responders should assume commodity or campaign-level exploitation may have occurred where vulnerable browser versions remained in use.

How to fix it

Upgrade Google Chrome and Chromium-based browsers to 90.0.4430.85 or later, preferably to the latest stable release available from the vendor. Ensure automatic browser updates are enabled and verify that all managed, unmanaged, kiosk, VDI, and server-side browsing components are covered. For applications bundling Chromium, V8, Electron, or headless browser components, update the embedded runtime rather than only the system browser. For the provided affected packages, update org.craftercms/crafter-studio to fixed versions 3.0.27 or 3.1.7 as applicable, and update craftercms/studio source deployments to include fixed commits cc163905c639e30c4ab56f1cecd9bd166752aa08 or 6faabd241818a48ec47ac3c8fd4139fe7683c0b2 as appropriate for the maintained branch. If immediate patching is not possible, reduce exposure by disabling or restricting untrusted browsing on affected systems, enforcing site isolation and browser sandboxing, blocking known malicious domains through web security controls, and isolating high-risk browsing in remote browser isolation or hardened virtual environments.

How to confirm the fix worked

Confirm browser versions through endpoint management, software inventory, EDR telemetry, or direct version checks and verify Chrome/Chromium is at 90.0.4430.85 or later. Validate that embedded Chromium/V8 runtimes used by desktop applications, content management workflows, automation tools, and headless browser services have also been updated. For CrafterCMS deployments, confirm org.craftercms/crafter-studio is 3.0.27, 3.1.7, or later on the relevant branch, or confirm source builds include fixed commits cc163905c639e30c4ab56f1cecd9bd166752aa08 or 6faabd241818a48ec47ac3c8fd4139fe7683c0b2. Re-scan software composition manifests, container images, endpoint software inventories, and CI/CD dependency outputs for vulnerable versions. Where possible, use browser management reporting to confirm update policy enforcement and check for endpoints that have not restarted since receiving the patched browser.

Typical attack path

1. Attacker identifies users or systems likely running Chrome prior to 90.0.4430.85 or software embedding a vulnerable Chromium/V8 engine.
2. Attacker hosts or injects a crafted HTML/JavaScript payload on a website, ad network, redirector, or compromised page.
3. Victim is lured to the malicious content through phishing, messaging, malvertising, watering-hole browsing, or embedded links.
4. The vulnerable V8 engine processes the crafted JavaScript and triggers type confusion memory corruption.
5. Attacker gains arbitrary code execution inside the Chrome renderer sandbox.
6. Attacker attempts browser-context data theft, persistence through additional payloads, or chains a sandbox escape/local privilege escalation for broader host compromise.
7. Attacker conducts follow-on activity such as credential theft, command-and-control, lateral movement, or data exfiltration if additional access is achieved.

How to detect it

There are no reliable public exploit-specific strings for this V8 type-confusion vulnerability, so detection should focus on behavioral and forensic evidence around vulnerable browser use. Review EDR and operating system telemetry for Chrome or Chromium renderer crashes followed by unusual child processes, file writes, downloads, persistence creation, credential access, or outbound network connections. Check browser history, proxy, DNS, secure web gateway, and firewall logs for visits to newly registered, low-reputation, redirect-heavy, or compromised domains shortly before suspicious endpoint behavior. Examine Chrome crash reports, minidumps, and application event logs for repeated renderer crashes around the time of suspicious browsing. In Windows environments, look for chrome.exe or chromium-based application processes spawning cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, bitsadmin.exe, or other LOLBin activity. On macOS and Linux, look for browser processes spawning shells, curl/wget, osascript, Python, Perl, or persistence mechanisms. Correlate detections with software inventory showing Chrome prior to 90.0.4430.85 or embedded vulnerable Chromium/V8 runtimes. Because exploitation may be chained with a sandbox escape, also hunt for subsequent privilege escalation, new persistence, credential dumping, and command-and-control from the same endpoint.

• chrome.exe spawning cmd.exe
• chrome.exe spawning powershell.exe
• chrome.exe spawning wscript.exe
• chrome.exe spawning cscript.exe
• chrome.exe spawning mshta.exe
• chrome.exe spawning rundll32.exe
• chrome.exe spawning regsvr32.exe
• chrome.exe spawning certutil.exe
• chrome.exe spawning bitsadmin.exe
• chrome.exe spawning curl.exe
• chrome.exe spawning wget.exe
• chromium.exe spawning cmd.exe
• chromium.exe spawning powershell.exe
• Google Chrome Helper spawning /bin/sh
• Google Chrome Helper spawning /bin/bash
• Google Chrome Helper spawning osascript
• Chrome version 90.0.4430.84
• Chrome version 90.0.4430.72
• Chrome version 89.
• Google Chrome prior to 90.0.4430.85

What your security team should do

• Prioritize remediation of any remaining Chrome, Chromium, embedded V8, Electron, or headless browser instances older than Chrome 90.0.4430.85 because this is a KEV-listed vulnerability with active exploitation history.
• Hunt for historical exploitation on endpoints that ran vulnerable versions after public disclosure, focusing on browser crashes, suspicious child processes, unexpected downloads, and post-browser execution activity.
• Inventory applications that bundle their own browser engines; do not assume patching the operating system browser fixes embedded Chromium/V8 copies.
• Update CrafterCMS-related packages to org.craftercms/crafter-studio 3.0.27 or 3.1.7, or include the fixed source commits cc163905c639e30c4ab56f1cecd9bd166752aa08 or 6faabd241818a48ec47ac3c8fd4139fe7683c0b2 where those packages are in use.
• Enforce managed browser auto-update policies and monitor for devices that fail to update or restart.
• Use EDR controls to alert on browser processes spawning command shells, scripting interpreters, archive utilities, or network tools.
• Apply web filtering, DNS security, and remote browser isolation for high-risk users and unmanaged browsing paths.
• If suspicious activity is found, preserve browser history, crash dumps, EDR process trees, downloaded files, and network logs before remediation removes evidence.