Chrome CVE-2026-85046 Is Already Exploited — Patch the Browser Fleet

Walk into a 12-person office in Staten Island, Bay Ridge, or Midtown and count the screens. Almost every desk runs a Chromium browser for email, banking portals, vendor dashboards, and the random PDF someone opened from a client. The firewall got patched last week. The phone box in the closet got a KEV write-up. The browser on every laptop is still the daily attack surface — and on September 3, 2026, Google said an in-the-wild exploit already exists for a High-severity V8 bug in Chrome.

This is not another closet-appliance story. It is fleet work: confirm Chrome (and the Chromium siblings) actually updated, force the restart people skip, and treat unmanaged home PCs and contractor laptops as part of the same problem.

Chrome CVE-2026-85046: what Google shipped on September 3

Google’s Stable Channel Update for Desktop (Thursday, September 3, 2026) moved Stable to 152.0.7977.82/.83 for Windows and Mac and 152.0.7977.82 for Linux. The rollout spreads over the coming days and weeks — which is exactly why “I think Chrome updates itself” is not a verification plan for a 15-user firm.

The headline fix is CVE-2026-85046, rated High: type confusion in V8. Google paid a $1,000 reward. Researcher Salvatore Gulizia (nickname Serotav) reported it on 2026-08-04. The advisory’s explicit line is the one that should move your ticket queue: Google is aware that an exploit for CVE-2026-85046 exists in the wild.

Google did not publish a campaign name, victim list, or exploit walkthrough. That is normal for an active Chrome zero-day. Your job is not to reverse-engineer V8. Your job is to get the patched build onto every machine that still opens the internet.

SecurityAffairs (Pierluigi Paganini, September 4, 2026) attributes a CVSS 8.8 score to CVE-2026-85046. Google’s own advisory only says High. If you need a number for a client email, attribute the 8.8 to SecurityAffairs — do not put Google’s name on a CVSS they did not print.

The same Stable train also patched other High issues (mention them as also fixed in this release; we are not inventing CVSS for them): CVE-2026-85052 (CrashReporting out-of-bounds read), CVE-2026-85043 (Network incomplete cleanup), CVE-2026-85048 (Compositing use-after-free), CVE-2026-85045 (V8 race), CVE-2026-85050 (WebGL out-of-bounds write), CVE-2026-85053 (CacheStorage improper resource exposure), CVE-2026-85042 (DevTools use-after-free), CVE-2026-85049 (Skia use-after-free), and CVE-2026-85051 (Compositing type confusion). Medium entries in the same advisory include CVE-2026-85047 and CVE-2026-85044. Twelve security fixes total in the train. The in-the-wild statement attaches to CVE-2026-85046.

What type confusion in V8 means for a desk worker

BleepingComputer (Bill Toulas, September 4, 2026) summarizes the risk in plain language: type confusion can make software misinterpret object types and corrupt memory. V8 is Chrome’s JavaScript and WebAssembly engine. A crafted HTML page with malicious JavaScript may enable remote code execution inside Chrome’s sandboxed renderer process.

That still matters for a small NYC firm. The sandbox is not a free pass to leave unpatched browsers on every desk. Browser compromise is how session cookies, open tabs into accounting portals, and “already logged into Microsoft 365” windows become someone else’s problem. We have already covered how email and identity paths turn into account takeover for local businesses — see email and identity as the breach path and Mirage2FA-style MFA session theft. A zero-day in the browser sits upstream of those stories: the user does not have to “click a weird attachment” if a bad page can run code in the renderer.

This post will not include exploit proofs, payloads, or reproduction steps. Those belong in vendor and researcher channels for people with a lab. Defenders need inventory, update confirmation, and restart proof.

Sixth Chrome zero-day of 2026 — why the count matters

Per BleepingComputer, CVE-2026-85046 is the sixth actively exploited Chrome bug Google has fixed in 2026. The earlier in-the-wild fixes they list:

• CVE-2026-2441 — February (iterator invalidation / CSSFontFeatureValuesMap)
• CVE-2026-3909 and CVE-2026-3910 — March (Skia out-of-bounds write; V8 inappropriate implementation)
• CVE-2026-5281 — April (use-after-free in Dawn / WebGPU)
• CVE-2026-11645 — June (out-of-bounds read/write in V8)

We are not inventing campaign names or borough infection counts. The operational point is simpler: Chrome zero-days are not a once-a-year event in 2026. If your MSP playbook only wakes up for firewall KEVs, you will keep missing the software that sits open eight hours a day on every desk.

Why small NYC firms miss browser patches

Chrome’s Stable update rolls out over days and weeks. That staggered release is good for Google’s crash telemetry. It is bad for a firm that assumes “everyone is current” after reading a headline on Friday morning.

Common failure modes we see in 10–20 person shops:

