Microsoft published CVE-2026-55945 on July 3, 2026, identifying a moderate-severity Microsoft Edge Chromium information disclosure flaw fixed in Edge version 150.0.4078.48 and tied to a race condition that can expose local file content. The important word in Microsoft’s advisory is not “moderate”; it is “confirmed.” This is a browser bug with awkward exploitation requirements, but it also sits in the part of the desktop where users, files, forms, and trust boundaries collide. For Windows admins, the right response is neither panic nor dismissal: verify Edge update compliance, understand the exposure, and treat browser patch latency as a real endpoint risk.
Microsoft’s Security Update Guide describes CVE-2026-55945 as an information disclosure vulnerability in Microsoft Edge, the Chromium-based browser that now functions as both a consumer browser and an enterprise application platform. The company says the underlying weakness is CWE-362, a race condition caused by concurrent execution using a shared resource with improper synchronization. In plain English, some timing-dependent interaction inside Edge can allow protected information to be accessed or altered in a way the browser’s security boundary should have prevented.
The advisory’s CVSS vector tells a more nuanced story than the headline severity. Microsoft rates the base score at 4.2, with a temporal score of 3.7, and marks the maximum severity as Moderate. The vector is local attack vector, high attack complexity, low privileges required, no user interaction, changed scope, low confidentiality impact, low integrity impact, and no availability impact.
That combination is unusual enough to deserve attention. “Local” does not mean harmless; it means the vulnerable component is not being exploited directly across the network. “High complexity” means successful exploitation depends on conditions that are not trivially repeatable. “Changed scope” means the vulnerable component and the impacted resource are not neatly contained inside the same security authority.
The advisory also answers the most practical question: what leaks? Microsoft says the information that could be disclosed is file content. That is not the same as arbitrary code execution, credential theft, or a remote worm. But it is also not mere telemetry or browser history metadata. File content is the sort of thing users and organizations reasonably expect the browser sandbox not to hand over.
The “attack complexity: high” entry is doing a lot of work here. Microsoft’s FAQ says successful exploitation requires an attacker to craft deceptive or invisible form elements and for a user to perform two sequential taps. That language points toward a UI-timing and input-flow problem, where the attacker is not simply sending a packet or dropping a file but trying to choreograph browser state, user action, and a race condition.
That matters because race conditions are famously slippery. They may be hard to exploit reliably in a lab, harder still across hardware, operating systems, display scaling, input devices, and browser builds. But when a vendor confirms a race condition and ships a fix, defenders should assume that the uncertainty cuts both ways: difficulty lowers mass-exploitation likelihood, but it does not make targeted exploitation impossible.
Microsoft’s exploitability section says the vulnerability was not publicly disclosed and not exploited at the time of original publication. It also marks exploit code maturity as unproven. That is the reassuring half of the advisory. The less reassuring half is that report confidence is confirmed, meaning Microsoft considers the vulnerability real and credible, not speculative.
There is a quiet lesson here for vulnerability managers. A vulnerability can be low-drama and still be worth patching quickly when it affects a ubiquitous browser and has a confirmed path to local file disclosure. The right triage question is not “Is this the worst bug of the month?” It is “How long do we want fixed browser builds missing from user endpoints?”
In many organizations, Edge is also the browser that is present even when it is not the preferred browser. It ships with Windows, integrates with Microsoft 365 identity flows, and is often permitted through application control policies by default. Users may not think they are “using Edge” until a link opens there, a PDF renders there, or an enterprise portal decides it is the blessed path.
That ubiquity changes the patching calculus. A vulnerability in a niche local application can be patched according to who uses it. A vulnerability in Edge must be treated as a baseline endpoint hygiene issue because the browser is part of the assumed Windows substrate. Attackers have historically been good at finding the default thing, the fallback thing, and the “we forgot that was installed” thing.
This is why Edge security updates deserve a place in the same operational conversation as Windows cumulative updates, even though the browser’s update rhythm is different. Microsoft’s advisory lists Edge version 150.0.4078.48 as the fixed build, released July 3, 2026 and based on Chromium 150.0.7871.47. For managed devices, that version number is the practical truth. Either the endpoint has it or it does not.
Microsoft’s description says concurrent execution using a shared resource with improper synchronization allows an authorized attacker to disclose information locally. That “authorized attacker” phrasing matters. This is not an unauthenticated remote attacker breaking into a machine from across the internet. It implies some level of access or local capability, which limits the threat model.
But modern attacks are often chained. A low-privilege foothold, a malicious local process, an abused browser workflow, or a social-engineered interaction can turn an apparently bounded information disclosure into a stepping stone. File content disclosure is especially interesting because files are where configuration data, tokens, documents, exported reports, and cached business context often live.
The CVSS vector also includes low integrity impact. Microsoft says an attacker who successfully exploited the vulnerability could make changes to disclosed information, while not affecting availability. That does not make this a destructive bug. It does mean the issue is not purely passive leakage in Microsoft’s scoring model, and that gives administrators another reason not to hand-wave it away.
This is an important distinction because vulnerability feeds are full of noise. Some CVEs begin as thin reports, database placeholders, or vendor-minimal advisories with little more than a product name and impact category. Others are backed by a vendor acknowledgement, a reproducible report, or functional details. CVE-2026-55945 is in the latter camp.
For attackers, report confidence can also be a signal. A confirmed browser vulnerability with a named weakness class, a fixed build, a researcher acknowledgement, and a short FAQ gives skilled analysts more to study than a vague “memory corruption” line item. Microsoft did not publish a proof of concept, and exploit maturity is unproven, but the advisory is not empty.
The acknowledgement to security researcher Gal Weizman further supports the coordinated-disclosure picture. That does not tell us the exploit recipe, nor should it. It does tell us this was serious enough to pass through Microsoft’s vulnerability response pipeline and into a shipped Edge security update.
Two taps are not much friction on a touchscreen device. Anyone who has used a tablet, convertible laptop, kiosk, or phone-like browser workflow knows how easy it is to tap twice without thinking, especially when a page appears to lag or when UI elements move. Deceptive or invisible form elements raise the specter of clickjacking-style behavior, even if this specific bug is technically a race condition rather than a classic framing attack.
The advisory does not say this is limited to mobile or touch-first hardware. It uses the word “taps,” which may reflect the exploit scenario Microsoft evaluated, but Edge runs across a broad range of Windows devices where touch, pen, mouse, trackpad, accessibility tools, and hybrid input overlap. That diversity is one reason race and UI-state bugs can be difficult to reason about from a single sentence in an advisory.
For defenders, the practical interpretation is simple: user training is not the fix. You cannot meaningfully train users to detect invisible form elements or to reason about race conditions while interacting with web pages. The fix is the fixed browser build.
Edge’s automatic update model helps consumers and many unmanaged systems, but enterprise fleets are rarely that clean. Update deferrals, network egress rules, frozen golden images, virtual desktops, kiosk devices, and application compatibility rings can all leave Edge behind the current Stable build. The administrative task is to prove update state, not to assume it.
On Windows, Edge updates are commonly handled outside the monthly Windows cumulative update cadence. That can be a blessing because browser fixes land faster. It can also be a blind spot because some patch dashboards are better at reporting OS patch compliance than browser build compliance. If your vulnerability management system cannot tell you which endpoints have Edge 150.0.4078.48 or later, this advisory is a useful excuse to fix that gap.
The same logic applies to servers used interactively, jump boxes, admin workstations, and shared support machines. A browser on an admin endpoint is not just another user application. It is a potential bridge between privileged work, internal portals, downloaded files, cloud consoles, and local secrets.
CVE-2026-55945 is not a screaming emergency. Microsoft says it was not publicly disclosed and not exploited when published. The attack is local, complex, and requires low privileges. The confidentiality and integrity impacts are low. Those are real constraints.
But the vulnerability also affects a default Microsoft browser, involves file content, has confirmed report confidence, and has an official fix available. For enterprise IT, that places it firmly in the “patch promptly through existing browser channels” category. Not a weekend incident bridge, but not a quarterly backlog item either.
There is also a broader ecosystem reason to move quickly. Edge inherits much of Chromium’s velocity, but Microsoft-specific integration and release timing still matter. A fixed Edge build closes the Microsoft-supported path; waiting for general Chromium chatter or third-party exploit analysis is the wrong dependency.
That opacity is partly intentional. Vendors do not want to hand attackers a recipe on publication day, especially for browser bugs that may not yet have public exploit code. But defenders still need enough detail to prioritize. The result is a strange middle ground where CVSS becomes a kind of compressed dialect: AV:L, AC:H, PR:L, UI:N, S:C, C:L, I:L, A:N.
The oddest part of this advisory is the relationship between the FAQ’s “two sequential taps” and the CVSS metric for user interaction, which Microsoft marks as none. CVSS user interaction asks whether a user other than the attacker must participate. If the attacker is also the local authorized user performing the taps, the scoring can still land at UI:N. That is technically coherent, but it is not intuitive for IT staff who read “two taps” and think “user interaction.”
This is why advisories need interpretation rather than rote transcription. The scoring framework is useful, but it is not a story. The operational story is that a local, low-privilege attacker can, under specific timing and UI conditions, cause Edge to disclose file content, and Microsoft has shipped a fix.
Microsoft’s Edge release notes are the natural place to track the security update, while the Security Update Guide provides the CVE-level vulnerability record. In managed environments, Edge update policy should be checked for deferrals, target channel settings, update overrides, and any configuration that prevents the Microsoft Edge Update service from doing its job. A successful deployment is not “we approved the update”; it is “the endpoints are running the fixed build.”
Security teams should also resist the urge to overfit detections to the sparse public description. There is no public exploit, Microsoft says it has not seen exploitation, and the exploit conditions are complex. Detection efforts are better spent on endpoint hygiene, suspicious local process behavior around browser contexts, and making sure browser telemetry is not excluded from normal investigation pipelines.
For Windows enthusiasts and power users, the advice is simpler. Open Edge, check the About page, and let the browser update if it has not already done so. If Edge is not your daily browser, do it anyway. Installed software can be invoked by links, documents, embedded workflows, and system defaults you forgot existed.
CVE-2026-55945 lives in that layered world. It is not a catastrophic remote-code-execution hole. It is a timing and synchronization issue that can disclose local file content under constrained conditions. That makes it less dramatic, but also more representative of the hard problems browsers face now: preserving user intent across complicated UI flows while hostile content tries to blur what the user actually meant to do.
The web’s security model depends heavily on clean separations. A page should not read local files unless the user intentionally supplies them. A renderer should not escape its sandbox. A click should mean what the user saw, not what a page raced into place. A form should not become a covert path to data the user did not mean to expose.
Race conditions attack those assumptions at the seams. They do not always look like the Hollywood version of hacking. Sometimes they look like a form, a tap, a resource that changes state at the wrong instant, and a browser that briefly trusts the wrong thing.
Microsoft Confirms the Bug, but Keeps the Blast Radius Narrow
Microsoft’s Security Update Guide describes CVE-2026-55945 as an information disclosure vulnerability in Microsoft Edge, the Chromium-based browser that now functions as both a consumer browser and an enterprise application platform. The company says the underlying weakness is CWE-362, a race condition caused by concurrent execution using a shared resource with improper synchronization. In plain English, some timing-dependent interaction inside Edge can allow protected information to be accessed or altered in a way the browser’s security boundary should have prevented.The advisory’s CVSS vector tells a more nuanced story than the headline severity. Microsoft rates the base score at 4.2, with a temporal score of 3.7, and marks the maximum severity as Moderate. The vector is local attack vector, high attack complexity, low privileges required, no user interaction, changed scope, low confidentiality impact, low integrity impact, and no availability impact.
That combination is unusual enough to deserve attention. “Local” does not mean harmless; it means the vulnerable component is not being exploited directly across the network. “High complexity” means successful exploitation depends on conditions that are not trivially repeatable. “Changed scope” means the vulnerable component and the impacted resource are not neatly contained inside the same security authority.
The advisory also answers the most practical question: what leaks? Microsoft says the information that could be disclosed is file content. That is not the same as arbitrary code execution, credential theft, or a remote worm. But it is also not mere telemetry or browser history metadata. File content is the sort of thing users and organizations reasonably expect the browser sandbox not to hand over.
The CVSS Score Is Modest Because the Exploit Path Is Messy
Security scoring is often read backwards. A 4.2 CVSS score can look like a permission slip to defer a fix, especially when the affected product is a browser that updates constantly and already sits under a mountain of other Chromium advisories. But the better reading is that Microsoft is saying the attack is constrained, not imaginary.The “attack complexity: high” entry is doing a lot of work here. Microsoft’s FAQ says successful exploitation requires an attacker to craft deceptive or invisible form elements and for a user to perform two sequential taps. That language points toward a UI-timing and input-flow problem, where the attacker is not simply sending a packet or dropping a file but trying to choreograph browser state, user action, and a race condition.
That matters because race conditions are famously slippery. They may be hard to exploit reliably in a lab, harder still across hardware, operating systems, display scaling, input devices, and browser builds. But when a vendor confirms a race condition and ships a fix, defenders should assume that the uncertainty cuts both ways: difficulty lowers mass-exploitation likelihood, but it does not make targeted exploitation impossible.
Microsoft’s exploitability section says the vulnerability was not publicly disclosed and not exploited at the time of original publication. It also marks exploit code maturity as unproven. That is the reassuring half of the advisory. The less reassuring half is that report confidence is confirmed, meaning Microsoft considers the vulnerability real and credible, not speculative.
There is a quiet lesson here for vulnerability managers. A vulnerability can be low-drama and still be worth patching quickly when it affects a ubiquitous browser and has a confirmed path to local file disclosure. The right triage question is not “Is this the worst bug of the month?” It is “How long do we want fixed browser builds missing from user endpoints?”
Edge Is No Longer Just a Browser in the Enterprise
Microsoft Edge occupies an odd position in modern Windows estates. It is a browser, a PDF viewer, an identity-aware enterprise access tool, a WebView-adjacent ecosystem participant, and the front door for countless SaaS workflows. That makes “moderate” browser vulnerabilities more operationally interesting than their score suggests.In many organizations, Edge is also the browser that is present even when it is not the preferred browser. It ships with Windows, integrates with Microsoft 365 identity flows, and is often permitted through application control policies by default. Users may not think they are “using Edge” until a link opens there, a PDF renders there, or an enterprise portal decides it is the blessed path.
That ubiquity changes the patching calculus. A vulnerability in a niche local application can be patched according to who uses it. A vulnerability in Edge must be treated as a baseline endpoint hygiene issue because the browser is part of the assumed Windows substrate. Attackers have historically been good at finding the default thing, the fallback thing, and the “we forgot that was installed” thing.
This is why Edge security updates deserve a place in the same operational conversation as Windows cumulative updates, even though the browser’s update rhythm is different. Microsoft’s advisory lists Edge version 150.0.4078.48 as the fixed build, released July 3, 2026 and based on Chromium 150.0.7871.47. For managed devices, that version number is the practical truth. Either the endpoint has it or it does not.
A Race Condition Is a Timing Bug, but the Risk Is About Trust
The phrase race condition sounds like something only exploit developers should care about. In practice, it means two operations can collide in time, and the software makes a security-relevant decision based on an assumption that stops being true at the wrong moment. In a browser, those assumptions can involve pages, frames, permissions, files, user gestures, form state, or boundaries between web content and local resources.Microsoft’s description says concurrent execution using a shared resource with improper synchronization allows an authorized attacker to disclose information locally. That “authorized attacker” phrasing matters. This is not an unauthenticated remote attacker breaking into a machine from across the internet. It implies some level of access or local capability, which limits the threat model.
But modern attacks are often chained. A low-privilege foothold, a malicious local process, an abused browser workflow, or a social-engineered interaction can turn an apparently bounded information disclosure into a stepping stone. File content disclosure is especially interesting because files are where configuration data, tokens, documents, exported reports, and cached business context often live.
The CVSS vector also includes low integrity impact. Microsoft says an attacker who successfully exploited the vulnerability could make changes to disclosed information, while not affecting availability. That does not make this a destructive bug. It does mean the issue is not purely passive leakage in Microsoft’s scoring model, and that gives administrators another reason not to hand-wave it away.
The “Confirmed” Report Confidence Is the Advisory’s Sharpest Signal
The user-facing text in Microsoft’s advisory defines report confidence as the degree of certainty in the vulnerability’s existence and in the credibility of the known technical details. For CVE-2026-55945, Microsoft marks that metric as confirmed. That means the vendor has enough evidence to stand behind the bug, the fix, and the risk statement.This is an important distinction because vulnerability feeds are full of noise. Some CVEs begin as thin reports, database placeholders, or vendor-minimal advisories with little more than a product name and impact category. Others are backed by a vendor acknowledgement, a reproducible report, or functional details. CVE-2026-55945 is in the latter camp.
For attackers, report confidence can also be a signal. A confirmed browser vulnerability with a named weakness class, a fixed build, a researcher acknowledgement, and a short FAQ gives skilled analysts more to study than a vague “memory corruption” line item. Microsoft did not publish a proof of concept, and exploit maturity is unproven, but the advisory is not empty.
The acknowledgement to security researcher Gal Weizman further supports the coordinated-disclosure picture. That does not tell us the exploit recipe, nor should it. It does tell us this was serious enough to pass through Microsoft’s vulnerability response pipeline and into a shipped Edge security update.
The Two-Tap Detail Points to a Browser UI Boundary Problem
Microsoft’s FAQ says exploitation requires deceptive or invisible form elements and two sequential taps by a user. That is the kind of line that should make browser security people sit up, because it smells like the boundary between user intent and page-controlled presentation. The web platform gives sites enormous power to render interfaces, but browsers are supposed to defend the places where local files, permissions, and trusted gestures enter the picture.Two taps are not much friction on a touchscreen device. Anyone who has used a tablet, convertible laptop, kiosk, or phone-like browser workflow knows how easy it is to tap twice without thinking, especially when a page appears to lag or when UI elements move. Deceptive or invisible form elements raise the specter of clickjacking-style behavior, even if this specific bug is technically a race condition rather than a classic framing attack.
The advisory does not say this is limited to mobile or touch-first hardware. It uses the word “taps,” which may reflect the exploit scenario Microsoft evaluated, but Edge runs across a broad range of Windows devices where touch, pen, mouse, trackpad, accessibility tools, and hybrid input overlap. That diversity is one reason race and UI-state bugs can be difficult to reason about from a single sentence in an advisory.
For defenders, the practical interpretation is simple: user training is not the fix. You cannot meaningfully train users to detect invisible form elements or to reason about race conditions while interacting with web pages. The fix is the fixed browser build.
The Fixed Build Is the Only Real Workaround That Matters
Microsoft lists the remediation level as official fix. It does not provide a meaningful workaround in the advisory, and that is typical for browser bugs involving race conditions and user-interface state. If the vulnerability is in the browser’s handling of a timing-sensitive resource, policy tweaks and awareness memos are poor substitutes for updated code.Edge’s automatic update model helps consumers and many unmanaged systems, but enterprise fleets are rarely that clean. Update deferrals, network egress rules, frozen golden images, virtual desktops, kiosk devices, and application compatibility rings can all leave Edge behind the current Stable build. The administrative task is to prove update state, not to assume it.
On Windows, Edge updates are commonly handled outside the monthly Windows cumulative update cadence. That can be a blessing because browser fixes land faster. It can also be a blind spot because some patch dashboards are better at reporting OS patch compliance than browser build compliance. If your vulnerability management system cannot tell you which endpoints have Edge 150.0.4078.48 or later, this advisory is a useful excuse to fix that gap.
The same logic applies to servers used interactively, jump boxes, admin workstations, and shared support machines. A browser on an admin endpoint is not just another user application. It is a potential bridge between privileged work, internal portals, downloaded files, cloud consoles, and local secrets.
Moderate Does Not Mean Optional When the Browser Is Everywhere
The old patch-management habit was to chase Critical and High first, then process Medium and Moderate advisories when bandwidth allowed. That model still has value, but browsers have weakened the neatness of severity-driven queues. Browser flaws are exposed to untrusted content by design, and browser updates are expected to move quickly.CVE-2026-55945 is not a screaming emergency. Microsoft says it was not publicly disclosed and not exploited when published. The attack is local, complex, and requires low privileges. The confidentiality and integrity impacts are low. Those are real constraints.
But the vulnerability also affects a default Microsoft browser, involves file content, has confirmed report confidence, and has an official fix available. For enterprise IT, that places it firmly in the “patch promptly through existing browser channels” category. Not a weekend incident bridge, but not a quarterly backlog item either.
There is also a broader ecosystem reason to move quickly. Edge inherits much of Chromium’s velocity, but Microsoft-specific integration and release timing still matter. A fixed Edge build closes the Microsoft-supported path; waiting for general Chromium chatter or third-party exploit analysis is the wrong dependency.
The Advisory Exposes the Limits of Public Vulnerability Language
Microsoft’s advisory is useful, but it also illustrates why public vulnerability language often frustrates defenders. We know the weakness class, affected product, fixed version, exploitability status, CVSS vector, researcher acknowledgement, and broad disclosure type. We do not know the exact browser component, file-selection flow, platform-specific conditions, or whether the issue is reachable in common enterprise configurations.That opacity is partly intentional. Vendors do not want to hand attackers a recipe on publication day, especially for browser bugs that may not yet have public exploit code. But defenders still need enough detail to prioritize. The result is a strange middle ground where CVSS becomes a kind of compressed dialect: AV:L, AC:H, PR:L, UI:N, S:C, C:L, I:L, A:N.
The oddest part of this advisory is the relationship between the FAQ’s “two sequential taps” and the CVSS metric for user interaction, which Microsoft marks as none. CVSS user interaction asks whether a user other than the attacker must participate. If the attacker is also the local authorized user performing the taps, the scoring can still land at UI:N. That is technically coherent, but it is not intuitive for IT staff who read “two taps” and think “user interaction.”
This is why advisories need interpretation rather than rote transcription. The scoring framework is useful, but it is not a story. The operational story is that a local, low-privilege attacker can, under specific timing and UI conditions, cause Edge to disclose file content, and Microsoft has shipped a fix.
Administrators Should Verify the Browser, Not Debate the Label
The obvious administrative action is to confirm that Edge Stable has advanced to 150.0.4078.48 or later across managed devices. That sounds mundane, but browser version drift is a persistent problem in real environments. The devices most likely to drift are often the ones least visible: kiosks, lab PCs, conference-room machines, VDI images, rarely used laptops, and systems behind restrictive proxies.Microsoft’s Edge release notes are the natural place to track the security update, while the Security Update Guide provides the CVE-level vulnerability record. In managed environments, Edge update policy should be checked for deferrals, target channel settings, update overrides, and any configuration that prevents the Microsoft Edge Update service from doing its job. A successful deployment is not “we approved the update”; it is “the endpoints are running the fixed build.”
Security teams should also resist the urge to overfit detections to the sparse public description. There is no public exploit, Microsoft says it has not seen exploitation, and the exploit conditions are complex. Detection efforts are better spent on endpoint hygiene, suspicious local process behavior around browser contexts, and making sure browser telemetry is not excluded from normal investigation pipelines.
For Windows enthusiasts and power users, the advice is simpler. Open Edge, check the About page, and let the browser update if it has not already done so. If Edge is not your daily browser, do it anyway. Installed software can be invoked by links, documents, embedded workflows, and system defaults you forgot existed.
The Patch Tells a Bigger Story About Browser Trust Boundaries
Every browser security advisory is a small reminder that the browser is an operating system inside the operating system. It has its own process model, permission prompts, storage, credential surfaces, renderers, sandbox assumptions, update channel, and application ecosystem. Edge adds Microsoft account integration, enterprise policy, Windows integration, and management hooks on top of Chromium’s foundation.CVE-2026-55945 lives in that layered world. It is not a catastrophic remote-code-execution hole. It is a timing and synchronization issue that can disclose local file content under constrained conditions. That makes it less dramatic, but also more representative of the hard problems browsers face now: preserving user intent across complicated UI flows while hostile content tries to blur what the user actually meant to do.
The web’s security model depends heavily on clean separations. A page should not read local files unless the user intentionally supplies them. A renderer should not escape its sandbox. A click should mean what the user saw, not what a page raced into place. A form should not become a covert path to data the user did not mean to expose.
Race conditions attack those assumptions at the seams. They do not always look like the Hollywood version of hacking. Sometimes they look like a form, a tap, a resource that changes state at the wrong instant, and a browser that briefly trusts the wrong thing.
The July 3 Edge Fix Is a Compliance Test Disguised as a Moderate CVE
CVE-2026-55945 should not dominate anyone’s threat briefing, but it should reveal whether an organization’s browser-update process actually works. A moderate, fixed, confirmed Edge flaw is exactly the kind of advisory that separates mature endpoint management from checkbox patching. The concrete work is small, but the signal is useful.- Microsoft published CVE-2026-55945 on July 3, 2026 as a Microsoft Edge Chromium information disclosure vulnerability with moderate severity.
- The fixed Edge release is version 150.0.4078.48, based on Chromium 150.0.7871.47.
- Microsoft says the flaw is a race condition and that successful exploitation could disclose file content.
- The CVSS base score is 4.2, with high attack complexity, low required privileges, changed scope, low confidentiality impact, low integrity impact, and no availability impact.
- Microsoft says the vulnerability was not publicly disclosed and not exploited at publication time, while the report confidence is confirmed.
- The practical response is to verify Edge build compliance across managed and unmanaged Windows endpoints rather than relying on severity labels alone.
References
- Primary source: MSRC
Published: 2026-07-03T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
