CVE-2026-4456 Chrome Use-After-Free: Patch to 146.0.7680.153 Now

The release of CVE-2026-4456 is another reminder that browser security increasingly hinges on tiny memory-lifetime mistakes with outsized consequences. Google says the flaw is a use-after-free in the Digital Credentials API, affecting Chrome versions before 146.0.7680.153, and that a remote attacker who had already compromised the renderer process could potentially turn it into a sandbox escape through a crafted HTML page. Google’s stable-channel fix landed on March 18, 2026, and Microsoft’s Security Update Guide now tracks the same issue for downstream visibility. (chromereleases.googleblog.com)

Background​

Chromium has long been the shared security foundation for Chrome, Edge, and a wide range of browser-adjacent products, which is why a single upstream flaw can become a fleet-wide concern almost immediately. The modern browser is no longer just a page viewer; it is a complex runtime that handles identity, documents, media, graphics, APIs, and app-like workflows all at once. That breadth is precisely why memory-safety bugs remain so valuable to attackers and so disruptive to defenders.
The Digital Credentials API sits in a particularly sensitive part of that ecosystem because it touches trust, authentication, and browser-mediated identity flows. Even without full exploit details, the fact that the vulnerability lives in that area tells us the bug is not merely academic. It is tied to one of the browser’s newer user-facing surfaces, where security failures can have implications beyond a simple crash.
Chrome’s March 2026 stable release train shows how busy the browser security pipeline has become. On March 18, 2026, Google shipped Chrome 146.0.7680.153/154 and listed 26 security fixes, including CVE-2026-4456. The company also noted that bug details may remain restricted until a majority of users are protected, which reflects the standard browser-vendor balance between transparency and anti-weaponization caution. (chromereleases.googleblog.com)
This matters especially for Windows administrators because Microsoft mirrors Chromium-origin vulnerabilities in its own update guidance. Microsoft’s update guide entry confirms the issue and gives enterprise teams a familiar way to map the upstream fix to their own browser inventory and rollout status. That is not a separate vulnerability story; it is the downstream side of the same Chromium security supply chain. (msrc.microsoft.com)
At a broader level, CVE-2026-4456 fits the pattern that has defined Chromium security for years: high-complexity software, a huge attack surface, and constant pressure from both fuzzing and adversarial research. Google’s own release notes show multiple memory-safety fixes in the same cycle, including issues in Base, Blink, WebRTC, V8, Network, PDFium, and graphics-related subsystems. That clustering is not unusual; it is a sign of how much work modern browser hardening requires. (chromereleases.googleblog.com)

Why this issue is different from a routine browser bug​

A use-after-free is not just “a crash bug.” It means the code tries to access memory after it has already been released, which can create unstable behavior, information leaks, and in the worst cases exploitable corruption. In a browser renderer context, that is often the first stage of a larger exploit chain rather than the final payload itself.
The phrase renderer process is the key clue. Chrome’s sandbox is designed to contain damage, so a successful renderer compromise is usually only one step in the attacker’s path. If a bug can help the attacker jump out of that sandbox, the value of the vulnerability rises sharply.

• It is a memory-safety flaw, not a logic-only error.
• The vulnerable surface is tied to browser identity and credential flows.
• The risk is about sandbox escape, not just page instability.
• The patch boundary is clear: Chrome 146.0.7680.153 and later. (chromereleases.googleblog.com)

---

Overview​

The most important operational fact is simple: Chrome builds prior to 146.0.7680.153 are the vulnerable line, and the fix is already shipping in stable. That means defenders are not waiting on a future patch or an uncertain workaround. They have a concrete version threshold and a present-tense remediation task.
CVE-2026-4456 is rated High in Chromium’s severity language, and NVD’s record identifies it as CWE-416: Use After Free. Microsoft’s entry also reflects a CVSS 3.1 vector of 8.8 High via CISA-ADP enrichment, with network attackability, low complexity, no privileges, and user interaction required. That combination is the classic browser-risk profile: accessible from the web, difficult to ignore, and dangerous enough to prioritize quickly. (msrc.microsoft.com)
The user-interaction requirement is important, but it should not reassure anyone too much. Browsers are consumed through routine behavior, which means the real-world trigger might be as ordinary as opening a link, loading an embedded page, or following a social-engineering lure. Security teams often underestimate this class of bug because it does not look dramatic until it is chained.

