On May 6, Google’s Chrome team disclosed two privilege escalation vulnerabilities in Chromoting — the Chrome Remote Desktop host component — that affect Chrome on Windows. CVE-2026-7948 is a Windows-only race condition. CVE-2026-7994 is an insufficient-data-validation issue in the Chromoting host. Both end the same way: a local attacker with a foothold on the machine can escalate to SYSTEM. Both are fixed in Chrome 148.0.7778.96.
If you maintain a Windows fleet, this is a quietly important week. Chromoting ships with Chrome. If you have Chrome on the endpoint — and you almost certainly do — you have the affected component, whether or not anyone in your organisation actually uses Chrome Remote Desktop.
What Chromoting actually is
Chromoting is the protocol and supporting service behind Chrome Remote Desktop. It runs as a host process that listens for inbound remote-control sessions and brokers input, screen capture, and file transfer. On Windows, parts of that host run with higher privileges than the standard user.
That privilege boundary is the interesting bit. A bug in the Chromoting host that lets a low-privileged caller influence its behaviour can become a clean local privilege escalation: standard user in, SYSTEM out.
The two CVEs in plain English
CVE-2026-7948 — race condition, Windows only
This is a time-of-check / time-of-use style race in the Chromoting host on Windows. A local attacker who can win the race can manipulate a privileged operation into doing work on a resource they control, ending in arbitrary code execution as SYSTEM. The fact that the bug is Windows-only is unusual for Chrome — Chromoting on macOS and Linux is not affected here — and reflects platform-specific behaviour of the host service.
CVE-2026-7994 — insufficient data validation
The second bug is described by Google as an “inappropriate implementation in Chromoting.” In practice it is an insufficient-data-validation flaw in the Chromoting host that lets a local attacker pass a crafted file in a way the host trusts. Successful exploitation leads to OS-level privilege escalation.
Both bugs require local access. That is the line some teams will use to argue these are not urgent. It is also the line that has aged worst over the last two years.
“Local LPE” is not a low priority anymore
Half the Patch Tuesday posts on this site come back to the same uncomfortable fact: modern intrusions almost always pass through a “local” privilege escalation step. The initial foothold these days is rarely a domain admin token. It is a phishing-delivered loader, a malicious browser extension, a leaked credential pair used through a VPN, or a contractor’s laptop. From there, the attacker needs SYSTEM to disable EDR, dump LSASS, or plant persistence. Bugs like the Chromoting pair are the rung in that ladder.
We covered this dynamic in our recent piece on shrinking breakout times: once a low-privileged process is on the endpoint, every unpatched LPE on the box is a possible next step.
Why local admin makes the exposure worse
If your users run as local admin, two things change for the worse.
First, the attacker may not even need this CVE chain. A local admin already has plenty of routes to SYSTEM. Second, the same admin rights that let users skip UAC prompts also make it trivial to install or update Chrome from random sources, including older builds that are still vulnerable. Standard-user environments paired with managed browser deployment give you a real chance to drive a coordinated patch. Local-admin environments give you ten different Chrome versions across the fleet and no clean way to enforce a baseline.
What to do now
- Push Chrome 148.0.7778.96 or later to every Windows endpoint. If you have Chrome deployed via Intune, Group Policy, or another management tool, raise the minimum required version and audit compliance. Do not rely on per-user “update on next restart” behaviour.
- Audit Chrome Remote Desktop usage. If your organisation does not sanction Chrome Remote Desktop, treat its presence as a finding. Block the host installer where you can, and use AppLocker, WDAC, or your EDR to flag the Chromoting host running on endpoints that should not have it.
- Check for non-managed Chrome installs. Side-loaded Chrome from a user-mode installer often updates on a separate channel from your managed deployment. If your inventory shows two flavours of Chrome on the same endpoint, consolidate them.
- Confirm your LPE detections fire on this class of bug. Most EDR products will alert on a Chromoting child process running with elevated tokens it should not have. If you have never tested that path, now is a good week.
- Use this as another data point in the local admin conversation. Every “local-only” LPE that ships is another reason standard-user environments are worth the operational cost. Pair this with your existing local admin retirement plan and add a row to the worked-examples list.
None of this is dramatic. There is no widespread exploitation in the wild yet, and the patch is available. The reason to move quickly is that “local LPE in a Chromium component on Windows” is exactly the kind of bug that gets bolted into commodity toolkits within weeks. Push the patch this sprint and tighten the management story behind it so the next one is less work.
