Chrome FedCM Use-After-Free (CVE-2026-4680): Patch Before 146.0.7680.165

Google Chrome’s March 23, 2026 stable-channel security update closed a high-severity use-after-free in FedCM, tracked as CVE-2026-4680, and the affected builds were Chrome versions prior to 146.0.7680.165 on desktop. Google’s own release notes say the flaw could be reached through a crafted HTML page and could allow remote code execution inside the browser sandbox, which is exactly the kind of browser bug security teams treat as urgent rather than routine. Microsoft’s Security Update Guide mirrors the issue for downstream visibility, underscoring that this is not just a Chrome-only concern but part of the wider Chromium supply chain that also affects Chromium-based products and patch-tracking workflows. gleblog.com](Chrome Releases))

Overview​

FedCM stands for Federated Credential Management, a browser-mediated identity flow designed to reduce reliance on third-party cookies and redirects for sign-in. In practical terms, it is part of the modern authentication plumbing that sits between websites, identity providers, and the browser itself. That makes it a sensitive area: if the browser’s identity layer mishandles object lifetimes, the result can be memory corruption in a component that users and enterprises increasingly depend on for login flows.
The timing matters. Chrome 146 was already in a dense security cycle, with Google shipping multiple high-severity memory-safety fixes across the March 2026 stable channel. The March 23 desktop release listed eight security fixes, including CVE-2026-4680, while earlier and later March releases show the browser moving quickly through point updates as the team stabilized the 146 branch. That cadence is a reminder that modern browser hardening is less about one dramatic patch and more about continuous containment of a broad attack surface. (chromereleases.googleblog.com)
For Windows administrators, the significance is straightforward: Chrome is often the first place a Chromium fix appears, but Microsoft’s update guide is where many enterprise teams track the downstream exposure of Chromium-based software. The Microsoft entry for CVE-2026-4680 reinforces the upstream Chrome advisory and the Chromium issue tracker, which helps patch teams map a browser-engine fix to their own deployment s this is a classic upstream-to-downstream security event, not an isolated browser note.
The vulnerability classification also tells a familiar story. Use-after-free bugs remain among the most dangerous memory-safety failures in large codebases because they can be turned into controlled memory corruption if an attacker can shape heap behavior well enough. In a browser, the stakes are amplified by sandbox escape potential, site reachability, and the sheer number of users exposed to web content every day. (chromereleases.googleblog.com)

Why FedCM matters more than it sounds​

FedCM is not a fringe feature. Google’s own documentation positions it as the browser-native path for identity federation, and it is increasingly central to sign-in experiences that are being rebuilt for the post-third-party-cookie era. That means a bug in FedCM is not just a bug in an optional UI widget; it is a flaw in a strategic authentication surface that browsers are actively expanding.

• It sits close to identity and login flows.
• It is part of Chrome’s privacy-preserving federation strategy.
• It is exposed to untrusted web content by design.
• It can affect both consumer sign-ins and enterprise-authenticated workflows.

Background​

Chromium’s security model is built around layers: process isolation, sandboxing, site isolation, and a constant stream of code audits and fuzzing. Even so, browser components that process complex web content, graphics, media, or identity workflows remain persistent targets because they combine complicated state management with attacker-controlled input. FedCM adds another layer of complexity by inserting the browser into authentication decisions that historically lived in web pages and redirects. (chromereleases.googleblog.com)
The Chromium project’s March 2026 security disclosures show how broad that attack surface remains. The same stable branch that carried CVE-2026-4680 also carried fixes for flaws in WebAudio, WebGL, WebGPU, Fonts, and CSS, illustrating that memory safety issues are still distributed across the browser stack rather than concentrated in one obvious subsystem. That breadth matters because attackers often look for whichever component offers the best trade-off between reachability and exploitability. (chromereleases.googleblog.com)
FedCM itself is part of a longer privacy and identity transition. Google’s documentation describes the API as a way to provide federated sign-in without third-party cookies and to preserve privacy while keeping login flows usable. As Chrome has evolved through 2025 and 2026, more identity-related behavior has moved into browser-managed flows, which means a defect in this area can have wider implications than a bug in a single site’s login script.
This is also why the Microsoft Security Update Guide is important. Microsoft’ction as downstream tracking records for Chromium vulnerabilities, helping security teams understand whether Edge or other Chromium-based products have already absorbed the upstream fix. Microsoft has explained that its Security Update Guide is part of a broader transparency effort, and that it publishes vulnerability data so customers can accelerate remediation across their own environments.

