Google disclosed CVE-2026-8013 on May 6, 2026, as a low-severity Chrome FedCM input-validation flaw fixed before version 148.0.7778.96, where a crafted HTML page could let a remote attacker leak cross-origin data after user interaction. That sounds like a small browser bug, and in isolation it is. But it lands in a part of the web platform that is trying to make identity safer, less trackable, and less dependent on third-party cookies. The lesson for Windows shops is not panic; it is that browser identity plumbing is now security-critical infrastructure.
CVE-2026-8013 is not the sort of vulnerability that usually lights up dashboards in red. The reported impact is limited to confidentiality, the attack requires user interaction, and the Chromium security rating is Low even though CISA’s ADP scoring gives it a medium CVSS 3.1 base score of 4.3. There is no public indication in the available advisory text that this flaw is being exploited in the wild.
That is precisely why it is interesting. The bug lives in FedCM, the Federated Credential Management API, which is designed to let users sign in to websites through identity providers without recreating the free-for-all tracking patterns that third-party cookies enabled. In other words, this is not just another malformed HTML edge case; it is a weakness in one of the web’s attempted replacements for the old identity economy.
The reported failure mode is also telling. “Insufficient validation of untrusted input” is the kind of phrase that looks generic until it appears in a browser feature responsible for brokering trust across origins. If the browser is mediating between a relying party, an identity provider, and the user, input validation becomes more than sanitation. It becomes part of the browser’s promise that one site cannot learn what it should not know about another.
That makes FedCM security unusual. A memory-corruption flaw in a renderer is frightening because it can become code execution; an identity-flow bug is frightening because it can quietly change what a website is allowed to infer. The worst outcome is not always a shell. Sometimes it is a leak that lets one origin learn state, relationships, or identifiers that browser isolation was meant to hide.
CVE-2026-8013 appears modest because the described outcome is cross-origin data leakage rather than remote code execution. But cross-origin boundaries are one of the web’s oldest and most important safety rails. If browser vendors are going to ask websites to trust new identity primitives, then even low-severity leaks deserve more attention than their score alone suggests.
This is the broader story behind the CVE. The web is replacing an ugly, leaky, widely deployed login-and-tracking substrate with cleaner, more explicit APIs. That transition will inevitably expose bugs in new code paths, new UI mediation, and new assumptions about what “user interaction” really means.
That is normal. Security teams triage by exploitability, impact, and exposure, not by conceptual elegance. A low-rated FedCM leak will lose the headline contest against use-after-free bugs and renderer issues every time.
But patch bundles are political documents as much as technical ones. They tell us where code is moving, where researchers are looking, and where vendors expect future risk to accumulate. The presence of a FedCM validation flaw in a large Chrome security release is a reminder that identity APIs are no longer experimental ornaments hanging off the side of the browser. They are part of the main attack surface.
The timing matters for Windows administrators because Chrome’s update cadence has trained many organizations to treat browser patching as background noise. That automation is good, but it can also obscure which subsystems are being touched. When the patched subsystem is authentication, SSO, or cross-origin privacy enforcement, the browser update belongs in the same mental bucket as identity-provider changes and endpoint policy shifts.
This is the trade-off Microsoft accepted when it rebuilt Edge on Chromium. The company gained compatibility, extension support, and a seat at the modern web-platform table. It also accepted Chromium’s vulnerability rhythm: when Google ships a security train, Edge administrators have to watch for Microsoft’s corresponding train, not merely assume the same version number has already arrived.
In practice, Microsoft has become fairly quick at this dance, but “quick” is not the same as “instant.” Enterprises that standardize on Edge should track the Microsoft Edge release notes and MSRC entries directly, not just Google’s Chrome Releases blog or NVD. If a Chromium CVE affects a component present in Edge, the relevant question is when Microsoft’s stable and extended stable channels incorporate the fix.
This is particularly important in mixed-browser estates. A shop may have Chrome for developers, Edge for standard users, WebView2 inside business apps, and Chromium-based third-party browsers scattered across unmanaged corners of the fleet. The same upstream bug can have several downstream patch states at the same time.
This distinction matters when scanner output hits a ticket queue. If a vulnerability record shows Windows in a configuration tree, a harried analyst may route it to the OS team, when the practical fix is a browser update. The correct operational target is the installed browser version and channel, not the underlying operating system family.
The user-submitted note asks whether a CPE is missing. Based on the public NVD text, the Chrome application CPE is present, and the platform CPEs are part of the configuration logic. What may be missing from some enterprise views is not a CPE so much as downstream product mapping: Edge, Brave, Opera, embedded Chromium runtimes, Linux distribution packages, and managed browser channels may not all appear with the same clarity at the same moment.
That is where vulnerability management becomes less about CVE literacy and more about asset truth. A complete answer requires knowing which Chromium-derived products are in use, how they are updated, and whether scanners identify them as distinct products or as generic Chromium engines. The CVE record is the starting gun, not the finish line.
FedCM sits directly in that evolution. It tries to solve a problem created by the collapse of third-party cookies as an acceptable identity and advertising substrate. If a user wants to sign in to a news site using an account from an identity provider, the browser can no longer casually allow invisible cross-site state checks to do all the work. FedCM puts the browser in the middle, asking it to present controlled UI and enforce controlled data release.
That means browser bugs in identity components can have ambiguous blast radii. They may not hand an attacker control of the machine, but they can weaken the assumptions that applications, identity providers, and privacy models depend on. A cross-origin data leak sounds abstract until the leaked data is login state, account linkage, or a signal that helps deanonymize a user across contexts.
This is the web’s uncomfortable bargain. The browser is becoming more powerful in order to make the web less reckless. More power means more security responsibility, and more responsibility means small validation bugs can become strategically important.
A crafted HTML page is not an exotic delivery mechanism. It is the web. Attackers do not need a malware dropper to exploit a browser logic flaw if the vulnerable condition can be reached through ordinary browsing behavior.
The better interpretation is that this issue likely requires a setup that depends on the user being placed into a particular web context. That makes mass exploitation less likely than a drive-by renderer bug, but it does not make targeted exploitation impossible. In identity-adjacent features, targeted exploitation is often the scenario that matters most.
For administrators, the presence of user interaction should shape urgency, not erase it. This is not a shut-down-the-network event. It is a make-sure-your-browser-update-pipeline-is-working event, with special attention to users in high-risk roles who regularly interact with external portals, partner identity providers, admin consoles, and SaaS dashboards.
Chrome and Edge are designed around rapid update channels because browser risk moves quickly. A low-severity issue fixed today can become more interesting tomorrow if researchers reconstruct the patch, infer the bug, or combine it with another weakness. Browser vendors often restrict bug details until users have had time to update precisely because the patch itself can become a roadmap.
This does not mean every low CVE deserves a war room. It means organizations should not overfit patch priority to the label. For browsers, the default should be steady, fast, measured deployment, with rollback plans and telemetry rather than prolonged debate over individual CVSS decimals.
That is especially true for Chromium. The ecosystem’s strength is shared engineering; its weakness is shared exposure. A Chromium bug may begin as a Chrome advisory, appear in NVD, surface in MSRC for Edge, and then ripple through other products on timelines that are similar but not identical.
Chrome’s built-in updater can move quickly, but only if it is allowed to. Edge can be governed through Microsoft policies and enterprise tooling, but only if channels and update controls are configured sanely. Linux packages may depend on distribution maintainers or third-party repositories. VDI images, kiosk systems, lab machines, and rarely rebooted servers with browsers installed can drift silently.
CVE-2026-8013 is a useful test case because it is not dramatic. If your vulnerability program only functions when a CVE is catastrophic, it is not a program; it is an alarm bell. A low-to-medium browser issue should still be enough to verify that inventory, update policy, and reporting loops are working.
The more subtle gap is between browser and embedded browser. Windows environments increasingly rely on WebView2 for enterprise apps, management portals, sign-in experiences, and vendor software. Not every Chromium CVE maps cleanly to WebView2 risk, but the architectural dependence is close enough that mature teams should know how WebView2 runtime updates are handled and where they appear in inventory.
That changes how IT should read browser CVEs. A flaw in an identity-related browser feature is not simply a browser bug; it may affect the reliability of assumptions made by SaaS providers, IdPs, and privacy controls. Security teams should ask whether their login flows use the affected capability, but they should also recognize that web-platform features can be present even before an organization consciously standardizes on them.
FedCM adoption is still uneven, and many enterprise login flows remain rooted in traditional redirects, SAML, OIDC, cookies, and IdP-managed sessions. But browser vendors are clearly building toward a world where more identity ceremony is mediated locally. The risk surface is moving there whether every administrator has updated the architecture diagram or not.
This is why a small FedCM bug is worth writing about. It marks the place where privacy engineering, browser security, and enterprise authentication meet. That intersection will produce more CVEs, more policy knobs, and more difficult triage decisions.
For Chrome, the practical fixed baseline in the advisory is 148.0.7778.96 or later. For Windows and macOS, Google’s release also references 148.0.7778.97 in the stable channel. For Edge, the answer depends on Microsoft’s corresponding release state, which administrators should track through Microsoft’s Edge security release notes and MSRC rather than infer from Chrome alone.
The most common mistake is to assume that automatic updates equal completed updates. Browsers often stage updates before restart. Users can keep sessions open for days. Remote workers can miss management windows. Shared devices can accumulate stale processes. Vulnerability scanners then report what policy believed was solved last week.
This is where Windows management tooling earns its keep. Intune, Configuration Manager, Group Policy, enterprise browser management consoles, and endpoint detection tools should converge on the same answer: installed version, pending restart state, update channel, and policy compliance. If they do not, CVE-2026-8013 is a low-stakes opportunity to fix that visibility before a high-stakes Chromium bug arrives.
The concrete response is refreshingly boring. Update Chrome to the fixed build or later. Watch for the corresponding Edge update and deploy it when available. Confirm that managed devices have actually received and activated the update. Keep an eye on downstream Chromium-based browsers if they exist in your estate.
There is also a policy response. Organizations should avoid freezing browser versions unless they have a compelling compatibility reason and a compensating security plan. The web platform changes too quickly, and attackers pay too much attention to browser patches, for long browser deferrals to be a casual administrative convenience.
The best browser patching programs look less like monthly ceremonies and more like controlled rolling delivery. They test quickly, stage broadly, force relaunches when risk justifies it, and retain enough telemetry to prove the fleet moved. That is not glamorous work, but it is exactly the work that turns a CVE from a headline into a closed loop.
Here is the practical read for WindowsForum readers:
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
A Low-Severity Bug in a High-Leverage Corner of the Web
CVE-2026-8013 is not the sort of vulnerability that usually lights up dashboards in red. The reported impact is limited to confidentiality, the attack requires user interaction, and the Chromium security rating is Low even though CISA’s ADP scoring gives it a medium CVSS 3.1 base score of 4.3. There is no public indication in the available advisory text that this flaw is being exploited in the wild.That is precisely why it is interesting. The bug lives in FedCM, the Federated Credential Management API, which is designed to let users sign in to websites through identity providers without recreating the free-for-all tracking patterns that third-party cookies enabled. In other words, this is not just another malformed HTML edge case; it is a weakness in one of the web’s attempted replacements for the old identity economy.
The reported failure mode is also telling. “Insufficient validation of untrusted input” is the kind of phrase that looks generic until it appears in a browser feature responsible for brokering trust across origins. If the browser is mediating between a relying party, an identity provider, and the user, input validation becomes more than sanitation. It becomes part of the browser’s promise that one site cannot learn what it should not know about another.
FedCM Exists Because the Old Login Model Was Too Useful to Kill
The modern browser is caught between two incompatible demands. Users and regulators want less ambient tracking, while websites still want frictionless sign-in, fraud controls, personalization, and account recovery. FedCM is one of Chromium’s answers to that tension: move more of the identity dance into a browser-mediated flow, so federated login can survive the decline of third-party cookies.That makes FedCM security unusual. A memory-corruption flaw in a renderer is frightening because it can become code execution; an identity-flow bug is frightening because it can quietly change what a website is allowed to infer. The worst outcome is not always a shell. Sometimes it is a leak that lets one origin learn state, relationships, or identifiers that browser isolation was meant to hide.
CVE-2026-8013 appears modest because the described outcome is cross-origin data leakage rather than remote code execution. But cross-origin boundaries are one of the web’s oldest and most important safety rails. If browser vendors are going to ask websites to trust new identity primitives, then even low-severity leaks deserve more attention than their score alone suggests.
This is the broader story behind the CVE. The web is replacing an ugly, leaky, widely deployed login-and-tracking substrate with cleaner, more explicit APIs. That transition will inevitably expose bugs in new code paths, new UI mediation, and new assumptions about what “user interaction” really means.
Chrome 148 Was a Security Release With One Quiet Identity Footnote
Google’s Chrome 148 stable desktop update was not built around CVE-2026-8013. The release moved Chrome to 148.0.7778.96 on Linux and 148.0.7778.96 or 148.0.7778.97 on Windows and macOS, and it carried a much larger batch of security fixes. Reporting around the release has focused on the higher-severity issues, including critical flaws in Blink, Mobile, and Chromoting.That is normal. Security teams triage by exploitability, impact, and exposure, not by conceptual elegance. A low-rated FedCM leak will lose the headline contest against use-after-free bugs and renderer issues every time.
But patch bundles are political documents as much as technical ones. They tell us where code is moving, where researchers are looking, and where vendors expect future risk to accumulate. The presence of a FedCM validation flaw in a large Chrome security release is a reminder that identity APIs are no longer experimental ornaments hanging off the side of the browser. They are part of the main attack surface.
The timing matters for Windows administrators because Chrome’s update cadence has trained many organizations to treat browser patching as background noise. That automation is good, but it can also obscure which subsystems are being touched. When the patched subsystem is authentication, SSO, or cross-origin privacy enforcement, the browser update belongs in the same mental bucket as identity-provider changes and endpoint policy shifts.
Microsoft Edge Inherits the Chromium Clock, Not Just the Chromium Code
For WindowsForum readers, the obvious question is not only “Is Chrome fixed?” It is “What about Edge?” Microsoft’s own Edge security release notes for May 6 said Microsoft was aware of the recent Chromium security fixes and was actively working on releasing a security fix. That phrasing matters because Edge is Chromium-based, but it is not Chrome with a blue icon. Microsoft has to ingest, test, package, and ship Chromium changes through its own channels.This is the trade-off Microsoft accepted when it rebuilt Edge on Chromium. The company gained compatibility, extension support, and a seat at the modern web-platform table. It also accepted Chromium’s vulnerability rhythm: when Google ships a security train, Edge administrators have to watch for Microsoft’s corresponding train, not merely assume the same version number has already arrived.
In practice, Microsoft has become fairly quick at this dance, but “quick” is not the same as “instant.” Enterprises that standardize on Edge should track the Microsoft Edge release notes and MSRC entries directly, not just Google’s Chrome Releases blog or NVD. If a Chromium CVE affects a component present in Edge, the relevant question is when Microsoft’s stable and extended stable channels incorporate the fix.
This is particularly important in mixed-browser estates. A shop may have Chrome for developers, Edge for standard users, WebView2 inside business apps, and Chromium-based third-party browsers scattered across unmanaged corners of the fleet. The same upstream bug can have several downstream patch states at the same time.
NVD’s CPE Entry Is Technically Useful and Operationally Awkward
The NVD entry for CVE-2026-8013 lists Google Chrome versions before 148.0.7778.96 as affected and wraps that application CPE inside operating-system entries for Windows, Linux, and macOS. That is a familiar pattern, but it is also a frequent source of confusion for vulnerability managers. A Chrome vulnerability is not a Windows vulnerability merely because vulnerable Chrome can run on Windows.This distinction matters when scanner output hits a ticket queue. If a vulnerability record shows Windows in a configuration tree, a harried analyst may route it to the OS team, when the practical fix is a browser update. The correct operational target is the installed browser version and channel, not the underlying operating system family.
The user-submitted note asks whether a CPE is missing. Based on the public NVD text, the Chrome application CPE is present, and the platform CPEs are part of the configuration logic. What may be missing from some enterprise views is not a CPE so much as downstream product mapping: Edge, Brave, Opera, embedded Chromium runtimes, Linux distribution packages, and managed browser channels may not all appear with the same clarity at the same moment.
That is where vulnerability management becomes less about CVE literacy and more about asset truth. A complete answer requires knowing which Chromium-derived products are in use, how they are updated, and whether scanners identify them as distinct products or as generic Chromium engines. The CVE record is the starting gun, not the finish line.
The Browser Has Become the Identity Boundary
For years, enterprise security treated the browser as an application that opened dangerous things. That model is obsolete. The browser now enforces site isolation, manages passkeys, mediates identity providers, stores tokens, handles device-bound credentials, processes enterprise policy, and increasingly decides which flows are privacy-preserving enough to allow.FedCM sits directly in that evolution. It tries to solve a problem created by the collapse of third-party cookies as an acceptable identity and advertising substrate. If a user wants to sign in to a news site using an account from an identity provider, the browser can no longer casually allow invisible cross-site state checks to do all the work. FedCM puts the browser in the middle, asking it to present controlled UI and enforce controlled data release.
That means browser bugs in identity components can have ambiguous blast radii. They may not hand an attacker control of the machine, but they can weaken the assumptions that applications, identity providers, and privacy models depend on. A cross-origin data leak sounds abstract until the leaked data is login state, account linkage, or a signal that helps deanonymize a user across contexts.
This is the web’s uncomfortable bargain. The browser is becoming more powerful in order to make the web less reckless. More power means more security responsibility, and more responsibility means small validation bugs can become strategically important.
User Interaction Is a Mitigation, Not a Comfort Blanket
The CVSS vector attached by CISA’s ADP assessment includes user interaction. That reduces exploitability, but it should not lull anyone into treating the bug as irrelevant. Modern web attacks are often built around coaxing a click, triggering a navigation, embedding a frame, or presenting a page that looks routine enough for the user to proceed.A crafted HTML page is not an exotic delivery mechanism. It is the web. Attackers do not need a malware dropper to exploit a browser logic flaw if the vulnerable condition can be reached through ordinary browsing behavior.
The better interpretation is that this issue likely requires a setup that depends on the user being placed into a particular web context. That makes mass exploitation less likely than a drive-by renderer bug, but it does not make targeted exploitation impossible. In identity-adjacent features, targeted exploitation is often the scenario that matters most.
For administrators, the presence of user interaction should shape urgency, not erase it. This is not a shut-down-the-network event. It is a make-sure-your-browser-update-pipeline-is-working event, with special attention to users in high-risk roles who regularly interact with external portals, partner identity providers, admin consoles, and SaaS dashboards.
Low Does Not Mean Optional in a Rapid-Release Browser
There is a tendency in enterprise patching to reserve urgency for critical and high vulnerabilities, then let medium and low browser issues ride until the next maintenance window. That strategy made more sense when applications were updated monthly and browsers were less central to work. It makes less sense in 2026.Chrome and Edge are designed around rapid update channels because browser risk moves quickly. A low-severity issue fixed today can become more interesting tomorrow if researchers reconstruct the patch, infer the bug, or combine it with another weakness. Browser vendors often restrict bug details until users have had time to update precisely because the patch itself can become a roadmap.
This does not mean every low CVE deserves a war room. It means organizations should not overfit patch priority to the label. For browsers, the default should be steady, fast, measured deployment, with rollback plans and telemetry rather than prolonged debate over individual CVSS decimals.
That is especially true for Chromium. The ecosystem’s strength is shared engineering; its weakness is shared exposure. A Chromium bug may begin as a Chrome advisory, appear in NVD, surface in MSRC for Edge, and then ripple through other products on timelines that are similar but not identical.
Enterprise Risk Lives in the Gaps Between Channels
The hardest part of browser security is not updating a single browser on a single machine. It is understanding the lag between upstream fix, vendor release, enterprise approval, device check-in, user restart, and scanner verification. Every organization has a real patch timeline hiding underneath its policy timeline.Chrome’s built-in updater can move quickly, but only if it is allowed to. Edge can be governed through Microsoft policies and enterprise tooling, but only if channels and update controls are configured sanely. Linux packages may depend on distribution maintainers or third-party repositories. VDI images, kiosk systems, lab machines, and rarely rebooted servers with browsers installed can drift silently.
CVE-2026-8013 is a useful test case because it is not dramatic. If your vulnerability program only functions when a CVE is catastrophic, it is not a program; it is an alarm bell. A low-to-medium browser issue should still be enough to verify that inventory, update policy, and reporting loops are working.
The more subtle gap is between browser and embedded browser. Windows environments increasingly rely on WebView2 for enterprise apps, management portals, sign-in experiences, and vendor software. Not every Chromium CVE maps cleanly to WebView2 risk, but the architectural dependence is close enough that mature teams should know how WebView2 runtime updates are handled and where they appear in inventory.
The Identity Stack Is Now a Patch Dependency
Authentication used to be something the browser displayed. Now it is something the browser participates in. Passkeys, conditional UI, FedCM, enterprise SSO, platform authenticators, and token-binding-adjacent mechanisms all blur the boundary between “web app” and “client security control.”That changes how IT should read browser CVEs. A flaw in an identity-related browser feature is not simply a browser bug; it may affect the reliability of assumptions made by SaaS providers, IdPs, and privacy controls. Security teams should ask whether their login flows use the affected capability, but they should also recognize that web-platform features can be present even before an organization consciously standardizes on them.
FedCM adoption is still uneven, and many enterprise login flows remain rooted in traditional redirects, SAML, OIDC, cookies, and IdP-managed sessions. But browser vendors are clearly building toward a world where more identity ceremony is mediated locally. The risk surface is moving there whether every administrator has updated the architecture diagram or not.
This is why a small FedCM bug is worth writing about. It marks the place where privacy engineering, browser security, and enterprise authentication meet. That intersection will produce more CVEs, more policy knobs, and more difficult triage decisions.
Windows Administrators Need Browser Telemetry, Not Browser Faith
The consumer version of browser security is simple: update Chrome, update Edge, restart when prompted. Enterprise security requires more proof. Administrators need to know which machines are below the fixed version, which update channel they are on, which policies might delay updates, and whether users have actually relaunched the browser to complete installation.For Chrome, the practical fixed baseline in the advisory is 148.0.7778.96 or later. For Windows and macOS, Google’s release also references 148.0.7778.97 in the stable channel. For Edge, the answer depends on Microsoft’s corresponding release state, which administrators should track through Microsoft’s Edge security release notes and MSRC rather than infer from Chrome alone.
The most common mistake is to assume that automatic updates equal completed updates. Browsers often stage updates before restart. Users can keep sessions open for days. Remote workers can miss management windows. Shared devices can accumulate stale processes. Vulnerability scanners then report what policy believed was solved last week.
This is where Windows management tooling earns its keep. Intune, Configuration Manager, Group Policy, enterprise browser management consoles, and endpoint detection tools should converge on the same answer: installed version, pending restart state, update channel, and policy compliance. If they do not, CVE-2026-8013 is a low-stakes opportunity to fix that visibility before a high-stakes Chromium bug arrives.
The Real Patch Is a Faster Browser Supply Chain
CVE-2026-8013 should not send anyone into emergency mode. It should, however, prod organizations to examine how quickly browser fixes cross the distance from vendor advisory to protected endpoint. That distance is now one of the most important measures of desktop security maturity.The concrete response is refreshingly boring. Update Chrome to the fixed build or later. Watch for the corresponding Edge update and deploy it when available. Confirm that managed devices have actually received and activated the update. Keep an eye on downstream Chromium-based browsers if they exist in your estate.
There is also a policy response. Organizations should avoid freezing browser versions unless they have a compelling compatibility reason and a compensating security plan. The web platform changes too quickly, and attackers pay too much attention to browser patches, for long browser deferrals to be a casual administrative convenience.
The best browser patching programs look less like monthly ceremonies and more like controlled rolling delivery. They test quickly, stage broadly, force relaunches when risk justifies it, and retain enough telemetry to prove the fleet moved. That is not glamorous work, but it is exactly the work that turns a CVE from a headline into a closed loop.
The Small FedCM Leak That Tells a Bigger Windows Story
CVE-2026-8013 is easy to summarize and easy to underestimate. Its details point to a narrow input-validation failure, but its location points to the future of browser security: identity, privacy, and cross-origin mediation all squeezed into code that must work for billions of users and countless enterprise workflows.Here is the practical read for WindowsForum readers:
- Chrome users should be on version 148.0.7778.96 or later, with Windows and macOS fleets also recognizing Google’s 148.0.7778.97 stable build where applicable.
- Edge administrators should track Microsoft’s own security release notes and MSRC guidance, because Chromium fixes arrive through Microsoft’s release process rather than by assumption.
- Vulnerability teams should treat the NVD platform CPEs as context, not as proof that the Windows OS itself is the vulnerable component.
- Browser update compliance should include restart or relaunch state, because a downloaded browser update is not always an active browser update.
- Asset inventories should include Chromium-derived browsers and embedded runtimes, not merely Chrome and Edge as visible desktop applications.
- Security teams should watch identity-related browser APIs more closely as FedCM, passkeys, and browser-mediated sign-in become normal parts of enterprise authentication.
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
