Six Zero-Days in Eight Months, One Thousand-Dollar Bounty
Google's Chrome team shipped builds 152.0.7977.82 and .83 for Windows and macOS, and 152.0.7977.82 for Linux, on September 3 and 4, 2026, fixing CVE-2026-85046, a type confusion flaw in the V8 JavaScript and WebAssembly engine that Google confirmed was already being exploited in the wild. The bug lets a crafted web page trick V8's compiler into handing an attacker arbitrary read and write access on the browser's heap, opening a path to remote code execution inside Chrome's sandbox. Researcher Salvatore Gulizia reported the flaw on August 4, 2026, and was paid a 1,000 dollar bounty; Google withheld technical detail until the fix had reached most users, standard practice for an actively exploited bug. This is the sixth actively exploited Chrome zero-day patched in 2026, and every one of them scored CVSS 8.8 and needed an emergency out-of-cycle patch rather than waiting for Chrome's normal release train.
| Month (2026) | CVE | Component | CVSS |
|---|---|---|---|
| February | CVE-2026-2441 | CSS (use-after-free) | 8.8 |
| March | CVE-2026-3909 | Skia (out-of-bounds write) | 8.8 |
| March | CVE-2026-3910 | V8 | 8.8 |
| April | CVE-2026-5281 | Dawn / WebGPU (use-after-free) | 8.8 |
| June | CVE-2026-11645 | V8 (out-of-bounds access) | 8.8 |
| September | CVE-2026-85046 | V8 (type confusion) | 8.8 |
Eight Days Before the Clock Started
Google's own timeline shows the gap that matters: it disclosed and patched CVE-2026-85046 on September 3 and 4, eight days before the enforcement date of the article in the EU Cyber Resilience Act that would have required a formal report of exactly this kind of event. From September 11, 2026, Article 14 treats software such as Chrome as a product with digital elements, and once a vendor becomes aware that a vulnerability is being actively exploited, it must send an early warning to a national contact point and to ENISA, the EU's cybersecurity agency, within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of the fix becoming available. Had Google discovered and disclosed the same bug on September 12 instead of September 3, the identical sequence of a researcher reporting a V8 bug, Google confirming in-the-wild exploitation, and Google shipping an emergency patch would have become the Cyber Resilience Act's first real test case rather than a routine advisory. Six exploited Chrome zero-days landing across eight months in 2026 makes a seventh, arriving after the Act's teeth are in, a matter of when rather than if.
The Decision Rule for Whoever Owns Patch Policy
The practical lesson for any EU business is not to wait for a regulatory filing to learn about the next Chrome zero-day, because Google's own release notes said the fixed builds would roll out over the coming days and weeks even after the patch existed, meaning autoupdate speed, not disclosure speed, decides how long a fleet of laptops stays exposed. Whoever owns endpoint policy should treat sixth zero-day this year as a base rate, not an anomaly: with six incidents landing roughly every six to seven weeks through 2026, the correct posture is a standing process that checks installed Chrome versions against the latest stable build on a weekly cadence, rather than trusting that every machine updates itself on schedule. Once the Cyber Resilience Act's clock is running, an EU-based IT team also gains a new signal worth watching: a vendor's ENISA filing history becomes a rough proxy for how often its products are being actively attacked, more concrete than a marketing claim about enterprise-grade security and worth checking before a renewal, not after an incident.
Read next: SonicWall SMA1000 Flaws Are Being Exploited Now | EU Security Teams Have No Say Over OpenAI's Astra



