CVE-2026-5890 WebCodecs Race Condition: Patch Chrome 147.0.7727.55+

Chrome’s latest security cycle has brought a fresh reminder that race conditions are not just kernel problems. CVE-2026-5890 affects WebCodecs in Google Chrome prior to 147.0.7727.55, and Google says a remote attacker could abuse a crafted HTML page to read potentially sensitive data from process memory. Microsoft has already reflected the issue in its vulnerability guidance, which is a strong signal that downstream Chromium-based browsers and enterprise fleets should treat the patch as operationally relevant, not merely theoretical. (chromereleases.googleblog.com)

Background​

Chromium security disclosures tend to follow a familiar rhythm: Google patches the upstream browser, publishes a stable-channel advisory, and downstream vendors such as Microsoft mirror the issue in their own security guidance so administrators can track inherited exposure. That model matters because modern browsers are not isolated products; they are platforms with shared code paths, shared media stacks, and shared rendering assumptions. When a bug lands in an engine feature like WebCodecs, the blast radius can extend far beyond a single branded browser. (chromereleases.googleblog.com)
The specific issue here is cataloged as CWE-362, which is the standard concurrency category for race conditions. The published description says the flaw allowed a remote attacker to obtain potentially sensitive information from process memory through a crafted HTML page, and Chromium rates the issue as Medium severity. That combination is important: the disclosure does not describe direct code execution, but it does describe a cross-boundary leak in a high-value component that handles media data and timing-sensitive operations.
WebCodecs itself is one of the browser’s lower-level media interfaces. Chromium’s own documentation describes it as the implementation layer for browser media encoders and decoders, including VideoFrame, AudioData, VideoDecoder, VideoEncoder, AudioDecoder, AudioEncoder, and ImageDecoder. In other words, this is not a decorative API tucked away in a corner of the engine; it is part of the modern media pipeline, where performance, memory handling, and asynchronous state transitions are all tightly interwoven.
That architecture is exactly why race bugs in media code deserve attention. Media pipelines are inherently asynchronous, with frames, buffers, callbacks, and reconfiguration paths all moving at different speeds. If synchronization is even slightly off, the result may not be an obvious crash. It can be a stale pointer, a use-after-free, or in this case, a memory disclosure that gives an attacker a glimpse into data that should never have been reachable from web content.
The timing also matters. Google’s stable-channel update for Chrome 147 already shows that the 147 branch was being rolled out in early April 2026, with an early stable release on April 1. That means the vulnerable window was short in absolute terms but still meaningful in managed environments, where rollout can lag by days or weeks across devices, update rings, and endpoint management policies. For consumers, the fix is mostly invisible; for enterprises, the key question is whether the patched build has actually landed everywhere it should. (chromereleases.googleblog.com)

---

What the Vulnerability Means​

At a technical level, a race condition in a browser media subsystem is less about “the browser crashes when two things happen at once” and more about who gets to observe state while it is in flux. If a crafted page can trigger a timing window inside WebCodecs, the attacker may be able to read memory that should have been isolated from web content. That is why even a Medium-rated information disclosure can be serious: browser memory often contains fragments of decoded media, object metadata, or adjacent heap structures that can aid a follow-on exploit chain.

Why process-memory disclosure matters​

Memory disclosure bugs are often underestimated because they are not as dramatic as remote code execution. But in a browser, leaked memory can be a force multiplier. It can reveal layout details, security-sensitive pointers, tokens in transient state, or simply enough heap information to make a later exploitation attempt more reliable.
That is especially important in hardened browser architectures. Chrome’s sandbox, site isolation, and process separation all exist to reduce the impact of a single bug, but those defenses depend on the assumption that one origin should not be able to peek into another process’s memory. A leak across that boundary does not automatically hand over the whole machine, but it can erode the assumptions that keep more severe exploits from becoming practical. (chromereleases.googleblog.com)

• The bug is a race condition, not a simple logic typo.
• The exposure is memory disclosure, not documented remote code execution.
• The attack surface is a crafted HTML page, which lowers the bar for delivery.
• The affected code sits in WebCodecs, a performance-sensitive media subsystem.

