A keypress on a Mac is supposed to require a person. A Chrome update this month closed a gap that let software inside the browser’s graphics process forge those keypresses and drive the desktop itself.
Google’s patch landed on October 6 as Chrome 155.0.8059.39 and carries CVE-2026-106378, rated 8.3. The flaw exists only on macOS.
The permission that does not expire mid-stream
Chrome hands rendering to a separate GPU process so a compromised page cannot reach the wider system. On macOS that process runs inside a Seatbelt profile, Apple’s rule-based confinement layer, and the profile deliberately allows one lookup: com.apple.windowserver.active. Without a line to WindowServer, which composites every window, nothing draws. Seatbelt only asked whether that connection could open. After it opened, nothing constrained which WindowServer functions the process called, and input flows through the same service as pixels.
Spotlight as the launchpad
Researchers at pwn.ai read Apple’s undocumented SDK stubs and found posting calls in CoreGraphics and SkyLight, among them CGSPostKeyboardEvent. Loading SkyLight from the sandboxed helper gave them synthetic keystrokes. Their proof sent Command+Space, typed Calculator, then Return. The calculator appeared, spawned by launchd rather than by the browser.
Accessibility permission decides whether that works. Only applications macOS has vetted through TCC may deliver manufactured input to the compositor, and in the tested path the GPU child carried the identity of whichever app launched Chrome.
Google’s remedy makes the GPU child disclaim inherited TCC responsibility behind a flag called kMacDisclaimGpuTccResponsibility.
The escape is one step in a longer intrusion. pwn.ai assumed code already running in the GPU process; a real intruder would need a memory-corruption bug such as ANGLE or Skia first. No in-the-wild exploitation has been reported, and CISA’s exploited register lists none.