The security model at stake​

Chrome’s sandbox is one of the browser’s principal defenses, but it is not a substitute for secure code. A renderer exploit that can be chained into sandbox escape is especially concerning because it can move the attacker from isolated content execution into a more privileged browser context. That makes the bug materially more serious than a straightforward crash or a content-rendering failure.
It also means exploit development may focus on building a chain, not a one-shot compromise. In practice, attackers often need a renderer primitive first and a sandbox-bypass primitive second. CVE-2026-4456 appears to sit near that boundary.

What administrators should read into the advisory​

The advisory tells us three things that matter for operations. First, the bug is real enough for a public CVE and a shipping stable fix. Second, the issue is serious enough to be assigned High severity. Third, the downstream patch ecosystem already acknowledges it through Microsoft’s guide.

• Fix available in stable Chrome.
• Vulnerable builds are anything before 146.0.7680.153.
• Microsoft is tracking the same issue for Windows-focused admins.
• The exploit story is about sandbox escape, not merely rendering failure. (chromereleases.googleblog.com)

---

The Digital Credentials API in Context​

The Digital Credentials API is not the sort of browser feature most users think about every day, which can make it easy to overlook from a security perspective. But features that touch identity, authentication, and credential handling deserve heightened scrutiny precisely because they sit close to trust boundaries. When those systems fail, the consequences can extend beyond a single tab or page session.
That is why this CVE stands out even among a crowded March 2026 patch train. A bug in a credentials-related API implies that the security boundary is not only the browser process, but the browser’s interaction with the web’s identity layer. The API itself is part of the broader shift toward more integrated browser-native identity workflows, and that shift makes correctness more important, not less.
Chrome’s release note does not describe the precise exploit mechanics, and that absence is deliberate. Google often limits bug detail until the patch has had time to land broadly, because public technical detail can help attackers rush weaponization. In a browser feature like this, secrecy for a short window is a defensive choice, not a lack of transparency. (chromereleases.googleblog.com)

Why identity-adjacent features are attractive targets​

Attackers like features that sit near authentication because the payoff is often higher than for generic content bugs. If a vulnerability helps them interact with or escape from code handling credentials, the resulting compromise may open the door to session theft, token abuse, or deeper browser control. Even if the exact chain is not public, the location of the bug tells us the likely value.
A use-after-free in such a component is especially unsettling because memory lifetime mistakes can translate into corrupted state at exactly the wrong moment. In identity workflows, corrupted state can be more damaging than a simple crash because it may affect ongoing browser trust decisions.

• Credentials-related code tends to be high-value.
• Memory bugs in trust flows are often chainable.
• Browser identity features frequently process sensitive state.
• A sandbox escape candidate deserves urgent attention. (msrc.microsoft.com)

Why the bug description is intentionally terse​

Google’s release note gives defenders enough to act, but not enough to reconstruct the exploit. That’s the right tradeoff in the early phase of disclosure. It protects users by shortening the vulnerable window while limiting the odds that a working exploit emerges immediately from the public advisory.
For enterprises, the practical implication is that the absence of detail should not be misread as low severity. In Chromium-land, terse often means deliberately withheld, not harmless.

---

Patch Timing and Release Cadence​

The fix boundary for CVE-2026-4456 is not vague. Google says Chrome 146.0.7680.153 is the stable build line that includes the remediation, and that version is already rolling out across platforms. For Windows and Mac, the release note calls out 146.0.7680.153/154, while Linux receives 146.0.7680.153. That is exactly the kind of concrete versioning administrators need when verifying compliance. (chromereleases.googleblog.com)
The timing also matters because Chrome 146 was already a fast-moving branch when this issue surfaced. By the time a browser reaches stable, the security team is often dealing with a cluster of late-cycle fixes. In this case, Chrome’s March 18 update bundled a large set of vulnerabilities, which is another sign that the project is operating on a continuous hardening cadence rather than a traditional release-and-wait model. (chromereleases.googleblog.com)
For defenders, that cadence is both good news and a challenge. Good news, because the patch is available quickly. Challenge, because rapid releases make it easy for endpoints to drift one or two patch trains behind if update governance is loose. In browser security, being “close enough” is not the same as being patched.

