CVE-2026-7997: Local Privilege Escalation in Chrome's macOS Updater

Auto-updaters are the quiet root daemons of every desktop. They have to be privileged - installing a browser system-wide means writing into places a normal user can't - so they run as a highly-trusted service and wake up to do privileged work on a schedule. That makes them one of the highest-value targets on a Mac: if a process running as root can be made to act on input a normal user controls, "normal user" becomes "root." CVE-2026-7997 is exactly that shape of bug in Chrome's macOS updater - insufficient validation of untrusted input on a privileged path, escalating a local user to elevated privileges.

The threat model people skip

The interesting attacker here is not remote. It's the local, unprivileged user - malware that already ran as you with your permissions, or a multi-user machine - trying to cross the line from "your account" to "the system." Most people model Chrome's attack surface as the renderer and the network. The updater is off to the side, privileged, and comparatively unwatched, which is precisely why it's worth the look. The privileged component and the thing feeding it input are at different trust levels; the vulnerability lives in the seam between them.

The class of bug

Chromium's advisory describes it as insufficient validation of untrusted input in the updater, exploitable locally through a malicious file to escalate privilege. That is the canonical macOS privileged-helper failure: a root-level service consumes a path, a file, or a message that a lower-privileged user can influence, and acts on it - writing, moving, or executing - without proving the input is what it assumes. The families this class splits into are well known:

• Path / symlink handling - the privileged side follows a path the user can redirect, so a write meant for a protected location lands somewhere the attacker chose.
• TOCTOU - the file is validated and then used as two separate steps, and the user swaps it in between.
• Trusting a client-supplied location - the service does privileged work against a path handed to it over IPC without confirming the caller should reach it.

The through-line is identical to the web bugs elsewhere on this page: something decided an input was safe, and something else acted on it with authority. The only thing that changes is that "authority" here is root, not the DOM.

On the severity, honestly

There's a genuine rating split on this one and it's worth being straight about. Google's Chromium security team rated it Low internally; CISA's ADP entry assigns a CVSS 3.1 base of 7.8 - High (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Both are defensible from where they sit: Google weighs it against a threat model where an attacker with local code execution is already a serious compromise, so a further local escalation moves the needle less; CISA scores the mechanical impact - local vector, low complexity, full confidentiality/integrity/availability loss on success - and that math lands at 7.8.

I report the number I can defend and I note the disagreement rather than quietly taking the bigger one. A local-EoP-to-root is real and worth fixing; it is also not a remote zero-click, and pretending otherwise is how a researcher spends credibility they'll want later.

The gap isn't hand-waving - it's the metrics. Load each preset below and watch the same bug move between LOW and HIGH. The whole disagreement lives in three fields: does escalation need pre-existing local code execution (PR), does it need a race (AC), and how much do you actually own on success (C/I/A)?

The fix, and the pattern

Fixed in Chrome for macOS 148.0.7778.96. The durable lesson isn't specific to Chrome: a privileged helper must treat everything from a lower trust level as hostile until proven otherwise - canonicalize and re-check every path after opening it, never trust a location supplied by a caller you didn't authenticate, and collapse validate-then-use into a single atomic operation so there's no window to swap the target. The updater that installs your browser has more power over your machine than your browser does. It should be at least as paranoid.

If you run Chrome on macOS: update to >= 148.0.7778.96 (Chrome → About Google Chrome). On managed fleets, confirm the updater itself is current, not just the browser binary.

Public record: NVD · Chrome releases. Reported to Google under coordinated disclosure.