CVE-2026-7910 is a high-severity Chromium use-after-free flaw in the Views component, fixed in Google Chrome 148.0.7778.96/97 on May 5, 2026, and NVD’s current enrichment already includes the Google Chrome CPE, with Windows, Linux, and macOS modeled as underlying platforms. That means the obvious Chrome CPE is not missing; the more interesting gap is how awkwardly vulnerability databases describe Chromium bugs once they flow into Chrome, Edge, and the wider browser ecosystem. For Windows administrators, the practical answer is blunt: inventory browser build numbers, not just CVE pages, and assume Chromium-derived browsers need separate verification. The CVE is less a standalone crisis than another reminder that the browser has become the operating system’s most exposed application boundary.
The NVD entry for CVE-2026-7910 describes a use-after-free issue in Chrome’s Views component before 148.0.7778.96. In NVD’s enrichment, the vulnerable application is represented as Google Chrome versions before that build, with operating systems listed as the platforms on which the affected application runs. That is a normal CPE modeling pattern, even if it looks odd when rendered as an “AND” tree.
So if the question is whether the Chrome product CPE is missing, the answer is no. The CPE shown for
But this is where the tidy world of vulnerability metadata collides with how people actually run browsers in 2026. Most users do not experience Chromium as an abstract upstream project. They experience it as Google Chrome, Microsoft Edge, Brave, Vivaldi, Opera, Electron apps, embedded webviews, kiosk shells, and managed browsers inside virtual desktops.
That is why security teams often feel as if a CPE is missing even when the database is technically correct. The CPE entry tells you where the originating vendor fixed the bug. It does not automatically tell you whether every Chromium downstream has pulled the patch, rebuilt, tested, shipped, and reached your endpoints.
A use-after-free bug in that territory is not automatically equivalent to remote code execution from a tab. The CVE language matters: an attacker first needed to compromise the renderer process, and then could use a crafted HTML page to bypass site isolation. That is not the same as saying any webpage instantly owns the machine.
Still, the requirement that the renderer already be compromised should not comfort defenders too much. Modern browser attacks are chained. One bug gets code running where it should not; another breaks containment; a third improves reliability or persistence. CVE-2026-7910 is interesting because it lives in that chainable middle ground, where the browser’s defense-in-depth story is tested.
Site isolation was designed to make the browser less catastrophic when renderer compromise happens. It separates sites into different processes and limits the blast radius of a compromised renderer. A bug that helps bypass that boundary is not merely a UI bug; it is a pressure point against one of Chrome’s core security promises.
The important phrase is if the right chain exists. The public description does not say this vulnerability is known to be exploited in the wild. It also does not say the bug alone provides a full sandbox escape or native code execution outside the browser. It says a remote attacker who had already compromised the renderer could bypass site isolation through crafted HTML.
That distinction matters for patch prioritization, not because the bug can be ignored, but because defenders need to understand what they are patching against. CVSS is a severity scoring system, not a narrative of observed attacks. A 9.6 score can describe a dangerous component in a theoretical chain even when no public exploitation has been confirmed.
For enterprise IT, the right operational interpretation is neither panic nor indifference. Treat the update as urgent because browsers are high-frequency attack surfaces and because isolation bypasses are valuable to attackers. But do not confuse the CVE text with evidence of a live campaign unless a vendor or trusted incident source says one exists.
That broader context is important because CVE-2026-7910 is not traveling alone. The release also included critical-class bugs and a familiar scatter of memory safety issues across the Chromium codebase. If you are trying to decide whether to make this a helpdesk fire drill, the answer should be based on the whole release, not one CVE entry.
Browser security has become a conveyor belt. Individual CVEs are useful for tracking, scoring, and compliance reporting, but the reality on endpoints is version-based. A machine either has the fixed browser build or it does not. The distinction between CVE-2026-7910 and its neighbors matters for researchers; for most administrators, the actionable unit is Chrome 148.0.7778.96 or later.
This is also why “we patched Windows” is not enough. Chrome updates on its own cadence. Edge updates on a related but separate cadence. Third-party Chromium browsers update according to their own channels. If your vulnerability management stack collapses all of that into a generic “browser risk,” it will miss the operational detail that actually determines exposure.
This distinction matters because Windows administrators often encounter these entries through Microsoft tooling first. A CVE may appear in MSRC, Defender vulnerability management, Intune reports, or enterprise dashboards and look like part of the Microsoft patch universe. In reality, it may be an upstream Chromium issue that Microsoft is surfacing because Edge inherits the affected code.
That is not a criticism of Microsoft. It is the right thing for Microsoft to do. Edge users need visibility into Chromium-origin vulnerabilities, and Microsoft’s security ecosystem is often where Windows shops first see them. But the remediation path still depends on the affected browser product and channel.
The practical question for a WindowsForum audience is therefore not “Is this a Windows bug?” It is “Which Chromium-based browser binaries are deployed in my environment, and which of them have consumed the fixed upstream code?” That is a less convenient question, but it is the one that maps to actual risk.
That boundary is especially valuable against speculative execution attacks, cross-site data theft, and post-renderer-compromise abuse. It does not make renderer bugs harmless. It makes successful exploitation less immediately useful. In the economics of browser exploitation, that matters.
A site isolation bypass threatens that economics. It can turn a renderer foothold into broader access to data that should have been segregated. It may help an attacker move from “I compromised this rendering context” to “I can reach across boundaries the browser was designed to enforce.”
That is why the CVE’s wording deserves more weight than the component name suggests. “Views” sounds like interface code. “Bypass site isolation” sounds like a defense boundary bending. The second phrase is the one security teams should underline.
Chromium has invested heavily in memory safety mitigations, sandboxing, fuzzing, and architectural hardening. Those investments matter. They have made exploitation harder and increased the cost of reliable attacks. But “harder” is not “gone,” and every Chrome security release is a public ledger of the remaining attack surface.
The interesting part is that these bugs now often live inside layered defenses. A memory safety issue may not be enough by itself. It may need a renderer compromise, a type confusion, an information leak, a sandbox escape, or a logic flaw beside it. CVE-2026-7910’s description reads exactly like that modern browser-security grammar.
For defenders, this means patching cannot be reduced to waiting for “actively exploited” labels. Attackers chain bugs privately before the public understands the chain. By the time a single CVE becomes famous, the exploitation strategy may already have moved.
For Microsoft Edge, administrators should check Edge’s own stable-channel release notes and deployed build numbers rather than assuming Chrome’s fixed build number maps one-to-one. Edge consumes Chromium, but it is not Chrome with a different icon. Its versioning, release timing, and enterprise controls differ.
Managed environments should also account for Extended Stable channels, browser relaunch deferrals, and update policies that intentionally slow rollouts. A browser can download an update and still remain vulnerable until it restarts. In enterprises where uptime habits keep browsers open for days, the gap between “update available” and “update applied” is often wider than dashboards imply.
The consumer fix is simpler. Open the browser’s About page, let the update complete, and restart. The enterprise fix is less romantic: query versions, enforce relaunch, watch failures, and verify after the patch window. Browser security is now operational hygiene.
That does not mean CPE is broken. It means CPE is not an asset inventory. A CPE can describe a vulnerable product line; it cannot reliably tell you which embedded browser runtimes are present inside your line-of-business applications, which user-installed Chromium fork slipped past policy, or which Electron app bundles an outdated engine.
This is where vulnerability management programs often overestimate their coverage. They match a CVE to Chrome, patch Chrome, and close the ticket. Meanwhile, Edge may be handled by a different policy, Brave may be unmanaged, and Electron applications may continue carrying old Chromium code under vendor-controlled update schedules.
The hard part is not knowing that Chrome before 148.0.7778.96 is vulnerable. The hard part is proving that no vulnerable Chromium code remains where users can reach hostile content. That is a much more ambitious inventory problem than a single NVD entry can solve.
The browser is now the front door to SaaS, identity flows, device management portals, admin consoles, code repositories, financial systems, and internal dashboards. It holds session tokens, mediates authentication, renders untrusted content, and bridges local devices to cloud services. A browser isolation bypass is therefore not a narrow desktop concern.
Windows administrators should think of browser patching the way they think of identity hardening. It is not glamorous, but it is foundational. The browser is where phishing, drive-by exploitation, malicious documents, OAuth abuse, and session theft often converge.
That makes CVE-2026-7910 a useful forcing function. Even if this specific vulnerability never becomes a famous exploit, it tests whether an organization can answer basic questions quickly: which browsers are installed, which versions are running, who is lagging behind, and whether updates require a restart that users keep postponing.
For CVE-2026-7910, the exposure is broad because Chrome is ubiquitous. The exploitation requirement is more complex because the attacker needs renderer compromise first. The impact is serious because the described outcome involves bypassing site isolation. The remediation is straightforward because fixed Chrome builds are available.
That combination argues for rapid patching and verification, not emergency theater. Security teams should communicate the risk clearly without overstating it. “This is a serious Chromium security fix in Chrome 148; make sure Chrome and Chromium-based browsers are updated and restarted” is better than “critical Chrome zero-day” if there is no evidence of active exploitation.
Precision matters because users eventually tune out exaggerated alerts. When everything is a zero-day apocalypse, nothing is. CVE-2026-7910 is serious enough on its own terms; it does not need embellishment.
That diversity is not inherently bad. Chromium’s shared engine has produced fast security improvements and a common hardening baseline. But shared foundations also create shared exposure. When upstream Chromium fixes a memory safety bug, the downstream question becomes urgent: who has shipped the fix, and who is still building?
Edge deserves special attention because it is both deeply present in Windows environments and managed through Microsoft’s enterprise ecosystem. A Windows admin may never have intentionally deployed Chrome and still have a Chromium-based browser estate. That reality changes what “browser patching” means in a Microsoft shop.
The best organizations already know this. They track Edge and Chrome separately, enforce update policies, and validate actual executable versions. The weaker ones wait for monthly patch cycles and hope the browser auto-updater quietly did the right thing.
That long tail is where chained vulnerabilities become especially dangerous. A bug like CVE-2026-7910 may not be the first link in a chain, but it can be a useful later link if the attacker finds a renderer compromise elsewhere. The longer old builds remain in circulation, the more time attackers have to study patches and infer the fixed bug.
Patch diffing is not magic, but it is real. Once a fix ships, capable researchers and attackers can compare old and new code to understand what changed. Restricted bug trackers slow public understanding, but they do not erase the clues embedded in source changes and binaries.
This is the paradox of browser patching. Vendors must ship quickly to protect users, but the act of shipping starts a race. Defenders win by shortening the time between release, deployment, restart, and verification.
For WindowsForum readers, the concrete lessons are narrow but useful:
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
The Database Got the Chrome CPE Right, but the Browser World Moved On
The NVD entry for CVE-2026-7910 describes a use-after-free issue in Chrome’s Views component before 148.0.7778.96. In NVD’s enrichment, the vulnerable application is represented as Google Chrome versions before that build, with operating systems listed as the platforms on which the affected application runs. That is a normal CPE modeling pattern, even if it looks odd when rendered as an “AND” tree.So if the question is whether the Chrome product CPE is missing, the answer is no. The CPE shown for
google:chrome up to but excluding 148.0.7778.96 is the central affected software configuration. The Windows, Linux kernel, and macOS CPEs are not substitutes for the browser CPE; they narrow the platform context.But this is where the tidy world of vulnerability metadata collides with how people actually run browsers in 2026. Most users do not experience Chromium as an abstract upstream project. They experience it as Google Chrome, Microsoft Edge, Brave, Vivaldi, Opera, Electron apps, embedded webviews, kiosk shells, and managed browsers inside virtual desktops.
That is why security teams often feel as if a CPE is missing even when the database is technically correct. The CPE entry tells you where the originating vendor fixed the bug. It does not automatically tell you whether every Chromium downstream has pulled the patch, rebuilt, tested, shipped, and reached your endpoints.
Views Sounds Boring Until It Sits Beside Site Isolation
The word “Views” does not have the headline electricity of V8, WebRTC, Skia, or Blink. It sounds like plumbing, and in browser security, plumbing often gets underrated until it fails. Chrome’s Views framework is part of the browser UI architecture, the layer that helps build and manage interface elements across desktop platforms.A use-after-free bug in that territory is not automatically equivalent to remote code execution from a tab. The CVE language matters: an attacker first needed to compromise the renderer process, and then could use a crafted HTML page to bypass site isolation. That is not the same as saying any webpage instantly owns the machine.
Still, the requirement that the renderer already be compromised should not comfort defenders too much. Modern browser attacks are chained. One bug gets code running where it should not; another breaks containment; a third improves reliability or persistence. CVE-2026-7910 is interesting because it lives in that chainable middle ground, where the browser’s defense-in-depth story is tested.
Site isolation was designed to make the browser less catastrophic when renderer compromise happens. It separates sites into different processes and limits the blast radius of a compromised renderer. A bug that helps bypass that boundary is not merely a UI bug; it is a pressure point against one of Chrome’s core security promises.
The CVSS Score Is Loud, but the Exploit Story Is More Nuanced
NVD’s CVSS 3.1 score for CVE-2026-7910 is 9.6, which lands in critical territory. That score reflects network attackability, low attack complexity, no privileges required, user interaction required, changed scope, and high impacts to confidentiality, integrity, and availability. In plain English, if the right chain exists, the consequences are severe.The important phrase is if the right chain exists. The public description does not say this vulnerability is known to be exploited in the wild. It also does not say the bug alone provides a full sandbox escape or native code execution outside the browser. It says a remote attacker who had already compromised the renderer could bypass site isolation through crafted HTML.
That distinction matters for patch prioritization, not because the bug can be ignored, but because defenders need to understand what they are patching against. CVSS is a severity scoring system, not a narrative of observed attacks. A 9.6 score can describe a dangerous component in a theoretical chain even when no public exploitation has been confirmed.
For enterprise IT, the right operational interpretation is neither panic nor indifference. Treat the update as urgent because browsers are high-frequency attack surfaces and because isolation bypasses are valuable to attackers. But do not confuse the CVE text with evidence of a live campaign unless a vendor or trusted incident source says one exists.
Chrome 148 Was a Security Release Wearing a Version Number
Chrome 148’s desktop stable release was not a tiny one-bug patch. Google’s release notes for the May 5 stable-channel update listed the move to 148.0.7778.96 on Linux and 148.0.7778.96/97 on Windows and macOS, with a large bundle of security fixes. Several public summaries counted more than 100 vulnerabilities addressed in the release.That broader context is important because CVE-2026-7910 is not traveling alone. The release also included critical-class bugs and a familiar scatter of memory safety issues across the Chromium codebase. If you are trying to decide whether to make this a helpdesk fire drill, the answer should be based on the whole release, not one CVE entry.
Browser security has become a conveyor belt. Individual CVEs are useful for tracking, scoring, and compliance reporting, but the reality on endpoints is version-based. A machine either has the fixed browser build or it does not. The distinction between CVE-2026-7910 and its neighbors matters for researchers; for most administrators, the actionable unit is Chrome 148.0.7778.96 or later.
This is also why “we patched Windows” is not enough. Chrome updates on its own cadence. Edge updates on a related but separate cadence. Third-party Chromium browsers update according to their own channels. If your vulnerability management stack collapses all of that into a generic “browser risk,” it will miss the operational detail that actually determines exposure.
Microsoft’s Appearance in the Story Is About Edge, Not Ownership
The user-supplied source points to Microsoft’s Security Update Guide page for CVE-2026-7910, which is unsurprising. Microsoft tracks Chromium vulnerabilities because Microsoft Edge is Chromium-based, and the Edge security story depends in part on upstream Chromium fixes. But that does not turn a Chrome CVE into a Windows operating system vulnerability.This distinction matters because Windows administrators often encounter these entries through Microsoft tooling first. A CVE may appear in MSRC, Defender vulnerability management, Intune reports, or enterprise dashboards and look like part of the Microsoft patch universe. In reality, it may be an upstream Chromium issue that Microsoft is surfacing because Edge inherits the affected code.
That is not a criticism of Microsoft. It is the right thing for Microsoft to do. Edge users need visibility into Chromium-origin vulnerabilities, and Microsoft’s security ecosystem is often where Windows shops first see them. But the remediation path still depends on the affected browser product and channel.
The practical question for a WindowsForum audience is therefore not “Is this a Windows bug?” It is “Which Chromium-based browser binaries are deployed in my environment, and which of them have consumed the fixed upstream code?” That is a less convenient question, but it is the one that maps to actual risk.
Site Isolation Changed the Stakes for Browser Bugs
To understand why this CVE is worth attention, it helps to remember what site isolation was supposed to buy. The old browser model treated a renderer compromise as dangerous, but many sites and frames could still share process boundaries in ways that made cross-site data exposure easier. Site isolation hardened that model by making process separation a central security boundary.That boundary is especially valuable against speculative execution attacks, cross-site data theft, and post-renderer-compromise abuse. It does not make renderer bugs harmless. It makes successful exploitation less immediately useful. In the economics of browser exploitation, that matters.
A site isolation bypass threatens that economics. It can turn a renderer foothold into broader access to data that should have been segregated. It may help an attacker move from “I compromised this rendering context” to “I can reach across boundaries the browser was designed to enforce.”
That is why the CVE’s wording deserves more weight than the component name suggests. “Views” sounds like interface code. “Bypass site isolation” sounds like a defense boundary bending. The second phrase is the one security teams should underline.
Use-After-Free Remains the Browser Bug That Refuses to Retire
Use-after-free vulnerabilities are old, well-understood, and stubbornly persistent. They happen when software continues using memory after it has been freed, creating opportunities for crashes, corruption, or attacker-controlled behavior. In large C++ codebases, especially those juggling asynchronous events, UI lifecycles, and cross-process messaging, these bugs are hard to eliminate completely.Chromium has invested heavily in memory safety mitigations, sandboxing, fuzzing, and architectural hardening. Those investments matter. They have made exploitation harder and increased the cost of reliable attacks. But “harder” is not “gone,” and every Chrome security release is a public ledger of the remaining attack surface.
The interesting part is that these bugs now often live inside layered defenses. A memory safety issue may not be enough by itself. It may need a renderer compromise, a type confusion, an information leak, a sandbox escape, or a logic flaw beside it. CVE-2026-7910’s description reads exactly like that modern browser-security grammar.
For defenders, this means patching cannot be reduced to waiting for “actively exploited” labels. Attackers chain bugs privately before the public understands the chain. By the time a single CVE becomes famous, the exploitation strategy may already have moved.
Version Numbers Beat Vulnerability Poetry
The most reliable remediation check for CVE-2026-7910 is mundane: verify that Chrome is at 148.0.7778.96 or later on Linux, and at the fixed 148.0.7778.96/97 line or later on Windows and macOS. That is less exciting than parsing CVSS vectors, but it is what closes the exposure for Google Chrome.For Microsoft Edge, administrators should check Edge’s own stable-channel release notes and deployed build numbers rather than assuming Chrome’s fixed build number maps one-to-one. Edge consumes Chromium, but it is not Chrome with a different icon. Its versioning, release timing, and enterprise controls differ.
Managed environments should also account for Extended Stable channels, browser relaunch deferrals, and update policies that intentionally slow rollouts. A browser can download an update and still remain vulnerable until it restarts. In enterprises where uptime habits keep browsers open for days, the gap between “update available” and “update applied” is often wider than dashboards imply.
The consumer fix is simpler. Open the browser’s About page, let the update complete, and restart. The enterprise fix is less romantic: query versions, enforce relaunch, watch failures, and verify after the patch window. Browser security is now operational hygiene.
The CPE Question Exposes a Bigger Inventory Problem
CPEs were built for a world where software products had cleaner boundaries. They are still useful, but they struggle with shared engines and fast-moving upstream dependencies. Chromium has made that limitation obvious. One upstream vulnerability can fan out into multiple products, while each downstream vendor ships on its own clock.That does not mean CPE is broken. It means CPE is not an asset inventory. A CPE can describe a vulnerable product line; it cannot reliably tell you which embedded browser runtimes are present inside your line-of-business applications, which user-installed Chromium fork slipped past policy, or which Electron app bundles an outdated engine.
This is where vulnerability management programs often overestimate their coverage. They match a CVE to Chrome, patch Chrome, and close the ticket. Meanwhile, Edge may be handled by a different policy, Brave may be unmanaged, and Electron applications may continue carrying old Chromium code under vendor-controlled update schedules.
The hard part is not knowing that Chrome before 148.0.7778.96 is vulnerable. The hard part is proving that no vulnerable Chromium code remains where users can reach hostile content. That is a much more ambitious inventory problem than a single NVD entry can solve.
Windows Shops Should Treat Browsers as Tier-One Infrastructure
For years, browsers were treated like productivity applications. They were important, but they sat below operating systems, identity providers, VPN clients, and endpoint security tools in the hierarchy of infrastructure seriousness. That model no longer fits.The browser is now the front door to SaaS, identity flows, device management portals, admin consoles, code repositories, financial systems, and internal dashboards. It holds session tokens, mediates authentication, renders untrusted content, and bridges local devices to cloud services. A browser isolation bypass is therefore not a narrow desktop concern.
Windows administrators should think of browser patching the way they think of identity hardening. It is not glamorous, but it is foundational. The browser is where phishing, drive-by exploitation, malicious documents, OAuth abuse, and session theft often converge.
That makes CVE-2026-7910 a useful forcing function. Even if this specific vulnerability never becomes a famous exploit, it tests whether an organization can answer basic questions quickly: which browsers are installed, which versions are running, who is lagging behind, and whether updates require a restart that users keep postponing.
The Right Response Is Faster Verification, Not Louder Panic
The security industry has trained users to react to CVEs with a kind of emotional weather system: critical means storm, high means rain, medium means clouds. That is understandable, but it is not enough. A mature response ties severity to exploitability, exposure, compensating controls, and time-to-remediate.For CVE-2026-7910, the exposure is broad because Chrome is ubiquitous. The exploitation requirement is more complex because the attacker needs renderer compromise first. The impact is serious because the described outcome involves bypassing site isolation. The remediation is straightforward because fixed Chrome builds are available.
That combination argues for rapid patching and verification, not emergency theater. Security teams should communicate the risk clearly without overstating it. “This is a serious Chromium security fix in Chrome 148; make sure Chrome and Chromium-based browsers are updated and restarted” is better than “critical Chrome zero-day” if there is no evidence of active exploitation.
Precision matters because users eventually tune out exaggerated alerts. When everything is a zero-day apocalypse, nothing is. CVE-2026-7910 is serious enough on its own terms; it does not need embellishment.
The Edge Case Is Every Chromium Derivative in the Fleet
The uncomfortable part for Windows environments is that Chrome is rarely the only Chromium story. Microsoft Edge is present by default on modern Windows systems. Developers may install Chrome Canary, Brave, Vivaldi, Opera, or specialized Chromium builds. Business applications may bundle embedded webviews or Electron runtimes.That diversity is not inherently bad. Chromium’s shared engine has produced fast security improvements and a common hardening baseline. But shared foundations also create shared exposure. When upstream Chromium fixes a memory safety bug, the downstream question becomes urgent: who has shipped the fix, and who is still building?
Edge deserves special attention because it is both deeply present in Windows environments and managed through Microsoft’s enterprise ecosystem. A Windows admin may never have intentionally deployed Chrome and still have a Chromium-based browser estate. That reality changes what “browser patching” means in a Microsoft shop.
The best organizations already know this. They track Edge and Chrome separately, enforce update policies, and validate actual executable versions. The weaker ones wait for monthly patch cycles and hope the browser auto-updater quietly did the right thing.
Exploit Chains Reward the Slowest Patchers
Attackers do not need every victim to be vulnerable forever. They need enough victims to remain vulnerable long enough. Browser updates are fast, but user restarts, enterprise rings, frozen VDI images, kiosk devices, and neglected lab systems create a long tail.That long tail is where chained vulnerabilities become especially dangerous. A bug like CVE-2026-7910 may not be the first link in a chain, but it can be a useful later link if the attacker finds a renderer compromise elsewhere. The longer old builds remain in circulation, the more time attackers have to study patches and infer the fixed bug.
Patch diffing is not magic, but it is real. Once a fix ships, capable researchers and attackers can compare old and new code to understand what changed. Restricted bug trackers slow public understanding, but they do not erase the clues embedded in source changes and binaries.
This is the paradox of browser patching. Vendors must ship quickly to protect users, but the act of shipping starts a race. Defenders win by shortening the time between release, deployment, restart, and verification.
The Small Chrome Entry That Reveals the Whole Browser Risk Model
CVE-2026-7910 is easy to summarize but harder to operationalize. It is a Chrome bug, fixed in a specific Chrome build, scored critically by NVD, and described by Chromium as high severity. It requires a compromised renderer, yet it targets a major containment boundary. It is simple enough for a vulnerability feed and complex enough to expose gaps in real asset management.For WindowsForum readers, the concrete lessons are narrow but useful:
- The NVD entry already includes the Google Chrome CPE for versions before 148.0.7778.96, so the obvious Chrome CPE is not missing.
- The operating-system CPEs in the NVD configuration describe supported platforms, not separate Windows, Linux, or macOS vulnerabilities.
- Google Chrome users should be on 148.0.7778.96/97 or later, depending on platform and channel.
- Microsoft Edge and other Chromium-derived browsers must be checked against their own vendor builds, not assumed safe because Chrome has patched.
- The phrase “renderer process already compromised” lowers the likelihood of one-click standalone exploitation, but the site-isolation bypass makes the bug valuable in chains.
- Browser update compliance should include restart enforcement, because a downloaded update does not necessarily mean the vulnerable process is gone.
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center