Jordan Polasek · Founder, BVTech LLC · June 11, 2026 · 9 min read
This was a browser week. On Monday, June 8, Google shipped a Chrome Stable update that fixed dozens of security issues and singled out one of them — CVE-2026-11645 — as already being exploited in the wild. By Tuesday, CISA had added it to the Known Exploited Vulnerabilities catalog with a federal patch deadline of June 23. It is the fifth Chrome zero-day attackers have used in real-world attacks since January, and the second this year in the same component: V8, the engine that runs the JavaScript on every page you open. Here is what happened, why the usual "I'll update later" instinct is the wrong move this time, and the rest of what landed on the KEV list this week.
What: A high-severity flaw (CVSS 8.8) in Chrome's V8 engine that lets a booby-trapped web page run code on your computer. Confirmed exploited in the wild.
Fix: Update Chrome to 149.0.7827.102 (or .103 on Windows/macOS) — then relaunch the browser. Same fix applies to Edge, Brave, Opera, and other Chromium browsers as their builds catch up.
By when: CISA's federal deadline is June 23. For everyone else: today.
Every modern browser ships a small, blisteringly fast program whose only job is to run the code that websites send you. In Chrome that program is called V8, and it runs JavaScript and WebAssembly. This flaw is what engineers call an out-of-bounds read and write — V8 can be tricked into reading and writing memory just outside the box it is supposed to stay inside. That sounds academic until you realize what it buys an attacker: the ability to corrupt memory in a controlled way, which is the first domino in turning "you visited a web page" into "code is now running on your machine." Google's own description is blunt: a crafted HTML page can lead to arbitrary code execution inside the browser's sandbox.
A security researcher known only as "303f06e3" reported it to Google on April 27 and earned a $55,000 bounty for the responsible disclosure. Google has confirmed an exploit exists in the wild but, as is standard while a fix rolls out, has not published technical details or said who is being targeted. That silence is deliberate and reasonable — it slows down copycats while the patch reaches people. It also means there is no clever detection trick to lean on instead of patching. The move is simply to update.
Here is the operational detail that trips up even IT-savvy teams, and the reason I wanted to write this one up. Chrome downloads its updates quietly in the background. That is great — except the new, fixed version does not actually take over until you relaunch the browser. If you are the kind of person who has had the same Chrome window open for three weeks with ninety tabs, you may be running the patched files on disk while still executing the vulnerable version in memory. The fix is sitting right there, doing nothing, until you close and reopen.
So the real checklist is two steps, not one. Open chrome://settings/help to confirm you are on 149.0.7827.102 or later, and then click "Relaunch" when it offers. On a managed fleet there are extra wrinkles: enterprise policies sometimes pin a Chrome version, virtual-desktop images can lag well behind, and any app that bundles its own copy of Chromium (Electron apps, some point-of-sale and kiosk software) carries the same vulnerable code and has to be updated on its own schedule. Inventory matters. "We use Chrome and it auto-updates" is not the same as "every endpoint that runs Chromium is on a fixed build."
On every computer in the business: open chrome://settings/help, let it finish checking, and click Relaunch. Do the same for Microsoft Edge at edge://settings/help. Remind staff that "I'll restart later" leaves the door open. If your team uses Brave, Opera, or Vivaldi, update those too — they are all Chromium underneath.
CVE-2026-11645 is the fifth Chrome zero-day caught being exploited this year, and the second to hit V8 specifically. The common thread across all five is memory corruption — the category of bug that comes from manual memory management in C++, where one mistaken pointer can hand over control of the process. I am not telling you this to make Chrome sound uniquely unsafe; it is one of the most scrutinized pieces of software on earth, which is exactly why so many of its bugs get found and fixed in public. The lesson is simpler and a little uncomfortable: the browser is now the front door to your business. It runs untrusted code from strangers every single time someone opens a page, which makes its engine the most valuable real estate an attacker can target. Treating browser updates as urgent — on the same footing as patching a firewall or a server — is the correct posture in 2026.
Chrome was not alone on the June 9 list. CISA added three vulnerabilities in the same batch, and the other two continue a theme I have hammered on in these recaps all spring — the network edge is where the fight is.
The throughline of the week is the contrast itself. Two of these three items live on specialized network hardware most small businesses will never touch. The third lives on every desktop in the building. That is the shape of modern risk for a small or mid-sized business: the exotic stuff makes headlines, but the thing that is actually going to get you is the ordinary software everyone runs and nobody restarts.
This is the difference between reactive and proactive IT, and weeks like this are the clearest illustration of it. In a break-fix world, a Chrome zero-day is invisible until something goes wrong — there is no one watching, so the update happens whenever a staff member happens to notice the little colored icon. In a managed environment, patch status is monitored centrally: we can see which endpoints are still on a vulnerable Chrome build, push the relaunch, and confirm the fleet is clean — usually before most owners have read the news. The browser zero-day gets handled the same morning it lands, not the next time someone reboots for an unrelated reason.
None of that requires a big company or a big budget. It requires someone whose job is to watch the screens so you do not have to. That is the model we run at BVTech for small and mid-sized Texas businesses: continuous monitoring, managed patching across endpoints and edge devices, and a human who actually picks up the phone. If you are not sure whether every computer in your shop is on a patched browser right now, that uncertainty is the answer — and it is exactly the gap a proactive setup closes.
Questions about where your business stands this week? Call BVTech at (210) 538-3669 or email [email protected]. The first conversation is always free, whether or not you ever become a client — a better-defended Texas is good for all of us.
Want the bigger picture behind weeks like this? Our 2026–2027 Cybersecurity & MSP Field Manual is 67 pages of plain-English, do-it-yourself protection — patching, MFA, backups, honeypots, AI threats, and the proactive managed-security model. No email wall. Built to be passed around.
⬇ Download the Free Report (PDF)— Jordan Polasek is the Founder and Managing Partner of BVTech LLC, the award-winning, El Campo-based managed IT services provider he founded in 2013. Jordan Polasek is an AWS-certified cloud & cybersecurity specialist with ethical-hacker-level security training, two decades of hands-on experience, and a 4.0 GPA in his Cloud Computing degree. He was named SuperOps Solo MSP of the Year in 2023. Connect with Jordan on LinkedIn or at jordanpolasek.com.