The patch cadence tells the story​

The relevant Chrome version here is 146.0.7680.165, which Google shipped in the March 23 stable update. The fact that the vulnerability is listed among eight fixes in a single release shows how concentrated browser patch cycles can be when multiple high-severity issues land at once. For defenders, that makes version verification the operational first step, not a later housekeeping task. (chromereleases.googleblog.com)

• Chrome 146 received the FedCM fix in the March 23 stable update.
• The same release also addressed seven other security issues.
• Microsoft’s guide reflects the upstream issue for visibility in downstream products.
• ChromeOS and Android branches track the same general Chromium fix lineage, though build numbers differ by platform. (chromereleases.googleblog.com)

---

What CVE-2026-4680 Means Technically​

A use-after-free occurs when software continues to use memory after it has already been released. In a browser engine, that usually means an attacker has found a way to influence object lifetime, pointer reuse, or heap layout so that freed memory can be reused in a predictable way. Once that happens, what should have been a crash can become a write primitive, a read primitive, or a code-execution chain. (chromereleases.googleblog.com)
The CVE description says the issue in FedCM allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. That phrasing is important because it implies the exploit chain begins at web content rather than requiring local access, install privileges, or a native app. The browser sandbox still matters as a containment layer, but sandboxed code execution is not a benign outcome; it can be the first step in a larger exploit stack. (chromereleases.googleblog.com)

Why memory bugs still dominate browser headlines​

Browser vendors have invested heavily in exploit mitigations, but memory corruption keeps showing up because browsers are enormous, performance-sensitive, and constantly handling hostile input. Attackers do not need the entire browser to be vulnerable; they need one code path that can be forced into an unsafe lifetime state. That is why a “single-page” HTML trigger can still carry serious risk in 2026. (chromereleases.googleblog.com)

• Use-after-free bugs are often hard to detect in casual testing.
• They can be triggered through legitimate-looking content paths.
• They become especially dangerous when attacker-controlled web input is involved.
• Browser sandboxes reduce impact but do not eliminate exploit value. (chromereleases.googleblog.com)

The fact that the affected component is FedCM also changes the threat model. Identity flows often involve modal dialogs, browser mediation, token exchange, and state transitions between the web page and browser UI. Those transitions are precisely where object-lifetime bugs can hide, because the browser is juggling security policy, user intent, and asynchronous state at the same time.

Why FedCM Is a High-Value Attack Surface​

FedCM is designed to be privacy-preserving, but privacy-preserving does not mean attack-resistant by default. The feature mediates authentication in a browser-controlled flow, and that makes it a high-value target because identity is one of the most sensitive resources on the web. A flaw here can be more attractive to attackers than a flaw in a less privileged rendering path.
There is also a strategic reason this matters. As Chrome and the wider web ecosystem move away from third-party cookies, browser-mediated identity becomes more central rather than less. The more browsers are responsible for sign-in orchestration, the more security teams need confidence in the correctness of those orchestration layers. FedCM is therefore not just a product feature; it is part of the next-generation trust fabric of the web.

Identity flows are especially brittle​

Authentication paths often combine several properties that make bugs more serious than they first appear. They are stateful, they are user-facing, and they frequently involve cross-origin boundaries. If the browser mismanages memory in that environment, the impact can extend beyond a single site or a single tab.

• Sign-in flows have long-lived state transitions.
• They must coordinate browser UI and webpage logic.
• They often involve cross-origin messaging and policy enforcement.
• They are attractive targets because they handle credentials or credential-like assertions.

For consumers, that means a malicious page could potentially weaponize what looks like a normal login-related interaction. For enterprise can intersect with identity policy, managed accounts, and browser configurations that are often standardized across large fleets. The risk is not simply “a browser crash,” but a potentially reliable path to code execution in a feature area that organizations increasingly trust. (chromereleases.googleblog.com)

How Google and Microsoft Framed the Fix​

Googluage for the March 23 desktop update is clear enough: CVE-2026-4680 was part of the security fixes in Chrome 146.0.7680.164/165, and the higher patch level is the one relevant to the vulnerability. The issue appears in the list with the classhich aligns with the attacker model implied by the description. (chromereleases.googleblog.com)
Microsoft’s Security Update Guide entry mirrors that upstream disclosure and adds the downstream enterprise context that many administrators rely on. That is a subtle but important distinction: Microsoft is not claiming a separate vulnerability in Edge; it is surfacing the Chromium issue so customers can tell whether their downstream browser builds have absorbed the fix. That is exactly how Chromium CVEs often propagate through the Windows ecosystem.

