What happened
On October 13, 2026 (US time), XBOW, an autonomous offensive security company, published on its official blog how it built a Chrome full-chain exploit. In Korea, Digital Daily reported the news on October 14.
A full chain links several vulnerabilities to get past every protection layer of a browser. This chain started from a single web page and ran an arbitrary program outside the sandbox on a Windows endpoint. The key point is that the user did not need to download a file or click a link. Opening the page was enough.
| Item | Details |
|---|---|
| Announced | October 13, 2026 (US time), XBOW |
| Build time | August 2 to August 7, 2026, six days |
| Team | One XBOW researcher + AI agents running on a public OpenAI model |
| Cost | About $40,000 (API cost estimated by XBOW from its usage logs) |
| Reward | $250,000 full-chain reward from Google’s Chrome Vulnerability Reward Program (VRP) |
| Target | Chrome for Windows. XBOW estimates about 1 billion affected users |
| Current status | All three flaws fixed. No use in real attacks reported |
According to XBOW, this is the first Chrome full-chain reward under the VRP rules Google changed in April 2026. The Hacker News reported that $250,000 is the most Chrome’s VRP pays for a single report.
The three flaws in the chain and their fixed versions
Chrome confines web page code in two layers: the V8 sandbox inside the JavaScript engine, and the renderer sandbox, where the operating system limits the renderer process’s privileges. This chain crossed both boundaries using three flaws in different components.
| Stage | Component | Identifier | Classification | Fixed version (Windows) |
|---|---|---|---|---|
| 1 | V8 (JavaScript engine) | CVE-2026-85045 | High, code execution inside the sandbox (CVE description) | 152.0.7977.82/.83 (September 3) |
| 2 | Animated WebP image decoder | No CVE (Chromium issue 548509153) | Bypass of the V8 sandbox boundary (per XBOW) | Not listed separately in release notes |
| 3 | Crashpad (Chrome’s crash handler) | CVE-2026-78952 | High, code execution outside the sandbox (Windows, CVE description) | 152.0.7977.64/.65 (August 25) |
Two points need care when reading the sources.
- CVE numbering differences: XBOW’s announcement and some reports citing it attributed CVE-2026-85045 to the WebP stage. Google’s September 3 release notes and the official CVE record assign this number to the V8 flaw, so checks should follow the official record
- Source of the “not exploited” statement: Neither set of release notes says the XBOW-reported flaws were exploited in the wild. The statement that they were not used in real attacks comes from XBOW and press reports
What changed – time and cost
What draws attention here is not the flaws themselves but the speed. An XBOW researcher said that building a Chrome full chain took a team of four about 6 to 9 months before AI, the company’s first attempt took two months, and the rewarded chain took six days. The model used was not a security-specific model but a public model anyone can use.
XBOW was also clear about the limits. People chose the targets, supplied context, checked results, and decided which components to combine, and XBOW said this does not mean anyone can build a full chain with the same time and money. Still, the conclusion is the same: the bar is much lower. XBOW expects that within a year, agents could find each of the three flaws on their own.
| Perspective | Change | What it means for enterprises |
|---|---|---|
| Building exploits | From months to days (per the XBOW case) | The time between a fix going public and a working exploit can shrink |
| People needed | From expert teams to a few researchers + AI agents | Advanced attack capability can spread to more actors |
| Bug collisions | Several parties find the same flaw at the same time | The assumption that an undisclosed flaw stays secret for long weakens |
| Defenders | The same tools can check their own code first | A vendor’s own testing and speed of shipping fixes become differentiators |
The Chrome 155 security update also included several vulnerabilities reported with help from AI. The faster vulnerabilities are found, the more enterprise security depends on how fast fixes reach endpoints.
The enterprise view – an attack that needs no click
Training users not to click suspicious links is not enough to stop this type of attack. Because the attack starts when a page is opened, an attack page can reach users through ad networks or compromised legitimate sites. Once code runs outside the sandbox with user privileges, it can lead to malware installation, credential theft, and lateral movement inside the network.
Users who only visit work sites are not exempt. Where one browser is used for both work systems and the external web, a single exposure to an external page puts the whole work endpoint at risk.
What enterprises should check now
| Check | Baseline | How |
|---|---|---|
| Chrome version | At least 152.0.7977.82 (152.0.7977.82/.83 on Windows and Mac). In practice, the latest Stable | Asset management tool or chrome://version |
| Endpoints not relaunched | Relaunch completed after updating | Set a relaunch deadline with the RelaunchNotification and RelaunchNotificationPeriod policies |
| Other Chromium-based browsers | Vendor’s patched build with these fixes | Check vendor security advisories and version information |
| Work apps that embed Chromium | Chromium version in work apps built with Electron and similar frameworks | Check the vendor’s update schedule |
| Low-trust external sites | Consider restricting JavaScript JIT | DefaultJavaScriptJitSetting and JavaScriptJitBlockedForSites policies. Performance may drop and WebAssembly may be limited, so pilot first, then expand |
| Detecting abnormal endpoint activity | Unusual child processes launched by browser processes | Review EDR detection rules and security monitoring alerts |
Google offers JIT restriction as a policy for running the browser in a more secure configuration, but it does not guarantee protection against any specific flaw. The definitive fix is the update.
The BrowZen view – engine flaws need engine fixes, data needs policy
BrowZen is a Chromium-based browser for work. Chromium engine flaws are a shared task for every browser built on the same code, and BrowZen follows these response principles.
| Step | Details |
|---|---|
| Check | We review Google’s security notices daily and check, fix by fix, whether BrowZen includes each one |
| Ship | For fixes that need to be applied, we prepare a patched build and notify customer administrators |
| Disclose | We do not publish detailed impact information before the patched build is released |
A secure browser does not remove engine vulnerabilities. Defense has to be split across layers, and the part a secure browser handles is as follows.
| Defense layer | Role against this type of attack | Owner |
|---|---|---|
| Browser engine security fixes | The definitive fix that removes the flaw itself | Browser vendor and enterprise patch management |
| Operating system security features | Raise attack cost but do not stop the attack alone | Operating system and endpoint management |
| EDR and security monitoring | Detect abnormal processes and activity after an endpoint is compromised | Security operations |
| In-browser work policies | Control how data leaves through paste, upload, and capture during normal work. Limited effect after an endpoint is compromised | Secure browser |
That is why, when choosing a browser for work, how and how fast the vendor ships engine security fixes matters as much as the feature list. If you are evaluating one, ask the vendor for its criteria for shipping Chromium security fixes, its patch history, and how it notifies customers. Standardizing on one work browser also reduces what you need to manage for versions and relaunches.
Closing
This case does not show that Chrome is weak. It shows that one of the most hardened pieces of software in the world can now be broken end to end in days by a small team working with AI, building on earlier preparation. As the time to build exploits shrinks, defense has to shrink the time it takes for fixes to reach endpoints.
See the BrowZen product page for features and deployment options, and What is a Secure Enterprise Browser for the basics.
References
Official notices and records
- Google Chrome Releases, Stable Channel Update for Desktop (2026-08-25, Chrome 152 - includes CVE-2026-78952)
- Google Chrome Releases, Stable Channel Update for Desktop (2026-09-03, includes CVE-2026-85045 and CVE-2026-85046)
- CVE.org, CVE-2026-85045 · CVE-2026-78952
- CISA, Known Exploited Vulnerabilities Catalog (CVE-2026-85046, added 2026-09-04)
- Chromium, Security Severity Guidelines · Chrome VRP FAQ
- Google, Chrome Enterprise Policy List
Announcements and reports
- XBOW, XBOW Built a Chrome Full-Chain Exploit Affecting a Billion Users in Six Days (2026-10-13)
- Digital Daily, XBOW: Chained vulnerabilities found in Chrome, used by 1 billion people (Korean) (2026-10-14)
- The Hacker News, Researchers Used a Public OpenAI Model to Build a $250,000 Chrome Full-Chain Exploit in Six Days (2026-10-14)