How the release model changes enterprise risk​

Enterprise environments often assume they can defer browser patches until the next maintenance window. That works for some software, but browser exploits move too quickly and are too exposed to rely on that model alone. A browser that is updated only after internal testing cycles may remain vulnerable long enough to matter.
The pressure is not just technical; it is operational. When a browser version is the front door to email, SaaS, HR systems, collaboration tools, and internal apps, a missed patch becomes a broad exposure event.

What the exact build number means​

The build number is more than a version string. It is the line between exposed and remediated. That means inventory tools should report the full browser build, not merely the major version, because a dashboard that says “Chrome 146” may hide a vulnerable sub-build.

• Treat 146.0.7680.153 as the minimum fixed build.
• Verify both Chrome and Chromium-based downstream browsers where applicable.
• Restart requirements still matter after update deployment.
• Offline machines and rarely used endpoints should not be assumed safe. (chromereleases.googleblog.com)

---

Enterprise Impact​

For enterprises, the most important question is not whether the bug is theoretically exploitable. It is how many devices remain on pre-fix Chrome builds and how quickly those devices can be moved forward. Because the flaw can be triggered through crafted HTML, exposure exists anywhere browsers process untrusted content, which is effectively everywhere in a modern workplace.
That includes remote workers, kiosks, VDI sessions, shared workstations, and privileged users whose browser activity touches high-value services. A renderer compromise that can lead to sandbox escape is especially concerning in enterprise settings because attackers rarely need to compromise every endpoint; they need one foothold in the right place.
Microsoft’s role in this picture is practical rather than symbolic. Its Security Update Guide helps administrators track Chromium-origin CVEs as they flow into downstream browser builds. That matters because many Windows fleets use Edge alongside Chrome, and the management process often depends on clear version mapping rather than vendor branding. (msrc.microsoft.com)

Patch governance is the real control​

Enterprises sometimes focus on endpoint detection and response, but for browser CVEs the first control is still patch speed. The browser itself is the vulnerable surface, and if it remains outdated, every other control becomes secondary. Verification matters just as much as deployment because a browser update that never actually lands is a security mirage.
A strong response should be boring and disciplined: inventory, deploy, verify, and recheck. Anything less leaves a gap for opportunistic abuse.

Why browser CVEs behave like supply-chain issues​

Chromium is not just one browser. It is an engine used across a family of products, and that means a vulnerability can propagate through multiple downstream release channels. The timing and packaging may differ, but the underlying issue is shared. In other words, one upstream fix can be a multi-product event.

• Chrome and Edge need separate verification.
• Embedded Chromium apps may need their own update path.
• Managed and unmanaged devices often age at different speeds.
• Security teams should verify the actual installed build, not policy intent. (chromereleases.googleblog.com)

The user-interaction factor should not soften priorities​

Yes, the attack needs user interaction. No, that does not make it low priority. In enterprise life, user interaction is almost guaranteed through normal web use, especially when employees click links from email or collaboration tools. That is why browser exploits remain so useful to attackers and so annoying for defenders.

---

Consumer Impact​

For consumers, this is a straightforward patch-now situation. If Chrome has not yet updated to 146.0.7680.153 or later, the browser may still be exposed. Most home users will never see the technical details of the bug; they only need to know that a malicious page could potentially trigger a serious browser failure pathway.
The good news is that Chrome updates automatically in most environments. The bad news is that automatic does not mean immediate. Browsers often require a restart, and many users leave tabs open for days or weeks, effectively postponing the protection they already downloaded.
That makes this CVE a classic example of how modern security depends on completion, not just download. A patch sitting in the updater cache is not a patch in practice until the browser is actually running the fixed build. (chromereleases.googleblog.com)

Everyday habits that matter here​

Consumers often underestimate the role of ordinary browsing behavior in exploit delivery. A link in email, a message in a chat app, or a compromised website can all become the trigger point if the browser is vulnerable. That is why the attack model is so effective: it uses everyday behavior as the delivery mechanism.
This bug also reinforces a broader lesson. The browser is no longer just a browser; it is where people bank, authenticate, shop, manage passwords, and access work tools. That makes browser hygiene a personal-security issue, not merely an IT-policy issue.