• Updated binary, old process. Settings → About Chrome shows the new build, but the user never restarted. The fix is not live until Chrome restarts.
• Unmanaged Chromium siblings. Edge, Brave, Opera, and Vivaldi pull Chromium fixes on their own schedules. BleepingComputer notes those browsers may take a couple of extra days. “We patched Chrome” is incomplete if half the staff lives in Edge.
• Home PCs and contractors. The bookkeeper who RDP’s from Myrtle Beach, the marketing contractor on a personal MacBook, the owner’s kids’ laptop that somehow has the QuickBooks bookmark — none of those are in your Intune group until someone puts them there.
• Android Chrome lag. Google also pushed Chrome 152 (152.0.7977.82) for Android via Play over the following days. Phones that open the same portals as the desk deserve the same “is it actually updated?” question.
• RMM blind spots. Some tools inventory “Chrome installed” and never check the running version after a silent update fails on a locked profile.

None of that requires a fancy threat brief. It requires a checklist and a confirmed restart.

Practical checklist: patch the browser fleet this week

No exploit steps. Defender work you can finish before the next status call.

1) Inventory every Chromium browser

• List Chrome, Microsoft Edge, Brave, Opera, and Vivaldi on every company laptop and VDI.
• Pull version from RMM / Intune / Jamf — do not trust a hallway survey.
• Ask who uses a personal browser profile for work email or banking. Those machines belong on the list.

2) Force Chrome to the September 3 train

• Target 152.0.7977.82 or .83 (Windows/Mac) and 152.0.7977.82 (Linux) per Google’s Stable advisory.
• On a sample desk: open Settings → About Chrome, wait for the update, then restart.
• If the rollout has not reached a machine yet, keep checking. Staggered does not mean optional.

3) Prove the restart happened

• Screenshot or RMM evidence of the new version after restart.
• Close lingering Chrome processes that keep old renderers alive (multiple profiles, background apps).
• For kiosk or shared Midtown reception PCs, schedule a forced restart outside lobby hours.

4) Cover Edge and other Chromium browsers

• Do not assume Edge auto-updated the same hour as Chrome.
• Check Edge’s About page (or your enterprise channel policy) and restart.
• Wait the couple of days BleepingComputer flags for Brave/Opera/Vivaldi if those are in use — then verify, do not guess.

5) Push policy, not hope

• Intune / Group Policy / your RMM: enforce Chrome update behavior and block ancient builds where you can.
• Prefer enterprise update controls over “users will click About Chrome someday.”
• Document exceptions (air-gapped lab machines, locked medical carts) so they do not silently become the hole.

6) Do not ignore phones

• Android Chrome 152.0.7977.82 is in the Play rollout. Confirm managed phones actually received it.
• iOS Chrome follows Apple’s rules; still confirm staff are not weeks behind on App Store updates for work browsers.

7) Tie browser hygiene to identity hygiene

• After a zero-day week, review who has standing sessions into M365, banking, and payroll from unmanaged browsers.
• Rotate high-value sessions if a machine was days behind and browsed freely.
• Keep MFA and session controls tight — browser bugs and session theft stories travel together.

Browser zero-day week vs. closet-appliance KEV week

Earlier this week we wrote about Sangoma Switchvox CVE-2026-9586 on CISA’s KEV list — the beige phone appliance that still has a public IP. That class of problem is “find the forgotten box, patch or kill exposure, triage if it was internet-facing.”

Chrome CVE-2026-85046 is the opposite topology. There is no single closet. There are fifteen laptops, two reception PCs, a contractor MacBook, and a stack of phones. The blast radius is the user session, not a SIP port. You still need urgency. You need a different playbook: fleet update + restart confirmation + Chromium-sibling lag + unmanaged endpoints.

Do both. Patching Switchvox does not update Chrome. Updating Chrome does not close a forgotten PBX. NYC SMBs get burned when the MSP only tells one of those stories.

What MicroSky will do if you call

If you want this handled instead of emailed around as a PDF:

• We inventory Chrome / Edge / Brave across your Staten Island, Brooklyn, Queens, and Midtown endpoints.
• We push or verify Stable 152.0.7977.82/.83, confirm restarts, and flag machines still waiting on Google’s staggered rollout.
• We align Intune or RMM update policy so the next Chrome zero-day is not a hallway scavenger hunt.
• We connect the browser work to the identity path — because a patched firewall with a stale Chrome session is still an open door.

Call (718) 672-2177 or visit microskyms.com. Ask for a browser-fleet check tied to CVE-2026-85046 — not a generic “we’ll look at updates someday” ticket.

Bottom line: Google’s September 3 Stable update fixes Chrome zero-day CVE-2026-85046 (High, V8 type confusion) and states an exploit exists in the wild. It is the sixth actively exploited Chrome fix of 2026. Get to 152.0.7977.82/.83, restart, cover Edge and friends, and verify the machines that never show up in your RMM. The browser is the desk. Treat it like one.