Release notes versus operational reality​

Release notes tell you what was fixed. Operational reality tells you whether your endpoints are actually patched. In enterprises, those are not always the same question, because update rings, policy deferrals, disconnected devices, and embedded browser components can all slow ingestion. That is why downstream cataloging in the Microsoft guide matters so much.

• Google publishes the upstream fix first.
• Microsoft tracks the issue for Edge and related browser deployments.
• Administrators still need to verify installed version numbers.
• Patch deployment timing can vary materially across fleets.

The broader lesson is that browser CVEs increasingly travel through a supply chain, not just a product channel. A Chromium bug can become a Chrome issue, then an Edge tracking item, then a fleet-wide remediation task across managed endpoints. That chain is efficient when everything works and frustrating when one link lags.

Enterprise Impact​

Enterprises should view CVE-2026-4680 as a browser patching priority, not a background note. The combination of remote reachability, crafted web content, and a browser sandbox exploit path means this is the kind of issue that belongs in urgent remediation queues, especially on systems used for sign-in, HR, finance, and admin portals. A successful exploit does not need to start with a local foothold; it can begin with a web page. (chromereleases.googleblog.com)
The practical challenge is that FedCM is tied to identity workflows, and identity workflows are rarely optional. If your organization uses browser-based single sign-on or federated login, the feature may be part of daily operations even if employees never consciously notice it. That creates a tension between productivity and hardening: disabling modern sign-in behavior may reduce exposure, but it can also break user experience or compatibility.

What admins should prioritize​

The first priority is version confirmation. If Chrome is below 146.0.7680.165, the device remains in the vulnerable range described by Google and Microsoft. The second priority is ensuring downstream Chromium-based browsers and embedded web surfaces have ingested the corresponding engine fix, because those products may not update on exactly the same schedule. (chromereleases.googleblog.com)

• Verify browser version on managed endpoints.
• Confirm update rings are not delaying Chromium ingestion.
• Check whether Edge or other Chromium-based products have the fix.
• Review identity-related browsing flows for exposure.
• Treat the issue as urgent on high-value user populations. (chromereleases.googleblog.com)

The enterprise angle is especially important because browsers are now infrastructure. They host authentication, collaboration, CRM, SaaS administration, and remote support tools, so a browser exploit can become an enterprise incident much faster than many organizations expect. That is why CVE-2026-4680 should be read in the context of business-critical identity tooling, not only personal browsing.

Consumer Impact​

For consumers, the advice is simpler but no less important: update Chrome immediately if you are below 146.0.7680.165. The user-facing risk is that a malicious site or embedded content could potentially deliver an exploit without requiring a download prompt, a macro, or any unusual local action beyond visiting a page. That is the classic browser threat model, and it remains effective because the browser is where the web meets the operating system. (chromereleases.googleblog.com)
Consumers should also understand that “sandboxed code execution” is not the same thing as safety. Sandboxing reduces what a compromise can do, but browser escapes and chained vulnerabilities are common enough that serious attackers still value sandboxA patch that closes the browser-side memory bug removes one of the most useful entry points in the chain. (chromereleases.googleblog.com)

Why ordinary users should care​

A lot of browser users assume that only obscure enterprise users or security researchers need to worry about version numbers. That assumption is increasingly outdated, because modern browser flaws often require no special setup beyond a visit to a hostile page. In that sense, the average user is exposed to the same class of risk as a corporate administrator, just with fewer patch-management tools to help. (chromereleases.googleblog.com)

• Web exploitation is often silent at the point of delivery.
• Identity features can be reachable during normal sign-in behavior.
• Patch delays matter even for home users.
• Browser updates should be applied as soon as they are offered. (chromereleases.googleblog.com)

There is also a trust issue. Users increasingly depend on browser-mediated login flows because websites push them there, and FedCM is part of that shift. If a feature meant to improve privacy and simplify sign-in becomes a security liability, it can slow adoption and make users more skeptical of browser-managed identity overall.

Competitive and Ecosystem Implications​

Chrome’s vulnerability model has an ecosystem ripple effect because Chromium is the shared engine behind several mainstream browsers and web-rendering components. When Google fixes a Chromium issue, the downstream question becomes how quickly other vendors ingest that patch and how clearly they communicate the resulting protection status. That is why Microsoft’s update guide exists in the first place.
This also affects competition indirectly. Browsers compete on speed, privacy, feature breadth, and trust, but security responsiveness is now part of the feature set. A vendor that can ship faster patch ingestion and clearer update guidance gains operational credibility with enterprises, while one that lags risks inheriting the same security debt without the same visibility.