Why “crafted HTML page” is a big deal​

A browser vulnerability delivered through HTML is more dangerous than a flaw requiring special local access or exotic hardware. Any attacker who can persuade a user to visit a page, click a link, or load embedded content can potentially trigger the vulnerable path. That makes this kind of issue broadly reachable, even if successful exploitation still depends on precise timing.
The attack model also resembles other modern browser disclosures: the bug is likely not a single-step compromise, but it can become an enabler for more advanced chains. An attacker who can extract memory from a browser process may be able to defeat ASLR or learn enough about runtime layout to make a separate browser sandbox escape or renderer exploit more reliable. That is why defenders should not treat “information disclosure” as “low importance by default.”

---

Why WebCodecs Is Sensitive​

WebCodecs is not just another web API; it is a bridge between JavaScript and the browser’s native media stack. That means it lives close to memory buffers, codec state machines, and timing-sensitive callbacks, which are all fertile ground for synchronization mistakes. The more the browser tries to optimize media handling, the more valuable careful state management becomes.

Media pipelines reward speed and punish sloppiness​

The browser’s media stack is designed to do a lot of work quickly. Frames can be decoded, transformed, and handed off asynchronously, while the page that requested them continues executing JavaScript. That concurrency is the feature; the problem is that concurrency multiplies the number of states a subsystem must handle safely.
In practice, a race in this area often emerges when one path tears down or reconfigures state while another path still believes the old object graph is valid. Chromium’s own recent source history shows other WebCodecs race fixes in adjacent areas, including a 2025 change that flushed an encoder on reconfigure specifically “to prevent race condition” behavior. That history underscores that this API family has had to evolve defensive patterns over time.

• Media APIs juggle frames, callbacks, and state transitions simultaneously.
• Reconfiguration is risky because old and new state can overlap.
• Timing bugs often leak data before they produce visible crashes.
• Fixes in this area tend to be surgical, because broad rewrites would be too disruptive.

Historical context: a recurring browser pattern​

This is not the first time Chromium has had to tighten media-path synchronization. Chromium history includes multiple race mitigations in WebCodecs-related areas, such as disabling asynchronous VideoFrame readback in 2024 and flushing encoders on reconfigure in 2025 to prevent race behavior. The pattern is consistent: as the API surface grows more capable, the implementation must keep closing subtle time-of-check/time-of-use gaps.
That matters for how we interpret CVE-2026-5890. It is not evidence that WebCodecs is uniquely broken, but it is evidence that this part of the browser remains a high-friction zone where even small synchronization mistakes can have security consequences. In a large, performance-tuned codebase, that is exactly where security teams expect to keep finding bugs.

---

Chromium’s Security Cadence​

Google’s release notes show the Chrome team moving the Stable channel to 147.0.7727.49/.50 in early stable release form on April 1, 2026, and the CVE entry itself says the vulnerable versions were prior to 147.0.7727.55. That implies the fix landed in the same 147 train, but the final patched revision is slightly ahead of the initial early-stable build. For organizations that stage updates, that distinction matters because “we’re on 147” is not the same as “we’re on the fixed 147 build.” (chromereleases.googleblog.com)

Release numbering is not a footnote​

Browser versioning is operationally significant because enterprises often track a branch number, not a precise revision. If a vulnerability is patched in a later point release, then machines on the same major branch may still be exposed until the exact fixed build is installed. That is why the CVE’s explicit cutoff at 147.0.7727.55 is more useful than a generic “Chrome 147” label.
Google’s stable-channel updates also show how quickly the branch moves. Chrome’s April 2026 release cycle already includes updates for desktop, beta, and Android, which means the ecosystem is moving on a fast cadence. That is good for security, but it also means lagging endpoints can fall behind quickly if admins rely on manual check-ins or slow patch rings. (chromereleases.googleblog.com)

