PWN.AI published a write-up of CVE-2026-106378, a macOS Chrome bug in which the GPU process sandbox allowed a WindowServer connection that could also post keyboard events. Their proof of concept typed into Spotlight to launch Calculator outside the sandbox, and they say Chrome 155 shipped the fix. Google's October 6 stable update and the CVE record confirm a Medium-severity sandbox privilege elevation on Mac before 155.0.8059.39.
The newsroom's question was whether agents that drive a bundled Chromium through Playwright or Puppeteer lag behind that fix. That matters because browser agents load untrusted pages all day, often on developer Macs where the terminal or IDE that launches the browser already holds Accessibility permission.
What we checked
- Can Chrome's CVE record and Playwright or Puppeteer release metadata verify which bundled Chromium versions remain affected and how widely agent deployments use them? partly confirmed. The CVE record and Chrome's release notes set the cutoff at Chrome on Mac before 155.0.8059.39. Playwright 1.64.0 bundles Chromium 156.0.8078.4 and Puppeteer-core 25.14.0 rolled to 155.0.8059.79, while Playwright 1.63.0 bundles 153.0.8010.12; no public data measures how many agent deployments still use older pins. [4][5][2][3][6]
- Is the bug a standalone remote compromise of agent browsers? refuted. Both the CVE text and PWN.AI's PoC require prior code execution inside Chrome (a compromised renderer or GPU helper), plus Accessibility permission on the launching app, so it is the second link of an exploit chain. [5][1]
What we found
- PWN.AI's write-up shows that Chrome's macOS GPU sandbox profile let the GPU helper look up the WindowServer Mach service and then post synthetic keystrokes, which it used to open Spotlight and launch Calculator outside the sandbox. The proof of concept is a second-stage escape: it assumes the attacker already runs native code in the GPU process, and it depends on the parent process holding Accessibility (TCC) permission. [1]
- The fix does not remove WindowServer access; per PWN.AI it makes the GPU child disclaim the parent's TCC responsibility behind a feature flag. That means exposure depends on whether the launching process (Terminal, an IDE, an agent host) holds Accessibility permission, which is common on developer Macs running automation tools. [1]
- Playwright's current release line already bundles a Chromium newer than the fixed Chrome stable: v1.64.0 ships Chromium 156.0.8078.4 and was tested against Chrome 155. The previous minor, v1.63.0, ships Chromium 153.0.8010.12, below the 155.0.8059.39 cutoff, so macOS projects pinned to Playwright 1.63 or older still run a pre-fix bundled Chromium. [2][3]
What it means
If you run browser agents or test automation on macOS, check which Chromium you actually launch. Playwright 1.64 and Puppeteer-core 25.14 or newer bundle builds at or past the fix; Playwright 1.63 and older bundle Chromium 153 or earlier, below the cutoff. Upgrading the pin and re-running the browser install step is the simple remedy, and agents that use the system Chrome channel are covered once Chrome updates to 155.0.8059.39 or later.
The bug is not a drive-by: an attacker needs a renderer or GPU-process exploit first. Still, because the escape rides on the parent's Accessibility permission, avoid granting Accessibility to the terminal or host that launches agent browsers, and prefer running agents in Linux containers or VMs, where this macOS-specific path does not exist.
Competing readings
- A narrow, already-patched macOS Chrome bug; current agent tooling is fixed and only stale pins matter (likely, about 70%). What would tell it apart: The fix shipped in Chrome 155.0.8059.39 and current Playwright and Puppeteer bundle builds at or above it [4][2][6]; Exploitation needs a prior renderer or GPU-process compromise [1][5].
- A meaningful agent-fleet risk because many macOS agent setups pin old Playwright versions with Accessibility-enabled hosts (unlikely, about 25%). What would tell it apart: Playwright 1.63 and older bundle Chromium below the fixed version [3]; The escape uses the parent's Accessibility context, so Accessibility-holding agent hosts matter most [1].
- The fix is incomplete because WindowServer access stays in the GPU sandbox (very unlikely, about 10%). What would tell it apart: The patch keeps the WindowServer lookup and only stops the GPU child using the parent's TCC context [1].
Base rate
The New Runtime archive holds only 1 earlier incident stories about companies, products, projects or standards from the last 12 months that are at least 3 months old: too few (minimum 5) for a base rate. The archive has too few cases to give a base rate: only 1 case with 1 match, below the minimum of 5, so this conclusion does not lean on it.
What would change this view
- Reports of in-the-wild chains pairing a Chrome renderer exploit with this escape against automation browsers (signal): The second-stage limit is not protecting agent fleets in practice.
- A Playwright or Puppeteer issue showing the fix is missing or disabled in bundled builds (open-source signal): Current bundled Chromium would remain exposed despite a newer version number.
- A follow-up CVE for another WindowServer operation reachable from the GPU sandbox (signal): The TCC-context patch did not close the class of bug.
Still open
- How many production or developer agent setups on macOS still pin Playwright 1.63 or older, or other tools bundling pre-155 Chromium?
- Does the Chromium 156.0.8078.4 build in Playwright 1.64 have the kMacDisclaimGpuTccResponsibility feature enabled by default, as stable 155 does?
- Have Electron-based agent hosts or other Chromium embedders picked up the fix?