Google and Microsoft disclosed CVE-2026-8019 this week as a Chromium WebApp policy-enforcement flaw fixed in Google Chrome 148.0.7778.96, allowing a remote attacker to perform user-interface spoofing through a crafted HTML page. That sounds minor beside the critical memory-safety bugs in the same Chrome 148 wave, but it points at a messier browser-security reality. The modern browser is no longer just a renderer and a URL bar; it is an operating environment where web apps, install prompts, permission surfaces, and desktop integration all blur together. CVE-2026-8019 matters because UI trust is now part of the browser’s attack surface, not merely its decoration.
The most obvious way to misread CVE-2026-8019 is to stop at the word “Low.” Chromium’s own security severity for the flaw is low, and the available scoring does not describe a remote-code-execution catastrophe. The CISA ADP CVSS 3.1 vector puts it in medium territory at 5.4, with network attackability, low complexity, no privileges required, and user interaction required.
That is not a zero-click exploit chain. It is not a sandbox escape, and it is not the kind of V8 or Blink bug that sends incident-response teams scrambling before coffee. But UI spoofing vulnerabilities occupy a different corner of the risk map: they often do not break the machine so much as break the user’s ability to understand what the machine is asking them to do.
That distinction matters more in 2026 than it did a decade ago. Browsers increasingly ask users to make security decisions inside interfaces that look native, semi-native, or intentionally app-like. A flaw in WebApp policy enforcement is therefore not just a cosmetic problem; it is a failure in the boundary between content and trusted chrome.
The bug’s public description is deliberately sparse, as Chrome vulnerability notes often are before the update has reached enough users. We know the component is WebApp, the pre-fix browser is Chrome before 148.0.7778.96, and the attack primitive is UI spoofing via a crafted HTML page. That is enough to understand the class of problem, even if the exploit mechanics remain restricted.
The old browser security model was visually crude but conceptually helpful. There was a page, and there was the browser around it. The page could lie, but the browser’s own address bar, permission prompts, and window decorations were supposed to remain trustworthy.
Installable web apps complicate that bargain. They intentionally reduce browser furniture, mimic native app conventions, and let web content live in windows that users may not mentally classify as “a website.” That is the whole point of the feature, but it also means policy enforcement has to be exact. A small mistake can let untrusted content borrow authority from the shell around it.
CVE-2026-8019’s weakness classification, CWE-451, captures this neatly: user-interface misrepresentation of critical information. This is the category of bug where the user is not necessarily tricked by bad judgment, but by a system that presents information in a misleading or ambiguous way. When the interface is the security boundary, misrepresentation is not superficial.
The distinction is important for Windows users in particular. Windows has long trained people to trust certain visual rituals: app windows, taskbar icons, install prompts, account pickers, permission dialogs, and update notices. Browser-based web apps now participate in many of those rituals. If a crafted page can make one of those rituals ambiguous, the attacker gains leverage without ever needing kernel access.
That is why “user interaction required” should not lull anyone to sleep. A huge percentage of real-world compromise depends on user interaction: opening a document, granting a permission, entering credentials, clicking through a prompt, installing an app, or approving a sign-in. The security question is not whether a human has to act. It is whether the interface gives that human a fair chance to act wisely.
UI spoofing flaws attack that fair chance. They make the trustworthy parts of software harder to distinguish from the theatrical parts. The more app-like the web becomes, the less margin there is for sloppy enforcement.
That context matters because it puts CVE-2026-8019 in its proper operational frame. For home users, the correct action is not to triage this one CVE in isolation. It is to get Chrome onto the fixed 148 branch or later, because the same update contains a much broader security payload.
The critical bugs in the Chrome 148 batch are the sort that usually dominate headlines: integer overflow, use-after-free, renderer and remote-access-adjacent components. They are more technically dramatic and usually more directly exploitable for code execution. But the presence of those bugs should not make the WebApp UI flaw invisible.
In mature software, the attack surface is plural. Memory corruption gets the sirens, policy bypasses get the footnotes, and UI deception gets the shrug. Attackers do not have to respect that hierarchy. They combine what works.
This is not a knock on Edge. It is a description of the supply chain. Chromium-based Edge is Microsoft’s browser, but its rendering engine, web platform behavior, and many security fixes flow through a shared upstream ecosystem. When Chromium ships a WebApp fix, Microsoft has to translate that into the Edge servicing world, the Security Update Guide, enterprise deployment channels, and administrative expectations.
For IT departments, the practical result is that browser security is now a two-column spreadsheet. One column says Chrome. The other says Edge. The CVEs often rhyme, the fixes arrive on related timelines, and the vulnerable conditions may be similar enough that policy has to treat them as siblings.
This is where the phrase “Chromium-based” becomes operational rather than branding. The browser wars may still exist at the product layer, but vulnerability management sees a shared substrate. A Chrome CVE can become an Edge concern not because Microsoft did anything wrong, but because the modern browser stack is a federation.
CPE data is often treated as truth by scanners, dashboards, and compliance systems. In practice, it is a translation layer. It tries to map a vendor’s product, version range, platform scope, and vulnerability statement into a format machines can consume. That translation can lag, overgeneralize, or omit edge cases.
For a conventional installed browser, the mapping is fairly straightforward: Chrome before 148.0.7778.96 is vulnerable. But Chromium is not just Chrome. Enterprises may have Chromium embedded in applications, packaged in containers, bundled with automation tooling, used by PDF renderers, or carried inside Electron-based apps whose update path has nothing to do with Google Chrome’s stable channel.
That is why the CPE question should not be dismissed as bureaucratic noise. It is a reminder that vulnerability management starts with identifiers but cannot end there. If your inventory only sees “Google Chrome,” it may miss the places where Chromium-derived code is doing browser work without wearing a browser badge.
CVE-2026-8019 is fixed in Chrome, not in a particular website. That sounds clean. Yet the risky interaction may occur when a user treats a web app as if it were a local application, complete with its own windowing behavior and trust cues. Browser patching addresses the vulnerable enforcement logic, but the administrative question is broader: which web apps are allowed to become app-like in the first place?
Many organizations still have mature controls for executable installation and comparatively immature controls for web-app installation. A user may need approval to install a native password manager but can pin, install, or launch a web app that looks and behaves like business software. That asymmetry is not sustainable.
The fix is not to panic and disable everything app-like on the web. The fix is to admit that web-app installation is an application-control decision. If the interface can impersonate trust, then the right to create that interface belongs inside policy.
Modern attackers are excellent at manufacturing interaction. They use calendar invites, fake collaboration notices, document-sharing workflows, authentication prompts, help-desk impersonation, and compromised legitimate sites. They do not need every user to click. They need enough users to click.
This is especially true for UI spoofing. If the exploit path involves making a crafted HTML page appear to be something more authoritative than it is, then the whole attack is already designed around persuasion. The required user action is not a barrier; it is the payload’s destination.
That is why security teams should stop treating “requires user interaction” as a synonym for “low priority.” It should mean something narrower: patch urgency can be balanced against exploitability, but user-facing controls and awareness remain relevant. A vulnerability that depends on deception is still dangerous in an environment where deception is the dominant intrusion method.
That makes UI integrity a business-control issue. If the browser misrepresents a permission, origin, app identity, or window context, it can affect how users handle credentials and sensitive workflows. In a zero-trust architecture, the browser is often the place where trust is actually experienced.
This is where IT pros should resist the temptation to score the bug purely by worst-case technical impact. The published vector includes low confidentiality impact and low availability impact, with no integrity impact in the CISA ADP scoring. But UI spoofing may still contribute to credential theft, session abuse, or social-engineering chains that are not fully captured by a single CVE score.
CVSS is useful. It is not omniscient. It measures a vulnerability, not the imagination of the person weaponizing it.
For WindowsForum readers, the operational advice is familiar but still under-enforced. Automatic updates should be enabled. Managed fleets should verify deployment rather than assume it. Edge and Chrome should be treated as Tier 1 applications, not consumer conveniences. And restarts still matter, because a downloaded browser update is not the same thing as a running fixed browser.
The subtle operational trap is version fragmentation. Chrome 148.0.7778.96 is the important fixed floor named in the CVE description, while Windows and macOS also saw 148.0.7778.97 in the stable-channel release. Linux was listed at 148.0.7778.96. Those numbers are not trivia; they are what scanners, administrators, and help-desk scripts have to compare against.
Enterprise browser management has improved dramatically, but it still depends on boring discipline. Policies must be applied. Update services must not be disabled by golden images. VDI templates and kiosk systems must be refreshed. Containers and automation hosts that ship browsers for headless rendering must be included in the inventory.
The most reasonable posture is not prohibition; it is curation. Enterprises should decide which web apps are approved, how they are installed, and whether unmanaged sites can create standalone app experiences. Managed browsers can enforce many of these decisions, but only if security and endpoint teams agree that web-app installation is in scope.
This is particularly relevant in education, healthcare, call centers, and shared-device environments. Users in those settings are often trained to follow workflows quickly, not to inspect subtle browser-state indicators. A spoofed or ambiguous UI can do more damage when the workflow itself rewards speed.
Admins should also look beyond Chrome and Edge on the desktop. Chromium-powered components appear in testing tools, embedded browsers, app wrappers, and developer workflows. If those components render untrusted content, the same class of web-platform flaw can matter even outside the obvious browser icon.
The responsible reading is narrower. We should not invent a proof of concept. We should not claim active exploitation without evidence. We should not imply that CVE-2026-8019 lets attackers execute code when the public description says UI spoofing. The known facts are enough to justify patching without exaggeration.
This restraint matters because browser security communication has a credibility problem. Every Chrome update becomes “urgent,” every bug becomes “critical” in some headlines, and every user is told to update now. The advice may be correct, but the language becomes numbingly repetitive.
A better model is precision. CVE-2026-8019 is not the scariest bug in Chrome 148. It is a small window into a large shift: browser UI, web-app identity, and desktop trust are becoming inseparable. That is the story worth paying attention to.
The better debate is about assumptions. Many organizations still treat browser vulnerabilities as isolated renderer defects and browser updates as routine hygiene. CVE-2026-8019 shows that browser security now includes how apps are presented, how users interpret trust cues, and how policies constrain web content that wants to behave like installed software.
This is the direction of travel for the web. The browser is absorbing more application behavior, more identity behavior, and more operating-system behavior. Every step makes the user experience smoother. Every step also increases the cost of getting the trust boundary wrong.
Near-term action should be concrete and unromantic:
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
Chrome’s Low-Severity Bug Still Lands in a High-Stakes Place
The most obvious way to misread CVE-2026-8019 is to stop at the word “Low.” Chromium’s own security severity for the flaw is low, and the available scoring does not describe a remote-code-execution catastrophe. The CISA ADP CVSS 3.1 vector puts it in medium territory at 5.4, with network attackability, low complexity, no privileges required, and user interaction required.That is not a zero-click exploit chain. It is not a sandbox escape, and it is not the kind of V8 or Blink bug that sends incident-response teams scrambling before coffee. But UI spoofing vulnerabilities occupy a different corner of the risk map: they often do not break the machine so much as break the user’s ability to understand what the machine is asking them to do.
That distinction matters more in 2026 than it did a decade ago. Browsers increasingly ask users to make security decisions inside interfaces that look native, semi-native, or intentionally app-like. A flaw in WebApp policy enforcement is therefore not just a cosmetic problem; it is a failure in the boundary between content and trusted chrome.
The bug’s public description is deliberately sparse, as Chrome vulnerability notes often are before the update has reached enough users. We know the component is WebApp, the pre-fix browser is Chrome before 148.0.7778.96, and the attack primitive is UI spoofing via a crafted HTML page. That is enough to understand the class of problem, even if the exploit mechanics remain restricted.
The Browser Has Been Slowly Disappearing Into the App
Chrome’s WebApp machinery is one of the quiet success stories of the modern web platform. Progressive web apps, installable sites, standalone windows, custom icons, launch handlers, and desktop integration have made the browser feel less like a tab strip and more like an application runtime. For users, that can be elegant. For attackers, it creates new seams.The old browser security model was visually crude but conceptually helpful. There was a page, and there was the browser around it. The page could lie, but the browser’s own address bar, permission prompts, and window decorations were supposed to remain trustworthy.
Installable web apps complicate that bargain. They intentionally reduce browser furniture, mimic native app conventions, and let web content live in windows that users may not mentally classify as “a website.” That is the whole point of the feature, but it also means policy enforcement has to be exact. A small mistake can let untrusted content borrow authority from the shell around it.
CVE-2026-8019’s weakness classification, CWE-451, captures this neatly: user-interface misrepresentation of critical information. This is the category of bug where the user is not necessarily tricked by bad judgment, but by a system that presents information in a misleading or ambiguous way. When the interface is the security boundary, misrepresentation is not superficial.
UI Spoofing Is the Oldest Trick Wearing the Newest Costume
Security people have mocked “fake login page” attacks for years, often with good reason. A bad phishing page with a stretched logo and a suspicious domain is not the same thing as a browser vulnerability. But UI spoofing inside browser-controlled or app-like surfaces is not ordinary phishing. It is phishing with better stage lighting.The distinction is important for Windows users in particular. Windows has long trained people to trust certain visual rituals: app windows, taskbar icons, install prompts, account pickers, permission dialogs, and update notices. Browser-based web apps now participate in many of those rituals. If a crafted page can make one of those rituals ambiguous, the attacker gains leverage without ever needing kernel access.
That is why “user interaction required” should not lull anyone to sleep. A huge percentage of real-world compromise depends on user interaction: opening a document, granting a permission, entering credentials, clicking through a prompt, installing an app, or approving a sign-in. The security question is not whether a human has to act. It is whether the interface gives that human a fair chance to act wisely.
UI spoofing flaws attack that fair chance. They make the trustworthy parts of software harder to distinguish from the theatrical parts. The more app-like the web becomes, the less margin there is for sloppy enforcement.
Chrome 148 Was Not a One-Bug Story
CVE-2026-8019 arrived as part of the Chrome 148 stable-channel update for desktop, not as a lonely emergency patch. Google moved Chrome 148.0.7778.96 to Linux and 148.0.7778.96/97 to Windows and macOS, with the update carrying a long list of security fixes. Reporting on the release counted 127 security fixes and highlighted three critical vulnerabilities among them.That context matters because it puts CVE-2026-8019 in its proper operational frame. For home users, the correct action is not to triage this one CVE in isolation. It is to get Chrome onto the fixed 148 branch or later, because the same update contains a much broader security payload.
The critical bugs in the Chrome 148 batch are the sort that usually dominate headlines: integer overflow, use-after-free, renderer and remote-access-adjacent components. They are more technically dramatic and usually more directly exploitable for code execution. But the presence of those bugs should not make the WebApp UI flaw invisible.
In mature software, the attack surface is plural. Memory corruption gets the sirens, policy bypasses get the footnotes, and UI deception gets the shrug. Attackers do not have to respect that hierarchy. They combine what works.
Microsoft Edge Inherits the Chromium Weather
The user-facing source here is Microsoft’s Security Update Guide entry for CVE-2026-8019, which is why many Windows admins will encounter this first as an Edge item rather than a Chrome item. That is the unavoidable trade-off of Chromium’s dominance. Microsoft Edge gains the engineering scale of Chromium, but it also inherits a steady cadence of Chromium vulnerabilities.This is not a knock on Edge. It is a description of the supply chain. Chromium-based Edge is Microsoft’s browser, but its rendering engine, web platform behavior, and many security fixes flow through a shared upstream ecosystem. When Chromium ships a WebApp fix, Microsoft has to translate that into the Edge servicing world, the Security Update Guide, enterprise deployment channels, and administrative expectations.
For IT departments, the practical result is that browser security is now a two-column spreadsheet. One column says Chrome. The other says Edge. The CVEs often rhyme, the fixes arrive on related timelines, and the vulnerable conditions may be similar enough that policy has to treat them as siblings.
This is where the phrase “Chromium-based” becomes operational rather than branding. The browser wars may still exist at the product layer, but vulnerability management sees a shared substrate. A Chrome CVE can become an Edge concern not because Microsoft did anything wrong, but because the modern browser stack is a federation.
The CPE Oddity Is a Reminder That Vulnerability Data Is Not Reality
The NVD change history for CVE-2026-8019 includes a CPE configuration for Google Chrome versions before 148.0.7778.96 across Windows, Linux, and macOS. The page also shows the familiar “Are we missing a CPE here?” language while configurations load and settle. That small administrative detail is worth more attention than it usually gets.CPE data is often treated as truth by scanners, dashboards, and compliance systems. In practice, it is a translation layer. It tries to map a vendor’s product, version range, platform scope, and vulnerability statement into a format machines can consume. That translation can lag, overgeneralize, or omit edge cases.
For a conventional installed browser, the mapping is fairly straightforward: Chrome before 148.0.7778.96 is vulnerable. But Chromium is not just Chrome. Enterprises may have Chromium embedded in applications, packaged in containers, bundled with automation tooling, used by PDF renderers, or carried inside Electron-based apps whose update path has nothing to do with Google Chrome’s stable channel.
That is why the CPE question should not be dismissed as bureaucratic noise. It is a reminder that vulnerability management starts with identifiers but cannot end there. If your inventory only sees “Google Chrome,” it may miss the places where Chromium-derived code is doing browser work without wearing a browser badge.
WebApp Bugs Expose the Gap Between Browser Patching and App Governance
Progressive web apps have always sat awkwardly between website and application governance. A normal website can change instantly on the server side. A native application has an installed version, a package identity, and some predictable management hooks. A web app can borrow from both models, which is powerful until security teams need to answer a simple question: what exactly are we patching?CVE-2026-8019 is fixed in Chrome, not in a particular website. That sounds clean. Yet the risky interaction may occur when a user treats a web app as if it were a local application, complete with its own windowing behavior and trust cues. Browser patching addresses the vulnerable enforcement logic, but the administrative question is broader: which web apps are allowed to become app-like in the first place?
Many organizations still have mature controls for executable installation and comparatively immature controls for web-app installation. A user may need approval to install a native password manager but can pin, install, or launch a web app that looks and behaves like business software. That asymmetry is not sustainable.
The fix is not to panic and disable everything app-like on the web. The fix is to admit that web-app installation is an application-control decision. If the interface can impersonate trust, then the right to create that interface belongs inside policy.
User Interaction Is Not a Safety Net
The CVSS vector’s user-interaction requirement is technically accurate and operationally misleading. It tells exploit writers that the bug is not self-triggering in the most severe sense. It does not tell defenders much about whether users are likely to encounter plausible lures.Modern attackers are excellent at manufacturing interaction. They use calendar invites, fake collaboration notices, document-sharing workflows, authentication prompts, help-desk impersonation, and compromised legitimate sites. They do not need every user to click. They need enough users to click.
This is especially true for UI spoofing. If the exploit path involves making a crafted HTML page appear to be something more authoritative than it is, then the whole attack is already designed around persuasion. The required user action is not a barrier; it is the payload’s destination.
That is why security teams should stop treating “requires user interaction” as a synonym for “low priority.” It should mean something narrower: patch urgency can be balanced against exploitability, but user-facing controls and awareness remain relevant. A vulnerability that depends on deception is still dangerous in an environment where deception is the dominant intrusion method.
The Enterprise Risk Is Not One Spoofed Window
For a single consumer machine, the remediation story is refreshingly boring: update Chrome, restart it, and move on. For an enterprise, the interesting question is what CVE-2026-8019 says about browser control planes. The browser has become the front door to identity, SaaS, device management, collaboration, finance, source code, and internal tooling.That makes UI integrity a business-control issue. If the browser misrepresents a permission, origin, app identity, or window context, it can affect how users handle credentials and sensitive workflows. In a zero-trust architecture, the browser is often the place where trust is actually experienced.
This is where IT pros should resist the temptation to score the bug purely by worst-case technical impact. The published vector includes low confidentiality impact and low availability impact, with no integrity impact in the CISA ADP scoring. But UI spoofing may still contribute to credential theft, session abuse, or social-engineering chains that are not fully captured by a single CVE score.
CVSS is useful. It is not omniscient. It measures a vulnerability, not the imagination of the person weaponizing it.
Patch Cadence Has Become Browser Governance
The Chrome 148 release reinforces the uncomfortable truth that browser patching is now one of the highest-frequency chores in endpoint security. The cadence is relentless because the browser is exposed, complex, and constantly changing. That is not a failure of Chrome or Edge; it is the price of making the web an application platform.For WindowsForum readers, the operational advice is familiar but still under-enforced. Automatic updates should be enabled. Managed fleets should verify deployment rather than assume it. Edge and Chrome should be treated as Tier 1 applications, not consumer conveniences. And restarts still matter, because a downloaded browser update is not the same thing as a running fixed browser.
The subtle operational trap is version fragmentation. Chrome 148.0.7778.96 is the important fixed floor named in the CVE description, while Windows and macOS also saw 148.0.7778.97 in the stable-channel release. Linux was listed at 148.0.7778.96. Those numbers are not trivia; they are what scanners, administrators, and help-desk scripts have to compare against.
Enterprise browser management has improved dramatically, but it still depends on boring discipline. Policies must be applied. Update services must not be disabled by golden images. VDI templates and kiosk systems must be refreshed. Containers and automation hosts that ship browsers for headless rendering must be included in the inventory.
The WebApp Surface Deserves Its Own Policy Review
CVE-2026-8019 should push administrators to look at WebApp settings, not merely browser versions. If users can install arbitrary web apps, pin them, and run them with minimal browser UI, then the organization has delegated part of its app-trust model to the open web. That may be acceptable, but it should be intentional.The most reasonable posture is not prohibition; it is curation. Enterprises should decide which web apps are approved, how they are installed, and whether unmanaged sites can create standalone app experiences. Managed browsers can enforce many of these decisions, but only if security and endpoint teams agree that web-app installation is in scope.
This is particularly relevant in education, healthcare, call centers, and shared-device environments. Users in those settings are often trained to follow workflows quickly, not to inspect subtle browser-state indicators. A spoofed or ambiguous UI can do more damage when the workflow itself rewards speed.
Admins should also look beyond Chrome and Edge on the desktop. Chromium-powered components appear in testing tools, embedded browsers, app wrappers, and developer workflows. If those components render untrusted content, the same class of web-platform flaw can matter even outside the obvious browser icon.
The Public Bug Details Are Sparse for a Reason
The Chromium issue linked from the CVE requires permission, which is normal for newly disclosed browser bugs. Vendors often restrict exploit details until most users have had time to update. That creates a temporary information vacuum, and the security internet predictably fills vacuums with guesswork.The responsible reading is narrower. We should not invent a proof of concept. We should not claim active exploitation without evidence. We should not imply that CVE-2026-8019 lets attackers execute code when the public description says UI spoofing. The known facts are enough to justify patching without exaggeration.
This restraint matters because browser security communication has a credibility problem. Every Chrome update becomes “urgent,” every bug becomes “critical” in some headlines, and every user is told to update now. The advice may be correct, but the language becomes numbingly repetitive.
A better model is precision. CVE-2026-8019 is not the scariest bug in Chrome 148. It is a small window into a large shift: browser UI, web-app identity, and desktop trust are becoming inseparable. That is the story worth paying attention to.
The Practical Lesson From Chrome 148 Is Bigger Than This CVE
For all the nuance, nobody should turn this into an academic exercise. If Chrome or a Chromium-based browser is below the fixed version, update it. If Edge surfaces the corresponding Chromium fix through Microsoft’s release process, deploy it. If vulnerability tooling flags CVE-2026-8019, do not spend a week debating whether “Low” means ignorable.The better debate is about assumptions. Many organizations still treat browser vulnerabilities as isolated renderer defects and browser updates as routine hygiene. CVE-2026-8019 shows that browser security now includes how apps are presented, how users interpret trust cues, and how policies constrain web content that wants to behave like installed software.
This is the direction of travel for the web. The browser is absorbing more application behavior, more identity behavior, and more operating-system behavior. Every step makes the user experience smoother. Every step also increases the cost of getting the trust boundary wrong.
The Fixed Version Is Only the First Line of Defense
Chrome 148 gives administrators a clean minimum version to chase, but the lasting defense is a policy posture that treats UI trust as managed infrastructure. That means version compliance is necessary, but not sufficient. It also means app-like web experiences deserve the same governance conversations as native software.Near-term action should be concrete and unromantic:
- Confirm that Google Chrome is updated to 148.0.7778.96 or later across Windows, macOS, and Linux endpoints.
- Verify that Microsoft Edge receives the corresponding Chromium security update through the organization’s normal Edge servicing channel.
- Include headless Chromium, automation images, VDI templates, kiosk builds, and bundled browser runtimes in vulnerability inventory.
- Review whether users are allowed to install or launch arbitrary web apps in standalone windows without administrative policy.
- Treat user-interaction requirements as a reason to improve UI-trust training, not as a reason to defer browser updates.
- Watch for scanner discrepancies around CPE data, especially where Chromium appears outside a standard Chrome installation.
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