• Track the exact build number, not just the major version.
• Confirm patch state on Windows and Mac separately if needed.
• Assume update lag in enterprise rings, especially on remote laptops.
• Remember that downstream Chromium products may lag their own ingestion cycles. (chromereleases.googleblog.com)

Why Microsoft’s guidance matters​

Microsoft’s Security Update Guide entry is important because it signals downstream awareness. Even when Microsoft does not originate the bug, it tracks Chromium issues that affect Edge and other Chromium-based experiences through code inheritance. In practice, Microsoft’s entry helps enterprise admins correlate upstream Chrome fixes with downstream browser fleet status.
That does not mean Microsoft independently changed the vulnerability description. Rather, it means the issue is relevant to organizations that rely on Microsoft’s patch and inventory tooling. For those environments, Microsoft’s guidance becomes part of the administrative workflow: identify the vulnerability, verify whether the underlying Chromium code has been ingested, and confirm that endpoint builds are actually remediated.

---

Enterprise Impact​

For consumers, a browser update is usually a background event. For enterprises, it is a policy event, an inventory event, and a compliance event all at once. A memory-disclosure bug in a browser engine can influence everything from privileged browsing sessions to line-of-business applications that embed Chromium components.

Managed fleets need version discipline​

The first enterprise task is straightforward: determine whether endpoints have Chrome 147.0.7727.55 or later, or whether a Chromium-based derivative has absorbed the fix through its own release channel. That means checking actual installed versions, not trusting that an update has “probably” propagated through the estate. On a mixed fleet, even a small set of outdated browsers can keep a vulnerability alive longer than it should be.
The second task is broader. Browser vulnerabilities often affect not just the browser itself, but web-based workflows that depend on browser embedding or automated rendering. That includes kiosks, RPA agents, support tools, internal portals, and remote assistance workflows. If WebCodecs is available in those environments, the attack surface can be larger than administrators expect.

• Audit browser build numbers across the fleet.
• Check embedded Chromium runtimes in third-party apps.
• Prioritize machines that handle sensitive internal web apps.
• Verify update success through endpoint management telemetry, not just policy intent.

Consumer impact is still real​

Even though consumers are less likely to parse CVE details, they are still exposed if they browse a malicious page before patching. The main difference is behavioral: consumers generally rely on automatic updates, while enterprises often have deliberate staging, rollout, and holdback policies. That means consumer exposure can be wide but brief, whereas enterprise exposure can be narrower but persist longer because updates are intentionally throttled. (chromereleases.googleblog.com)
That distinction is important when assessing urgency. A consumer who has already restarted Chrome and received the latest stable build is likely fine. A managed device stuck in an update queue, or a browser deployed through a bundled enterprise app, may remain vulnerable long after the public advisory has been published.

---

Attack Surface and Likely Abuse​

A crafted HTML page is a classic browser delivery mechanism because it requires almost nothing beyond a link and a vulnerable code path. If an attacker can coax a browser into hitting the buggy sequence in WebCodecs, they may be able to extract data from the process without needing elevated privileges or local access. That makes the issue attractive to phishing campaigns, malvertising operators, and opportunistic exploit writers alike.

Why timing bugs are attractive to attackers​

Race conditions are notoriously difficult to weaponize reliably, which is why they are sometimes dismissed too quickly. But attackers do not need perfect reliability to find value in them; they only need enough repetition and enough victims to make exploitation worthwhile. Browser bugs are especially attractive because the attack surface is huge and the delivery mechanism can be mass-distributed.
A memory-disclosure bug can also be used as an exploit primitive. Even if the immediate payoff is limited, leaked memory can support later stages of exploitation by revealing memory layout or object contents. That is the broader reason security teams should treat disclosure bugs seriously rather than assuming only code execution deserves priority.

• Timing bugs may be unreliable, but they are still useful at scale.
• Browser bugs are easy to distribute through ordinary web traffic.
• Memory leaks can assist ASLR bypass and exploit refinement.
• The threat model includes both targeted attacks and commodity abuse.

What is not yet known​

