Google has shipped the Chrome 155 security update twice in three days. The second one landed on 15 October 2026 and patches ten vulnerabilities, including one rated Critical. If you only update the Chrome on your own laptop and stop there, you have missed most of the places Chromium lives in a developer’s stack — your Electron apps, your Playwright and Puppeteer test browsers, your CI images, and the machines your team manages.
This is the developer’s checklist for the October 15 Chrome 155 security update: which build you actually need, what the patch fixes, and the four places to update beyond your own browser. Verified and published 20 October 2026.
Which Chrome 155 build do you actually need?
Chrome 155 has had three separate security events in thirteen days, and the version numbers are easy to mix up. Here is the timeline:
| Date | Stable build (Win/Mac · Linux) | Fixes |
|---|---|---|
| 7 Oct 2026 | 155.0.8059.39/.40 · 155.0.8059.39 | 247 fixes, 4 Critical |
| 13 Oct 2026 | 155.0.8059.79/.80 · 155.0.8059.79 | 37 fixes, 7 Critical |
| 15 Oct 2026 | 155.0.8059.84/.85 · 155.0.8059.84 | 10 fixes, 1 Critical |
Your target is 155.0.8059.84 or later on Linux, and 155.0.8059.84/.85 or later on Windows and Mac. If your About page shows .79/.80, you have the October 13 patch but not the October 15 one. If it shows .39/.40, you are two patch days behind. Android carries the same fixes at build 155.0.8059.84, and the Extended Stable channel got the same ten fixes at 152.0.7977.169.
What the October 15 Chrome 155 security update fixes
The headline item is CVE-2026-110922, a Critical use-after-free in Prerender — the feature that loads pages in the background to speed up navigation. Use-after-free bugs let attackers corrupt memory and, in some cases, run their own code inside the renderer. It was reported by Xinyang Ge on 2 October.
The full list from Google’s advisory:
| CVE | Severity | Component | Type |
|---|---|---|---|
| CVE-2026-110922 | Critical | Prerender | Use after free |
| CVE-2026-110913 | High | DOM | Memory corruption |
| CVE-2026-110919 | High | V8 | Use after free |
| CVE-2026-110918 | High | Core | Memory corruption |
| CVE-2026-110917 | High | SVG | Memory corruption |
| CVE-2026-110921 | High | V8 | Use after free |
| CVE-2026-110920 | High | V8 | Memory corruption |
| CVE-2026-110916 | Medium | Desktop | Improper input validation |
| CVE-2026-110915 | Medium | Compositing | Use after free |
| CVE-2026-110914 | Medium | Workers | Memory corruption |
Two things stand out for developers. First, CVE-2026-110913 was reported by Xinyang Ge of Anthropic “with Claude AI” — Google’s advisory credits an AI model in the report, part of the growing trend of AI-assisted vulnerability research. Second, Google says it found many of these bugs with its sanitizer and fuzzing toolchain: AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, and AFL. The bugs in this batch were reported between April and October 2026.
Google has not reported any in-the-wild exploitation for this batch, and it keeps the bug-tracker entries restricted until most users have updated — so there are no public details to turn into detections. Third-party threat trackers put the Critical flaw’s 30-day exploitation probability (EPSS) at 0.2%. The correct response is update discipline, not incident response.
Step 1: Update Chrome — then actually restart it
The obvious step, done properly. Google’s rollout is staged over days and weeks, so your machine may not be offered the build yet. Do not wait for it:
- Open Chrome, go to the three-dot menu → Help → About Google Chrome (or type
chrome://settings/helpin the address bar). - Chrome queries the update servers and starts downloading immediately.
- Click Relaunch when it finishes. Save your form work first — tabs restore, unsaved text in plain forms may not.
- Confirm the version reads 155.0.8059.84/.85 (Windows/Mac) or 155.0.8059.84 (Linux).
The relaunch is the step people skip. Chrome downloads the update in the background, but the patched code only runs after the browser restarts. An “updated but never relaunched” browser is still running the vulnerable build — and if your About page says “Chrome is up to date” while showing an older 155 build, your device cohort is simply still queued; check again in a few hours.
Step 2: Your Electron apps don’t get the fix for free
Here is the part most developers miss. VS Code, Slack, Discord, and every Electron app you have shipped bundles its own copy of Chromium. Updating Google Chrome does nothing for them.
Check what your Electron apps are actually running. In any Electron app’s developer console:
process.versions.chrome
// e.g. "154.0.8037.126" — compare against 155.0.8059.84Or use Help → About in the app itself. Then check the Electron release schedule to see which Chromium each Electron version bundles, and watch your vendors’ update channels. Downstream projects move at their own pace — the Helium browser shipped version 0.19.4 on Chromium 155.0.8059.84 within four days, and GrapheneOS’s Vanadium updated to 155.0.8059.84 the same week, which shows how fast well-run forks can move when they want to.
If you ship an Electron app yourself, this is a shipping task, not a someday task: rebuild on a current Electron release and push the update to your users. Your users will never open chrome://settings/help inside your app.
Step 3: Refresh your Playwright and Puppeteer test browsers
Your test automation runs browsers too, and they are pinned — not auto-updated.
Playwright downloads specific pinned Chromium builds per Playwright version. The official guidance is explicit: every time you update Playwright, re-run the install command. On your machine and in CI:
# Update Playwright itself first
npm install -D @playwright/test@latest
# Then install the matching browsers
npx playwright install chromium
# On CI, install OS dependencies at the same time
npx playwright install --with-deps chromiumOne nuance worth knowing: Playwright’s bundled Chromium is usually ahead of Google Chrome’s stable channel — when the world is on Chrome N, Playwright already ships Chromium N+1. So your Playwright tests may already be running a newer engine than your browser. But if your config uses channel: 'chrome', Playwright drives the branded Google Chrome installed on the machine — and then the machine’s Chrome version is what matters. Check which one your projects use before assuming you are covered.
Puppeteer downloads Chrome for Testing, not the browser on your machine. To pull the current stable build:
# Latest Chrome for Testing from the Stable channel
npx @puppeteer/browsers install chrome@stable
# See what you already have cached
npx @puppeteer/browsers listIf your Docker images install google-chrome-stable from Google’s apt repo, they get the latest stable at build time — rebuild the image to pick up 155.0.8059.84, and make sure your CI actually rebuilds on a schedule instead of caching a months-old layer.
Step 4: Rebuild CI images and check managed fleets
If you manage other people’s machines, push the update through Chrome Enterprise policy and verify it landed — confirm the relaunch actually happened, not just that the download completed. Reporting from the previous Chrome 155 patch day flagged this explicitly: downloaded-but-not-restarted browsers were still exposed.
For CI and ephemeral environments, the checklist is short:
- Rebuild any Docker image that installs
google-chrome-stableor a pinned Chromium — the browser inside is frozen at image build time. - Re-run
npx playwright install --with-deps chromiumin your CI setup step if you cache the browser directory between runs. - If you pin a Chrome for Testing version in Puppeteer configs, bump the pin to a 155.0.8059.84+ build.
This is the same discipline as any other patch-day post on this blog — see the OpenSSH 10.6 upgrade checklist and the GitLab October security update guide for the pattern: audit where the software runs, update every copy, verify the running version.
What you can stop worrying about
Three things are true at once: the flaws are real, no exploitation has been reported, and the fix is a routine update. There is nothing to hunt for in your logs — with bug details restricted and no public proof of concept, there are no artifacts to build detections from. CISA has not listed any of these CVEs as known-exploited.
The oddity worth remembering is the cadence itself: three Chrome 155 security releases in thirteen days (247 fixes, then 37, then 10). That is not a sign that Chrome is falling apart — it is what a fast-moving stable channel looks like when external researchers and Google’s own fuzzing keep finding memory-safety bugs. Your job is not to read every advisory. Your job is to make sure every copy of Chromium in your stack — the browser, the Electron apps, the test browsers, the CI images — is on a build from October 15 or later, and to verify the number instead of assuming the updater did its job.
Further Reading & References
- Stable Channel Update for Desktop (Oct 15, 2026) — the official Chrome Releases announcement with the build numbers.
- Chrome 155 Patches Critical Use-After-Free Flaw and Nine Additional Security Bugs — Cybernoz; the full CVE table with reporters.
- Google Chrome 155 Patches Critical Use-After-Free Flaw and Nine Additional Security Bugs — GBHackers; confirms the “assisted by Claude” credit and no in-the-wild exploitation.
- Chrome 155 Update Patches 37 Security Flaws, 7 of Them Critical — details on the separate October 13 push (.79/.80), so you don’t mix the two builds up.
- @puppeteer/browsers CLI documentation — official docs for the
install chrome@stablecommand. - Playwright: Browsers — official docs on installing and updating Playwright’s pinned browsers.
- Electron Release Schedule — which Chromium each Electron version bundles.
- Helium browser 0.19.4 update — an example of a downstream Chromium fork shipping 155.0.8059.84 within days.
