Chrome 155 shipped 247 security fixes

Chrome 155 reached the Stable channel on 6 October 2026. Google's release post says it carries 247 security fixes, four of them rated Critical. That is an unusually large batch even by the standards of the two-week cadence Chrome moved to with Chrome 153.

This post covers what the release says, what it leaves open, and why a browser patch cadence belongs in the operating routine of anyone who runs a Form.

What shipped

The desktop build is 155.0.8059.39/.40 on Windows and macOS and 155.0.8059.39 on Linux. Chrome 155 also reached Android and iOS. It arrived in two steps: a small share of Windows and macOS users got 155.0.8059.26/.27 on 30 September, and the wider rollout began on 6 October. Chrome 156 entered Beta on 30 September.

Google's post notes that access to bug details and links stays restricted until a majority of users are updated with a fix, and stays restricted longer when the flaw sits in a third-party library other projects also depend on.

The severity split in the secondary write-up is four Critical, 53 High, 122 Medium and 68 Low. Counted against the previous desktop update, which carried 11 fixes, this is a release that changes a lot at once.

The four critical bugs

All four Critical entries are use-after-free bugs, a class where memory is released while something still holds a pointer to it. Google lists them by component and by CVE.

• Chromecast: CVE-2026-106382, reported by Google.

• Browser: CVE-2026-106197, reported by Xinyang Ge.

• Navigation: CVE-2026-106358, reported by Xinyang Ge of Anthropic, assisted by Claude.

• Track: CVE-2026-106347, reported by Xinyang Ge of Anthropic, assisted by Claude.

A use-after-free in Navigation or Track matters to anyone whose page posts a form, because both sit in the path a browser walks while a visitor moves between pages and a Submission is sent. That is a reason to care about the patch. It is not a claim that anything on your page was broken.

Why the cadence belongs in your routine

Chrome now ships every two weeks. A Form that accepts Submissions through a generated component runs inside whichever browser the visitor brought, and you do not control that browser. What you control is how quickly your own machines take the patch, and whether anyone reads the release notes at all.

Two habits cover most of it. Update the browsers your team uses. Then write down what you test after a browser release: one Submission from a desktop browser, one from a phone, and one Hosted page opened cold. That is a cheaper routine than learning about a rendering change from a Submitter's complaint.

What this does not decide

• It does not say a bug was exploited. Google's post does not state that any of the 247 vulnerabilities had been used, and the details of the four Critical bugs remain restricted.

• It does not say FormFlow was affected. Nothing here is a statement that FormFlow, its Hosted pages or its generated component were vulnerable, were tested against Chrome 155, or changed because of this Release.

• It does not say your Form works on Chrome 155. Whether your page renders and posts correctly is a question for your own test, on your own page.

Read the fix count as the size of the maintenance, not as a measure of danger. The useful action is the same either way: update, then test the one page you depend on.