Chrome is the most widely deployed application in the enterprise, running on nearly every endpoint, in front of nearly every web application, handling nearly every credential your workforce enters. That reach is exactly why a Chrome vulnerability is not a routine patch item. It is a window during which attackers can reach almost everyone in your organization through software you cannot simply turn off.
The uncomfortable part is timing, though not in the way most teams assume. Google ships Chrome fixes quickly, and Chrome is among the fastest major browsers to land a patch once a flaw is reported. The delay is on your side of the wire, in the stretch between a fix being available and that fix reaching every endpoint you are responsible for. This post explains why that gap exists, why patching alone cannot close it, and where the durable fix actually lives.
A Chrome zero-day is a flaw in the browser that attackers are exploiting before Google has released a fix, meaning defenders have had no opportunity to deploy a patch. A Chrome zero-day can let a malicious page execute code, escape the browser's sandbox, or steal session data. Attackers often chain multiple zero-days to compromise fully patched, well-managed devices.
A Chrome one-day vulnerability is a flaw that is exploited shortly after Google has released a fix. Zero-day vulnerabilities become one-day vulnerabilities once a patch is available, and attackers are also increasingly adept at reverse engineering patches to quickly generate exploits that target responsibly-disclosed vulnerabilities.
These are not rare edge cases. Google has repeatedly issued emergency Chrome updates for vulnerabilities already under active attack, and browser sandbox escapes have become a favored target because the browser sits at the exact point where users meet the untrusted web. CVE-2025-2783 is a recent example, a Chrome sandbox escape that Kaspersky identified being used in live, targeted attacks (Kaspersky Securelist, 2025).
Patching is not enough because a fix being available is not the same as a fix being deployed, and attackers operate deliberately inside that difference. Even organizations with mature patch management do not push a browser update to their entire fleet the instant it ships. Testing, staged rollout, and roaming or unmanaged devices all stretch the timeline.
The scale of that lag is measurable, and it is getting worse rather than better.
The median time organizations took to fully remediate a vulnerability already confirmed to be exploited in the wild, up from 32 days the year prior. Only 26% of such vulnerabilities were fully remediated at all. Source: Verizon Data Breach Investigations Report, 2026
During that window, every unpatched instance of Chrome is a live target. And the damage in a modern browser exploit happens fast. A sandbox escape can put an attacker in a position to reach credentials or session data held in browser memory, well before the slower work of establishing persistence on the device begins.
Endpoint and network tools miss Chrome exploits because no signature exists for the attack yet, and because the activity may never produce the disk or process artifacts those tools are built to inspect.
| Security Control | What It Is Built to Catch | Why a Chrome Zero-Day Slips Past |
|---|---|---|
| Patch Management | Known vulnerabilities, once a fix exists and is deployed | A zero-day is exploited before a patch exists, and fleet-wide rollout lags the fix by weeks |
| Endpoint Detection (EDR) | Malicious file writes and suspicious process behavior on the device | Exploitation can occur in memory, generating little or nothing for the endpoint tool to flag |
| Secure Web Gateway and URL Filtering | Known-malicious domains and reputation signals | Exploit pages are served from clean or newly registered domains, and classification lags the attack window |
| Network Inspection | Threats visible in traffic based on known exploit signatures | A zero-day has no signature yet, and attackers mutate payloads specifically to evade signature-based detection |
The through-line is that Chrome exploits cannot be caught by signature-based or reputation-based approaches, because both depend on prior knowledge of an attack that is, by construction, new.
You protect against Chrome zero-days by moving the execution of untrusted web content off the endpoint entirely, so that the impact of an exploit is limited to a disposable cloud container. This is the structural answer to the patch gap. If the vulnerable rendering never happens on the user's device, the timing race between a fix shipping and a fix landing stops mattering.
Cloud isolation does exactly this. With Menlo Threat Prevention, web content, DOM rendering, JavaScript, and CSS execute in a remote container in the Menlo Cloud and do not reach the user's browser. When a Chrome vulnerability is triggered by a malicious page, it detonates in the cloud, not on your endpoint, in an environment holding no credentials and no session data. The exposure window still exists, but it stops being a path to anything worth reaching.
Two properties make this approach preventive rather than reactive:
This is prevention at the browser layer, ahead of the patch cycle rather than chasing it. It is the browser-first defense model that Menlo advocates across the full attack chain, and it is why browser security is no longer an optional layer on top of the stack. It is the layer where the exploit actually lands.
How often does Chrome have zero-day vulnerabilities? Google issues security updates for Chrome frequently, and a meaningful share addresses vulnerabilities already being exploited in the wild. The exact count varies year to year, but emergency out-of-band Chrome updates for actively exploited flaws have become a regular occurrence rather than an exception. Google's Project Zero maintains a public tracker of zero-days exploited in the wild.
If I patch Chrome quickly, am I safe from zero-days? Fast patching reduces exposure but cannot eliminate it. A zero-day is exploited before a patch exists, and even after a fix ships, fleet-wide rollout takes time. The median organization takes weeks to fully remediate a vulnerability already known to be under active exploitation, so patching is necessary but not sufficient on its own.
Does EDR protect against Chrome exploits? Often not in time. In modern browser-based attacks, particularly sandbox escapes, an attacker can reach credentials and session tokens inside browser memory before generating the disk or process activity endpoint tools are built to detect. EDR is also fundamentally reactive, and sophisticated attackers mutate their tooling specifically to evade it.
What actually closes the Chrome zero-day patch gap? Removing the target. When untrusted web content executes in a remote cloud container before it reaches the endpoint, an exploit, even an unknown one, detonates in the cloud rather than on the device. The window between a vulnerability being exploited and a patch being deployed stops mattering, because there is nothing on the endpoint for the exploit to reach.
About the Author
Lionel Litty is the CISO at Menlo Security, where he has been working on reducing the browser attack surface for the past 12 years. He holds multiple patents in the Cyber Security space and has previously spoken at conferences such as Usenix Security. He holds a PhD in Computer Systems from the University of Toronto.
Menlo Security