Google’s public description does not spell out the exact memory region leaked, the primitive involved, or whether the bug was discovered internally or reported externally. NVD also notes that enrichment was still incomplete at publication time, with CVSS values not yet provided. That means administrators should avoid overfitting to a more dramatic scenario than the public evidence supports.
At the same time, the absence of a detailed public exploit narrative is not reassuring in itself. Many browser bugs remain low-profile until after patches ship, and defenders should assume that responsible disclosure may be intentionally withholding the kind of details that would help an attacker reproduce the issue. In security work, missing detail is not missing risk.

---

How This Differs from Remote Code Execution​

Not every browser vulnerability is equal, and CVE-2026-5890 belongs in the category of “important, but not automatically catastrophic.” The public description points to information disclosure from process memory, not direct code execution. That means the most likely immediate impact is data exposure or exploit assistance rather than full compromise on its own.

Why that distinction still matters​

Security teams sometimes triage based on the end state they most fear: system takeover. But browser exploitation is often incremental. One bug leaks memory, another bug turns that leak into predictability, and a third bug uses the predictability to break isolation. Seen that way, a disclosure bug can be a crucial step in a chain rather than an isolated nuisance.
This is why Chromium’s Medium severity label should be interpreted carefully. Medium does not mean trivial, and it certainly does not mean “safe to ignore until the next maintenance cycle.” It means the issue has meaningful security implications but may not meet the threshold of top-tier exploitation risk on its own.

• Information disclosure is often a staging point for more serious attacks.
• No code execution does not equal no urgency.
• Memory leaks can undermine browser hardening in subtle ways.
• Severity labels must be paired with threat modeling and asset context.

Comparing with recent Chromium patterns​

Chromium’s 2026 security cycle has already included multiple memory-related and race-related fixes across different components. That broader pattern suggests the browser project is continuing to harden complex subsystems rather than dealing with an isolated anomaly. For defenders, the takeaway is not alarmism; it is that browser stability and browser security now move together.

---

The Microsoft Edge Angle​

Because Edge is Chromium-based, Microsoft’s security guidance is often the practical bridge between upstream Chrome fixes and enterprise deployment status. When a Chromium CVE appears in Microsoft’s update guidance, it is usually a sign that the issue matters to Edge users even if the vulnerability originated in Google’s codebase. That is exactly the kind of cross-vendor tracking administrators depend on.

Downstream inheritance is the whole game​

The browser market has become a code-sharing ecosystem. Chromium provides the engine, and multiple vendors build product and policy layers on top of it. That creates a security benefit—patches can propagate quickly—but it also means a vulnerability in the engine can ripple into enterprise browsers, managed wrappers, and embedded web views.
Microsoft’s own Windows update documentation shows how Chromium issues surface in broader platform guidance, even when the update text is not directly about Chrome. That makes the Security Update Guide a useful coordination layer for admins who manage both Microsoft and non-Microsoft browser stacks. (support.microsoft.com)

• Edge inherits upstream Chromium security fixes.
• Microsoft’s guidance helps map vulnerability status to deployment status.
• Enterprises should not assume Chrome and Edge patch on identical schedules.
• The same CVE can have different operational urgency depending on browser policy.

What admins should verify​

Admins should confirm whether Edge builds in their environment have already absorbed the Chromium fix, especially if those builds are on a managed rollout schedule. They should also review any other Chromium-based applications in the fleet, because the same engine issue may exist in more than one product line. In other words, the question is not just “Is Chrome updated?” but “Where else do we carry Chromium?”
That broader inventory often catches surprises. Internal line-of-business apps, developer tools, remote support suites, and document viewers increasingly embed Chromium components. If those products update on their own cadence, they can quietly lag behind the browser proper, and that is where CVE-2026-5890 may linger longest.

---

Patch Management Implications​

The practical answer to a disclosure like this is simple: patch quickly, verify carefully, and do not confuse release train movement with actual remediation. Google’s published cutoff at 147.0.7727.55 gives administrators a clear threshold, but operational reality is messier because browser updates can be delayed by policy, user behavior, or packaging constraints.

