Chrome 155 Security Update: Prioritize Enterprise Browser Patching

Google’s Chrome 155 security update is a large release, and four of its fixes carry a critical rating. The release patches 247 security flaws in total. That makes it a priority item for any team that manages Chrome across a desktop fleet.

Release availability does not equal installation, though. Chrome builds roll out gradually, so some endpoints may lag behind the fixed version. Enterprise teams should verify deployment rather than assume it. The sections below cover what Google fixed and where the risk sits. They also explain how IT teams can confirm the update reached every managed desktop.

What the Chrome 155 security update fixes

Google detailed the release in its Stable Channel update for desktop. The advisory lists 247 security fixes. Four carry Google’s critical rating, and all four are use-after-free flaws:

• CVE-2026-106382 affects Chromecast.
• CVE-2026-106197 affects Browser.
• CVE-2026-106358 affects Navigation.
• CVE-2026-106347 affects Track.

Google labels each flaw with a component name but does not define the names. Navigation covers how Chrome loads a new page, including redirects, committing the page, and creating a session history entry. Track likely points to media code, where tracks carry audio, video, or text streams. Google’s advisory does not confirm that meaning, so treat it as context, not a technical finding.

Fixed desktop builds

• Windows: 155.0.8059.39/.40
• macOS: 155.0.8059.39/.40
• Linux: 155.0.8059.39

Google says these builds will roll out over the coming days and weeks. Admins should not expect every endpoint to update at once.

The advisory also lists 53 high-severity fixes. The remaining 190 carry medium or low ratings. Nothing in Google’s advisory indicates that attackers have exploited any of these flaws. This release is a patch-management priority, not a confirmed exploitation alert.

What is known about the four critical flaws

A use-after-free flaw occurs when code keeps using memory after the program has freed it. Defects in this class can cause memory corruption in the affected component. All four critical issues belong to this class, but they sit in different parts of Chrome.

Public detail remains thin. Google’s advisory does not outline an exploitation chain. It also notes that it may restrict access to bug details until most users have updated. For defenders, that means patch prioritization rests on Google’s severity ratings rather than on observed attack data. This article therefore does not speculate about how an attacker might use these flaws.

Why enterprise teams should prioritize this patch

The operational concern is continued use of affected browser builds across Windows, macOS, and Linux endpoints. An endpoint that runs an earlier build still lacks the fixes in this release. Mixed fleets add complexity because each platform needs its own version check.

Prioritize the critical fixes ahead of routine browser maintenance. Teams can structure the work in three steps:

• Validate compatibility before the wider rollout.
• Deploy a fixed build on each platform.
• Verify the installed version, not just the job status.

A completed deployment job does not prove that endpoints run a fixed build. A version check also gives security teams a clear record of which endpoints remain behind.

How Hexnode can support Chrome Patch Deployment

Hexnode can help teams push the fixed build and watch managed endpoints while updates land. Neither product replaces Google’s fix.

Hexnode UEM: Deploy and Verify the Fixed Build

Hexnode UEM includes patch management for Windows and macOS devices, including app patching, and supports OS updates on Linux devices. On Windows, Hexnode UEM supports third-party app updates through Winget integration. Admins can use it to automate patching for apps such as Chrome. They can also upload a custom installer package, such as an .exe or .msi file, and install it silently. A typical workflow has three parts:

• Pilot the update on one device group before the wider rollout.
• Deploy through a Required Apps policy, which flags devices missing the app, or an App Distribution automation with success checks, return code handling, and retries.
• Review installed versions in the console and compare them with Google’s fixed build.

App Updates policies can also push app updates on Windows. Confirm Chrome is a supported app in your console before relying on them. None of these options show coverage of these specific CVEs, so compare installed versions against Google’s fixed build.

On macOS, upload the updated Chrome .pkg or .dmg installer as an enterprise app and push it silently. Deploy it through a Required Apps policy or the Install Application action, or use a custom script instead. DMG installs need the latest Hexnode Agent on the Mac. On Linux, use remote script execution to run your distribution’s package manager update. Test each script on one device first.

Hexnode XDR: Add Visibility Into Post-Exploitation Activity

Hexnode XDR currently supports Windows and macOS endpoints. Hexnode XDR cannot fix a use-after-free flaw, because only the fixed Chrome build does that. It adds a telemetry layer for endpoints that still run an unpatched browser during the rollout. XDR collects process creation events on supported endpoints and applies heuristic and behavioral detection.

Security teams can use it in three ways:

• When XDR raises a threat, check its process tree for unexpected child processes or shell activity from a browser.
• Review the command lines and MITRE ATT&CK mappings attached to each detection.
• Contain a suspicious endpoint by killing a process tree or isolating the device.

Treat this as an optional layer of visibility, not a response to confirmed exploitation. Hexnode XDR supports investigation of endpoint activity, but it does not guarantee detection of attempts to exploit these flaws.

Featured resource

Cybersecurity kit

Download the blueprint, checklist, incident policy template, and UEM guides to build a cybersecurity strategy.

DOWNLOAD

The takeaway for IT teams

Treat the Chrome 155 security update as a browser-remediation task. Validate compatibility, deploy the fixed build, and verify completion on every platform.

Public reporting has not established an active exploitation campaign, so teams can test carefully without delaying the rollout. Confirming installed versions turns a released fix into a finished one. Build the same check into every future browser release.