Google shipped Chrome 148 to the stable channel on May 6, 2026, fixing a macOS-only vulnerability that could let an attacker escalate privileges on a Mac remotely, with no user interaction required. The flaw, tracked as CVE-2026-7978, is rated Medium by Google’s own Chromium severity system but carries a 8.1 High score from CISA’s ADP, based on a CVSS 3.1 vector that flags high impacts to confidentiality, integrity, and availability.

What changed in Chrome 148

The update moves Chrome on desktop to version 148.0.7778.96/97 across platforms, but the spotlight is on a fix for the Companion component on macOS. Google’s advisory is characteristically terse: “Inappropriate implementation in Companion. Reported by [redacted].” The Chromium bug tracker entry is restricted, so precise technical details remain under wraps. What is public: a remote attacker who can deliver malicious network traffic might trigger the flaw to gain OS-level privileges on an unpatched Mac. The vulnerability carries a CWE-693 classification—failure of a protection mechanism—which points to a breakdown in a security boundary rather than a classic memory corruption bug.

CVE-2026-7978 is just one of over 100 security fixes in the Chrome 148 release, which also closes several critical flaws in V8, WebRTC, and other components. The browser’s own update mechanism will download the patch automatically, but the new code only takes effect after a full restart.

What this means for you

The practical fallout depends on who you are and how you use a Mac.

For everyday Chrome users on a Mac: You need to update now. Open Chrome, click the three-dot menu, go to Help > About Google Chrome, and let the update run. Confirm you’re on version 148.0.7778.96 or higher (the .97 build is also patched). Then relaunch the browser completely—simply closing the window is not enough; use Chrome’s Relaunch button or quit and reopen. Because the attack vector is network traffic with no user interaction, staying on a vulnerable version is riskier than usual, even though the exploit complexity is high.

For IT administrators managing Mac fleets: This is a baseline patching event, not a drill. The vulnerability is scored 8.1, with high impact on all three security dimensions. Even if exploitation is hard, a privilege escalation on a developer’s or executive’s Mac can cascade quickly into credential theft and lateral movement. Immediate steps:
- Verify your endpoint management tool (Jamf, Kandji, Intune, etc.) can push Chrome updates and enforce browser restarts.
- Check that your vulnerability scanner correctly applies the CPE condition: it should flag Chrome before 148.0.7778.96 on macOS and not overmatch Windows or Linux systems.
- Recognize that Chrome’s update might be staged but not active until the user relaunches. A compliance report that only checks installed version—not running process—can give a false sense of safety. Enforce relaunch deadlines or use Chrome’s forced restart policies.
- Prioritize Macs used by developers, executives, and cloud administrators; these endpoints often hold the most valuable credentials and sessions.

For enterprises using Microsoft Edge on Mac: Don’t panic. Microsoft’s Security Update Guide entry for CVE-2026-7978 exists because Edge is Chromium-based, but Microsoft states that “the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable.” That language implies Edge may not be affected by this specific macOS Companion issue, or it’s already fixed. Still, keep Edge updated through its own stable channel and monitor Edge security release notes. If your scanner fires on Edge for this CVE before Microsoft confirms impact, treat it as a cue to validate and wait for official word rather than creating a exception.

For developers and power users: If you build or deploy Electron-based apps or other Chromium derivatives, note that the vulnerability is currently scoped to Google Chrome on macOS. There is no public evidence that the same code path exists in other Chromium products, but it’s a reminder to track upstream security fixes and test your own supply chains. For now, the immediate action is to update your own Chrome installation.

How we got here

Chrome’s attack surface has been expanding for years. The Companion component, while not publicly documented in detail, is part of a trend where vulnerabilities move outside the traditional renderer and into helper services, updaters, and platform integrations. The “no user interaction” and “network” triggers are especially troubling because they don’t rely on tricking someone into visiting a malicious website or installing a rogue extension.

The scoring dissonance—Google’s Medium versus CISA’s 8.1—highlights a recurring challenge. Vendor severity often reflects internal triage and exploitability assumptions that outsiders can’t see. CISA’s ADP score, on the other hand, is based purely on the CVSS standard and the same sparse advisory text. When attack complexity is high but impact is maximum, the resulting number can look like a bureaucratic compromise. For defenders, the safe interpretation is that this bug is a valuable building block in an exploit chain, and letting it linger on a Mac is unwise.

The macOS-only scope matters. Enterprise Mac fleets are sometimes treated as second-class citizens in patch programs dominated by Windows processes. But Chrome runs identically across platforms, and a Mac-specific flaw is a reminder that platform integrations can open unique holes. Apple’s own security hardening—System Integrity Protection, sandboxing, TCC—provides layers of defense, but a Chrome compromise that elevates to OS privileges could still do immense damage to user data and corporate resources.

What to do now

  1. Update Chrome on every Mac you control. The fixed version is 148.0.7778.96 or later. Use the browser’s built-in updater, an MDM profile, or your management platform.
  2. Force a browser relaunch. Don’t rely on users to notice the “Update” badge. Set policies that prompt for restart or automatically restart when Chrome is idle. If a user keeps Chrome open for days, the vulnerability window remains open even though the update is downloaded.
  3. Validate scanner logic. Confirm your vulnerability management tools are using the correct CPE: cpe:2.3:a:google:chrome:*:*:*:*:*:macos:*:* before version 148.0.7778.96. If your scanner alerts on Windows or Linux systems for this specific CVE, tune the rule to avoid alert fatigue.
  4. Check Edge separately. For Macs running Edge, cross-reference Microsoft’s security release notes for build numbers. If you see CVE-2026-7978 associated with an Edge update, apply it immediately. If not, don’t force an Edge patch based solely on the Common Vulnerability name.
  5. Monitor for downstream impact. Developers maintaining Chromium-based software (Brave, Opera, Electron apps) should watch for vendor advisories. For now, no other vendor has confirmed exposure, but it’s early.

What to watch next

CVE-2026-7978 is a test case for how well the ecosystem turns a sparse advisory into a fixed fleet. In the coming days, we’ll be watching for:

  • Any sign of in-the-wild exploitation. As of publication, none has been reported, but a no-interaction network vector is attractive to sophisticated attackers.
  • Publication of the restricted Chromium bug to see if the flaw extends to other platforms or Chromium forks.
  • Further CPE refinements in the National Vulnerability Database to guarantee accurate scanner coverage.
  • Microsoft’s Edge stable-channel notes to confirm whether the bug was ever applicable to Edge on macOS and how it was addressed.

For Mac users and administrators, the bottom line is clear: this is not a drill. Update Chrome, restart it, and verify that every managed Mac is actually running the patched build. In an era where the browser is the workplace, patch speed is the difference between a near miss and a breach.