Safeguard
Vulnerability Analysis•

771 Chrome Security Fixes in Six Weeks: What It Means for Headless Chrome

Between 1 Sept and 15 Oct Chrome shipped 11 desktop Stable updates, three new majors and 771 security fixes. Pinned headless Chrome in CI and render services falls behind fast.

Safeguard Security Team
6 min read

Between 1 September and 15 October 2026, Google shipped 11 Stable channel updates for desktop Chrome, promoted three new major versions (153 on 8 September, 154 on 22 September, 155 on 6 October) and listed 771 security fixes. Thirty seven of those fixes were rated Critical. The latest build, 155.0.8059.84 for Linux, arrived on 15 October.

Most people get these updates without thinking about it. The Chrome copies that don't update themselves are the ones developers own: headless Chrome inside container images, browsers bundled by test frameworks, and render services that turn HTML into PDFs or screenshots.

What's affected

Here is every desktop Stable update in the window, with the count of security fixes Google listed in each post. Two September updates also carried exploited-in-the-wild notices. Those two bugs are covered separately, and this post focuses on the rest.

DateVersion (Linux)Security fixesCritical
1 Sep152.0.7977.75262
3 Sep152.0.7977.82120
8 Sep153.0.8010.362305
15 Sep153.0.8010.47423
17 Sep153.0.8010.52162
22 Sep154.0.8037.5710811
29 Sep154.0.8037.92321
1 Oct154.0.8037.97111
6 Oct155.0.8059.392474
13 Oct155.0.8059.79377
15 Oct155.0.8059.84101

Eighteen of the 37 Critical fixes are in the graphics stack: 10 in WebGL, 5 in ANGLE, 2 in GPU and 1 in Dawn. The 13 October update alone had seven Criticals, including use after free bugs in PDF (CVE-2026-110136), Network (CVE-2026-110161) and Core (CVE-2026-110165), plus a buffer overflow in ANGLE (CVE-2026-110152). The 15 October update added a Critical use after free in Prerender (CVE-2026-110922).

Another pattern stands out in the reporter credits. Xinyang Ge is credited on 40 of the fixes across these posts, several marked as "assisted by Claude." Machine-assisted bug finding is increasing the volume of fixes, and the release cadence has sped up to match.

How to check if you're exposed

Find every Chrome or Chromium binary that doesn't auto-update. Start with container images and CI runners:

# In a running container or CI job
google-chrome --version 2>/dev/null || chromium --version 2>/dev/null

# Across local images
for img in $(docker images --format '{{.Repository}}:{{.Tag}}' | grep -iE 'chrome|puppeteer|playwright|render|pdf'); do
  echo "$img: $(docker run --rm --entrypoint sh "$img" -c 'google-chrome --version 2>/dev/null || chromium --version 2>/dev/null')"
done

Then check browsers downloaded by test tooling:

npx @puppeteer/browsers list
npx playwright install --dry-run

Compare what you find with the current Stable build. Google's Chrome for Testing endpoint gives a machine-readable answer:

curl -s https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions.json | jq -r '.channels.Stable.version'

On 17 October that returned 155.0.8059.84.

What to do now

  1. Rebuild images that bundle Chrome or Chromium, not just the app layer. A cached base layer keeps the old browser.
  2. Update test framework browsers by bumping the framework version and re-running its install step. Pinned framework versions pin the browser.
  3. Treat render services as internet-facing browsers. If a service loads user-supplied HTML or URLs into headless Chrome, schedule it for weekly rebuilds at minimum, matching Chrome's own cadence.
  4. Turn off what you don't use. A PDF or screenshot service rarely needs WebGL. Chromium supports --disable-webgl and --disable-3d-apis, which cut off the code paths behind 18 of the 37 Criticals in this window.
  5. Keep the sandbox on. Running headless Chrome with --no-sandbox is common in containers because it avoids setup work. The sandbox is the layer meant to contain a compromised renderer, so turning it off leaves one wall where Chrome was designed to have two.

A launch config for a render service might look like this:

const browser = await puppeteer.launch({
  headless: true,
  args: ['--disable-webgl', '--disable-3d-apis'],
});

Why it matters

A browser in a CI job or render service is still a browser. It parses untrusted HTML, runs untrusted JavaScript and talks to the GPU stack. The difference is that nobody clicks "Relaunch to update." With three majors and 771 fixes in six weeks, an image built on the last day of August is now 11 updates behind.

This is also a dependency inventory problem. Chrome rarely shows up in a package manifest. It arrives through a base image, a test framework's download step or an apt layer, so it slips past checks that only read lockfiles.

Try it yourself

List every place your organization runs headless Chrome: E2E test images, PDF services, link preview workers, scrapers. For each, record the Chrome version and the date the image was built. Anything older than 6 October is still on Chrome 154 or earlier.

Click through it at your own pace, or open it full screen.

Quick check

How many Chrome major versions reached Stable between 1 September and 15 October 2026?

Three: Chrome 153 on 8 September, 154 on 22 September and 155 on 6 October.

Which component area had the most Critical fixes in the window?

The graphics stack. WebGL alone had 10 of the 37 Criticals, and WebGL, ANGLE, GPU and Dawn together had 18.

Your Playwright version is pinned and CI passes. Is the browser current?

Not necessarily. The framework version decides which browser build gets downloaded, so a pinned framework keeps an old browser until you bump it.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.