CVE-2026-3910

What it actually does

This vulnerability is a remote code execution flaw in Chrome’s V8 JavaScript engine caused by an inappropriate implementation that can be triggered through malicious web content. A remote attacker can craft an HTML page that causes V8 to execute attacker-controlled code within the Chrome renderer sandbox. Because the CVSS vector requires user interaction, exploitation generally depends on a user visiting a malicious or compromised web page, opening a malicious link, or being redirected to exploit content. The vulnerability provides high confidentiality, integrity, and availability impact within the browser sandbox; full host compromise may require chaining with a separate sandbox escape or privilege escalation vulnerability.

Why it matters to the business

Successful exploitation can allow attackers to run code through the browser, steal data accessible to the browser session, hijack authenticated web sessions, deliver malware, or establish an initial foothold for broader compromise. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and has a remediation due date of 2026-03-27, organizations should treat unpatched Chrome installations as a priority exposure even though the EPSS score is currently low. The broad use of Chrome across Windows, macOS, and Linux increases operational risk because a single vulnerable browser version can expose many users to drive-by or phishing-based compromise.

How an attack unfolds

An attacker prepares a specially crafted HTML page containing JavaScript designed to trigger the V8 implementation flaw. The attacker then lures a target to the page through phishing, malicious advertising, search poisoning, watering-hole compromise, or a link in messaging platforms. When the vulnerable Chrome browser processes the page, the flaw can corrupt execution state in a way that allows attacker-controlled code to run inside the Chrome sandbox. From there, the attacker may attempt to steal browser-accessible data, abuse active sessions, stage a payload, or chain the bug with another vulnerability to escape the sandbox and gain deeper access to the operating system. Public reporting indicates active exploitation and association with an Interlock ransomware campaign context, so defenders should assume exploitation may be used for initial access or payload staging rather than only proof-of-concept activity.

How to fix it

Upgrade Google Chrome to version 146.0.7680.75 or later on all supported platforms. Where enterprise browser management is used, force an immediate update and restart of Chrome, because browser updates are not fully applied until the browser process restarts. Remove or isolate systems that cannot be updated before the KEV due date. Apply the same urgency to Chromium-based browsers if vendor advisories identify inherited exposure from the affected V8 codebase. As mitigations until patching is complete, restrict access to untrusted sites, increase web isolation for high-risk users, disable or limit JavaScript only where operationally feasible, use browser isolation for risky browsing, and reduce exposure to malvertising and phishing through DNS, proxy, and email controls. Mitigations should not be considered a substitute for updating.

How to confirm the fix worked

Confirm that every managed Chrome installation reports version 146.0.7680.75 or later and that the browser has been restarted after the update. Validate through enterprise browser management, endpoint inventory, software asset management, EDR software inventory, or command-line version checks. On Windows, verify the installed Chrome version from application inventory or the Chrome executable properties; on macOS and Linux, verify package or application version through the relevant management tooling. Also confirm auto-update is enabled and functioning, update deferrals are not preventing deployment, and unsupported Chrome channels or unmanaged Chromium builds are not present. Exposure remains if any actively used browser is older than 146.0.7680.75.

Typical attack path

1. Attacker identifies users likely to run vulnerable Chrome versions prior to 146.0.7680.75.
2. Attacker hosts or injects a crafted HTML/JavaScript exploit page on attacker-controlled or compromised infrastructure.
3. Attacker delivers the URL through phishing, malvertising, redirects, compromised websites, or messaging lures.
4. A user opens the page in a vulnerable Chrome browser.
5. The V8 flaw is triggered and attacker-controlled code executes inside the Chrome renderer sandbox.
6. Attacker performs browser-context actions such as session theft, payload staging, reconnaissance, or credential access attempts.
7. If available, attacker chains a sandbox escape or local privilege escalation to execute code outside the browser sandbox.
8. Attacker establishes persistence, moves laterally, or deploys follow-on malware or ransomware tooling.

How to detect it

To assess possible prior exploitation, review endpoint detection telemetry, browser crash reports, web proxy logs, DNS logs, email security logs, and EDR process events for the period before patch deployment. Focus on users running Chrome versions earlier than 146.0.7680.75 who visited suspicious or newly observed web pages, especially pages reached through phishing, malvertising, redirects, or compromised legitimate sites. Look for Chrome renderer crashes followed by unusual activity, such as Chrome spawning command interpreters, script engines, archive tools, installers, or unsigned binaries. Investigate unexpected downloads initiated by Chrome, files written to user download or temporary directories immediately after browsing activity, credential or cookie access attempts, and outbound connections from newly created processes shortly after a Chrome crash. Because this vulnerability executes inside the browser sandbox, there may be no reliable exploit-specific artifact unless the attacker used a known payload or follow-on tool. If Interlock ransomware-related activity is suspected, correlate browser exploitation timelines with ransomware intrusion indicators such as unusual remote access tool installation, credential dumping, lateral movement, backup tampering, and encryption staging.

What your security team should do

• Immediately inventory Chrome versions across Windows, macOS, and Linux endpoints and prioritize any version older than 146.0.7680.75.
• Force Chrome updates and browser restarts through enterprise management; treat non-restarting browsers as still exposed.
• Prioritize remediation before the CISA KEV due date of 2026-03-27 and escalate exceptions for systems that cannot be updated.
• Hunt for suspicious browser crashes, renderer crashes, unusual child processes spawned from Chrome, and browser-initiated downloads or script execution around suspected exposure windows.
• Review web proxy, DNS, EDR, and email telemetry for users who visited newly registered, low-reputation, compromised, or suspicious redirect-heavy sites before patching.
• Apply enhanced monitoring to users with elevated access or high-value business roles, because browser RCE is commonly used for initial access.
• Use browser isolation, hardened web filtering, and ad-blocking controls for high-risk groups until patch coverage is complete.
• Check Chromium-based browser advisories and update policies, not only Google Chrome, where those browsers are deployed.