Chromium as a shared security platform​

Because Chromium is open source, its security wins and failures are shared widely. That is good for transparency and coordinated patching, but it also means one upstream flaw can become a multi-vendor event. The upside is a more consistent fix pipeline; the downside is that a single memory-safety bug can touch browsers, embedded webviews, and enterprise software all at once.

• Upstream fixes propagate to downstream browsers.
• Visibility depends on vendor disclosure and cataloging.
• Enterprises need version-based rather than brand-based thinking.
• Security debt can spread faster than product differentiation.

FedCM also illustrates how competitive browser features can concentrate risk. As vendors race to replace deprecated identity patterns and third-party-cookie dependencies, more security-critical logic is being pulled into browser-managed code paths. That is a sensible privacy direction, but it also means browsers are now managing more of the sensitive state that attackers want to influence.

Strengths a good news is that this vulnerability was fixed quickly and folded into a routine Chrome stable release, which shows the browser team’s ability to move fast when memory-safety bugs are identified. Microsoft’s downstream tracking also gives administrators a clearer way to verify exposure across Edge and Chromium-based deployments. The broader platform trend toward browser-mediated identity is still defensible if vendors keep tightening implementation quality and improving observability. (chromereleases.googleblog.com)​

• Rapid patching in Chrome 146.0.7680.165 reduces the window of exposure. (chromereleases.googleblog.com)
• Downstream visibility through Microsoft’s guide helps enterprises track remediation.
• FedCM’s privacy goals remain valuable for the web ecosystem.
• Version-based verification gives IT teams a concrete control. (chromereleases.googleblog.com)
• Browser sandboxing still provides a meaningful layer of defense. (chromereleases.googleblog.com)
• Open-source transparency makes the fix lineage easier to audit.

Risks and Concerns​

The biggest concern is that identity-related browser code is now so central that bugs in it can have outsized consequences. Even if the initial exploit remains sandboxed, attackers often use browser bugs as part of a larger chain that ends in credential theft, persistence, or lateral movement. Another concern is patch lag, because enterprises rarely update every endpoint at once, and downstream browser versions do not always converge on the same day. (chromereleases.googleblog.com)

• Sandboxed code execution is still a serious compromise primitive. (chromereleases.googleblog.com)
• Patch delay can leave managed fleets exposed longer than expected.
• Identity flow complexity makes regression risk higher after fixes.
• Browser feature sprawl increases the attack surface over time. (chromereleases.googleblog.com)
• User trust erosion can slow adoption of privacy-preserving identity standards.
• Downstream products may lag or obscure fix status if versioning is not checked carefully.

There is also an architectural concern worth watching: as browsers absorb more authentication logic, they become higher-value targets by design. That does not make FedCM a mistake, but it does mean security engineering has to scale at the same pace as product ambition. If the web is going to rely on the browser to mediate identity, the browser has to earn that role release after release.

---

Looking Ahead​

The immediate question is whether CVE-2026-4680 becomes an isolated March 2026 browser footnote or part of a broader pattern in FedCM hardening. Google has already shown it is willing to ship rapid stable-channel fixes when needed, and the March branch demonstrates the company’s willingness to cluster multiple security patches into a short time window. What matters next is whether the FedCM code path gets additional auditing, fuzzing, and defensive refactoring as Chrome 146 matures into later point releases. (chromereleases.googleblog.com)
For enterprises, the operational lesson is to make Chromium versioning a standing control rather than a reactive task. That means tracking not just Chrome, but also Edge and any embedded browser surface that inherits Chromium security fixes. The most effective teams will treat browser patch intelligence the way they treat OS patch intelligence: continuously, version-by-version, and with explicit verification.

• Monitor Chrome, Edge, and embedded Chromium versions.
• Confirm that FedCM-related code paths are not held back by policy deferrals.
• Watch for follow-up advisories or additional FedCM hardening in later releases.
• Validate that identity flows still function after the patch is applied.
• Keep browser security updates on an accelerated deployment ring where possible. (chromereleases.googleblog.com)

CVE-2026-4680 is a reminder that the browser is now the front door for identity, privacy, and productivity all at once, which makes every memory-safety flaw more consequential than it would have been a decade ago. The good news is that this one was patched promptly and surfaced clearly in both upstream and downstream guidance. The harder truth is that as the web continues to move critical workflows into the browser, the cost of a single use-after-free bug keeps rising, and defenders will need to keep pace accordingly.

---

Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center