Chrome’s renderer and GPU processes were meant to be disposable. On the Mac, not quite.
A sandbox escape patched in Google’s browser let code inside the graphics helper type on a user’s desktop and start applications for them. The flaw, tracked as CVE-2026-106378, scored 8.3 and applied only to Chrome on the Mac.
The exception that started it
Under Seatbelt, Apple’s rule-based sandbox, the GPU process may look up WindowServer, the service that draws the screen. Rendering needs it. Seatbelt decides whether the connection exists, not what the process does with it, and WindowServer also handles keyboard and mouse input.
The pwn.ai team combed Apple’s SDK stubs, catalogs of private functions Apple leaves undocumented, and located calls that post events in CoreGraphics and SkyLight. From inside the sandbox they sent synthetic keys: Command-Space, then Return. The app launched.
The sandbox held. A shell spawned from the GPU process failed, and Calculator opened as a separate process started by launchd. It worked because macOS accepts synthetic input from processes holding Accessibility permission, which the child inherited from whatever launched Chrome.
Half a chain, not a whole one
The proof of concept assumed code already running in the GPU process, simulated by patching Chromium itself. A real intrusion would still need memory corruption in the renderer, ANGLE or Skia first.
Google fixed it in Chrome 155 on October 6 by making the GPU child disclaim the inherited permission, behind a feature flag. Rendering still needs it, so the lookup stayed. No exploitation has been reported and the CVE is absent from CISA’s known exploited list.
Chrome 156 for Mac shipped October 27. Check chrome://settings/help and relaunch, since the change only applies after a restart. pwn.ai says other sandboxed Mac apps whose child processes keep the WindowServer lookup should audit the same handoff.
