Chrome 155 Requires Build and Extension Policy Checks
Google released Chrome 155 on 6 October and updated it again on 13 October. A fleet can therefore be on the right major version and still miss the newer security release. Check the version running after restart, not just an installation notification.
The October baseline has moved
Google’s 13 October desktop notice lists 155.0.8059.79/.80 for Windows and macOS and 155.0.8059.79 for Linux, rolling out over days or weeks. It includes 37 security fixes, seven rated critical. Android’s corresponding build is 155.0.8059.79.
The 6 October release introduced 155.0.8059.39/.40 for Windows and macOS and 155.0.8059.39 for Linux. Android also used 155.0.8059.39. Its 247 fixes included four critical use-after-free flaws: CVE-2026-106382 in Chromecast, CVE-2026-106197 in Browser, CVE-2026-106358 in Navigation and CVE-2026-106347 in Track. These are historical builds, not today’s deployment target. Neither desktop notice makes an exploitation claim.
An extension failure may be deliberate policy enforcement
Google’s enterprise-policy explanation, published 8 September and revised 16 September, describes a separate change in Chrome 155. A non-empty runtime_blocked_hosts list rejects chrome.debugger.attach() on every target, even with runtime_allowed_hosts. DisableScreenshots or DLP restrictions also reject attachment. Unmanaged browsers and managed environments without those restrictions are unchanged.
That distinction changes how a support team should respond. An error after an update is a symptom to investigate, not a reason to remove the organisation’s security requirements. The browser team and extension owner need to agree which behaviour is intended before deciding whether anything is broken.
One rollout, two decisions
Keep the security deployment and business-workflow assessment visible as separate decisions. The first asks whether the running installation meets the current release target. The second asks whether people can still perform the approved task under the controls the organisation chose. Answering only one can leave either a security gap or an unexplained operational failure.
For a pilot, choose a real approved workflow and involve its owner. Compare the result with the organisation’s intended policy, then decide whether the extension’s design or the documented way of working needs to change. A successful launch screen is weak evidence if the task that matters has not been exercised. Equally, an attachment rejection is not proof of a vulnerable browser.
Desktop and mobile deployment results should remain distinguishable in that handover. This is BlackTree’s proposed operating approach, not a claim that we tested the organisation’s extensions or that Google certified a local rollout.
Our earlier Chrome 154 report explains why vendor release evidence can arrive before vulnerability-database enrichment. It concerns a different release; its identifiers and fixed builds do not replace the current targets above.
Updated 14 October 2026: added the 13 October release targets and clarified the separate extension-policy decision. The original 9 October publication date is retained.