What home users should do​

The response is simple, but worth stating clearly. Update Chrome, restart it, and remove any reluctance to reboot after the patch lands. The fastest protection is usually the one already available in the auto-update channel.

• Make sure Chrome is fully restarted after updating.
• Keep background updates enabled.
• Avoid delaying browser restarts for long periods.
• Treat unfamiliar or unsolicited links as higher risk than usual. (chromereleases.googleblog.com)

Why “crafted HTML page” is a meaningful phrase​

That wording means the attacker does not need a local installation, a USB drop, or physical access. They need web delivery. That makes the bug relevant to anyone who uses the browser normally, which is to say nearly everyone.

---

Why Use-After-Free Bugs Keep Appearing​

Use-after-free bugs continue to show up in Chromium because modern browser code is a brutal environment for object lifetime management. Pages are dynamic, scripts are asynchronous, rendering is layered, and many components interact across process boundaries. That complexity means stale pointers can be introduced in subtle ways even in well-engineered code.
The Chromium release notes for March 2026 make the point indirectly but powerfully. Google fixed multiple memory-safety flaws in one update cycle, spanning Base, Blink, WebRTC, V8, Network, PDFium, and more. That clustering shows the bug class is not rare or isolated. It is a persistent feature of large C++ codebases that process hostile input at internet scale. (chromereleases.googleblog.com)
CVE-2026-4456 is therefore not an anomaly. It is part of a broader maintenance reality where security hardening is continuous, and where each new API or feature surface adds another chance for lifetime mistakes. The browser is a moving target, and attackers know it.

Why the Digital Credentials API is a difficult surface​

APIs tied to identity and authentication often have complicated state transitions. They need to interact with user gestures, browser context, platform features, and privacy rules. Each additional interaction point can introduce new object lifetimes and asynchronous flows, which is exactly where use-after-free bugs tend to hide.
That does not mean the API is insecure by design. It means the security bar is high, and the implementation burden is real. In browser engineering, the hard part is often not building a feature, but doing it without creating a memory-corruption foothold.

The broader lesson for browser developers​

The recurring lesson is defensive engineering plus rapid remediation. Fuzzing, sanitizer runs, and code audits clearly matter, but they do not eliminate the problem. Google’s own release note explicitly points to tools such as AddressSanitizer, MemorySanitizer, Control Flow Integrity, libFuzzer, and AFL as part of the security process. That tells us the project is already using serious defenses, yet flaws still emerge. (chromereleases.googleblog.com)

• Complex asynchronous code is fertile ground for lifetime bugs.
• New browser APIs enlarge the trusted computing base.
• Fuzzing helps, but it cannot prove the absence of exploitable states.
• Patch velocity remains a core part of browser defense. (chromereleases.googleblog.com)

A note on the sandbox​

The browser sandbox is one of the great security successes of the modern web, but it is not invincible. A sandbox escape vulnerability is most dangerous when it follows a renderer compromise, because that turns content rendering into a path toward broader system influence. That is why Google’s description here deserves close attention even without exploit details.

---

Microsoft’s Role in the Disclosure​

Microsoft’s Security Update Guide entry matters because it helps Windows administrators connect the upstream Chromium advisory to downstream browser management. Microsoft is not claiming the bug originated in Edge; it is tracking the Chromium issue because Edge inherits Chromium code and therefore inherits Chromium risk. That distinction is crucial for anyone managing mixed-browser fleets on Windows. (msrc.microsoft.com)
The Microsoft record also adds the CVSS enrichment that many enterprise tools rely on when triaging vulnerabilities. A score of 8.8 High with network attackability and user interaction required is exactly the kind of input security operations teams use to prioritize response. In other words, Microsoft’s guide does not replace Google’s advisory; it operationalizes it for Windows environments. (msrc.microsoft.com)
This downstream tracking is one reason Chromium vulnerabilities show up so prominently in enterprise patch dashboards. They are not just browser events; they are lifecycle events across an ecosystem of products that share code but not always the same rollout timing. That means a single bug can have different exposure windows depending on the browser vendor, update channel, and enterprise policy stack.