Three steps that matter most​

• Confirm the installed browser build on every endpoint, not just the primary workstation sample.
• Check whether Chromium-based applications embed the vulnerable engine separately from the browser.
• Reconcile vulnerability scanners with actual package and version telemetry, because browser auto-updates can lag scanner refreshes.

That workflow sounds basic, but it is where most browser vulnerability handling succeeds or fails. Administrators who rely on a single inventory snapshot often miss devices that were offline during the patch window or machines with update services deferred by policy.

Why this CVE fits routine patch cycles​

This is not a zero-day with public exploitation warnings in the materials reviewed, and it is not described as a broad breakout bug. But that should not soften the response. Routine browser patch cycles exist precisely to absorb issues like this before they can be chained, mass-scanned, or quietly exploited on unpatched devices.

• Treat the issue as real patch debt, even without an exploit headline.
• Use precise build verification, not broad version buckets.
• Recheck embedded Chromium runtimes in third-party software.
• Include browsers in the same urgency tier as other internet-facing software.

---

Strengths and Opportunities​

The good news is that this vulnerability sits in a part of Chromium where the browser team has repeatedly shown it can make targeted, low-risk repairs. Because WebCodecs is a performance-sensitive subsystem, fixes are likely to remain surgical rather than disruptive, which reduces the chance of broad regression for users who install the update. That is one reason browser security work, while constant, is usually manageable when organizations keep pace.

• The fix path is already visible in a live Chrome release cycle.
• Downstream vendors can inherit the correction quickly.
• The issue is bounded to a specific API surface, which helps targeted validation.
• Chrome’s and Edge’s update channels give defenders multiple verification points.
• Security teams can use this CVE to tighten browser inventory hygiene.
• The race-condition class is well understood, which improves triage clarity.
• The disclosure reinforces the value of monitoring point releases, not just majors.

Risks and Concerns​

The concern, of course, is that a memory-disclosure bug can be more useful than it first appears. If attackers can reliably trigger the race, the leak may help them refine a larger browser exploit chain or extract data that should have remained private. The other risk is operational: organizations that think “we’re on Chrome 147” may falsely believe they are already safe when the vulnerable build cutoff is more specific.

• The bug may be leveraged as an exploit primitive.
• Users on partially rolled-out builds may remain exposed.
• Managed environments can lag behind public release notes.
• Third-party Chromium embeds may not follow Chrome’s schedule.
• Administrators may underreact because the issue is “only” Medium severity.
• Security scanners may lag behind real-world patch state.
• Lack of detailed public exploit information can create false confidence.

---

Looking Ahead​

The next thing to watch is whether Google publishes any additional technical detail in future Chrome release notes or issue trackers, and whether Microsoft’s guidance changes to reflect downstream build numbers as Edge rolls forward. In practical terms, the important question is not whether the CVE exists—it clearly does—but how quickly the fixed build becomes universal across desktop browsers and embedded Chromium products.
The second thing to watch is whether this disclosure prompts broader scrutiny of WebCodecs synchronization paths. Chromium’s history already shows a pattern of race mitigations in adjacent media code, so it would not be surprising if engineers continue tightening state transitions or adding more explicit teardown behavior in related pathways. That would be a healthy sign, not evidence of crisis.

• Watch for updated vendor advisories and downstream build confirmations.
• Check whether Edge and other Chromium forks publish aligned fixes.
• Monitor whether additional WebCodecs race bugs are disclosed.
• Validate that endpoint inventory reflects the exact fixed build.
• Reassess browser auto-update policy for devices with delayed connectivity.

The broader lesson is that browser security is increasingly a story about precision: precise state handling, precise build tracking, and precise downstream coordination. CVE-2026-5890 is not the most dramatic Chrome bug of the year, but it is the kind of subtle flaw that reminds defenders why patch discipline matters. When media code, web content, and asynchronous state all meet in one place, even a Medium-severity race can deserve immediate attention.

---

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