Why the same CVE can matter differently across products​

Chrome and Edge may share the same vulnerable engine, but they do not update on exactly the same schedule. In consumer settings, Chrome’s auto-update behavior may narrow the window quickly. In managed Windows environments, approval gates, staged deployment, and compatibility testing can widen it. That difference is where administrators earn their keep.

• Upstream Chrome fixes do not equal immediate downstream safety.
• Edge needs independent confirmation of the patched build.
• Managed environments often lag consumer rollouts.
• Version compliance should be checked in each browser family. (msrc.microsoft.com)

What this says about modern patch coordination​

The modern browser ecosystem is really a patch-coordination ecosystem. Vendors upstream create the fix, downstream vendors integrate it, and customers then verify that it reached the devices they control. That is much more complex than the old idea of simply “installing a browser update.”

---

Strengths and Opportunities​

The good news is that this is a case where the ecosystem is behaving the way it should: the bug is disclosed, the fix is available, and the version boundary is clear. That gives defenders a real remediation target instead of an abstract warning, and it gives security teams a chance to improve their patch discipline while the issue is still fresh. The broader opportunity is to turn this one CVE into a better browser-governance process overall.

• Clear fixed version: Chrome 146.0.7680.153 is the hard line for remediation. (chromereleases.googleblog.com)
• Stable patch already shipped: no waiting on a future release. (chromereleases.googleblog.com)
• Downstream visibility exists: Microsoft is already tracking the CVE. (msrc.microsoft.com)
• Good compliance test case: version audits can be improved immediately.
• Useful awareness moment: browser identity features deserve more security attention.
• Cross-platform relevance: the fix matters across Windows, Mac, and Linux endpoints. (chromereleases.googleblog.com)
• Patch-process benefit: teams can benchmark how fast they move from advisory to verification.

Risks and Concerns​

The main concern is that this vulnerability sits in a place where a successful exploit could have consequences beyond a browser crash. A sandbox escape path is serious by definition, and the fact that the bug lives in a credentials-related API makes the issue feel even more security-sensitive. The second concern is the usual one: many organizations will assume they are safe because they “have auto-update,” while a meaningful number of endpoints remain below the fixed build.

• Sandbox-escape potential raises the stakes. (chromereleases.googleblog.com)
• User interaction is common enough to be exploitable at scale. (msrc.microsoft.com)
• Update lag is the real window attackers target.
• Managed environments can delay deployment for compatibility reasons.
• Off-network devices may miss the update entirely.
• Patch verification gaps can leave false confidence.
• Identity-adjacent code tends to have a large blast radius.

---

Looking Ahead​

The next question is not whether the fix exists; it does. The real question is how quickly fleets move to it, and whether exploit researchers or attackers learn enough from the public record to build chains around the bug before the vulnerable build disappears from circulation. In browser security, that patch-adoption window is often the only window that matters.
Security teams should also watch for adjacent Chromium advisories in the same release family. Chrome’s March 2026 stable note shows a dense cluster of vulnerabilities, which suggests the browser is under sustained security pressure rather than isolated event handling. That means administrators should expect more fixes, not fewer, and should build their patching process around that reality. (chromereleases.googleblog.com)

Near-term checklist​

• Verify Chrome is at or above 146.0.7680.153. (chromereleases.googleblog.com)
• Confirm Edge and any other Chromium-based browsers are patched through their own channels. (msrc.microsoft.com)
• Restart browsers that have downloaded updates but not applied them.
• Audit remote and offline devices separately.
• Recheck endpoint reports after deployment, not just before it.
• Watch for follow-on Chromium advisories in the same branch. (chromereleases.googleblog.com)

In the end, CVE-2026-4456 is another reminder that the browser is now one of the most important security boundaries on any desktop. The good news is that the fix is already in the wild; the bad news is that exposed browsers will remain exposed until organizations and users actually move. In the Chromium era, that gap between available patch and verified deployment is where the real risk lives, and the safest response is still the oldest one: update first, verify second, and assume nothing until the version number says otherwise.

---

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