Microsoft disclosed CVE-2026-58297 on July 3, 2026, as a high-severity information disclosure vulnerability in Microsoft Edge for Android, affecting Chromium-based Edge builds before version 150.0.4078.48 and allowing an unauthorized network attacker to access private personal information if user interaction occurs. The sparse MSRC entry is not a mere bookkeeping footnote; it is a reminder that mobile browsers are now credential vaults, identity brokers, passkey front ends, and enterprise access clients. The practical story is less about a single Android app patch than about how much trust organizations have quietly concentrated in the browser sitting on an employee’s phone. Microsoft’s advisory gives defenders enough to act, but not enough to satisfy curiosity — and that asymmetry is intentional.
Edge for Android is not just “the Windows browser, but smaller.” For many Microsoft-heavy organizations, it is the mobile doorway into Entra ID, Microsoft 365, Outlook on the web, SharePoint, Teams links, enterprise SaaS apps, and managed browsing policies. A flaw that exposes private personal information over the network therefore lands in a different category from an obscure UI bug or a low-impact crash.
According to Microsoft’s Security Update Guide, CVE-2026-58297 is classified as an information disclosure vulnerability in Microsoft Edge for Android. Third-party CVE aggregators tracking the MSRC entry list the affected product as Microsoft Edge Chromium-based for Android before 150.0.4078.48, with a CVSS 3.1 base score of 7.1, a “High” severity rating, network attack vector, low attack complexity, no privileges required, and required user interaction.
That combination matters. “Network,” “low complexity,” and “no privileges required” tell administrators that the bug does not belong in the comfortable category of local-only attacks requiring prior compromise. “User interaction required” softens the rating, but only slightly, because mobile browsing is almost entirely user interaction: tapping links, opening tabs, approving prompts, and following redirects through apps that all want to become the default handler for something.
The affected version boundary is also notable. A fix at or after Edge 150.0.4078.48 implies the remediation path is straightforward for consumers: update the app. For enterprises, the path is less tidy, because managed Android fleets often depend on staged rollouts, Android Enterprise policy timing, Play Store update behavior, and the stubborn reality that mobile devices spend long stretches outside the tidy patch windows administrators design on paper.
The user-supplied MSRC text points to a key scoring idea: confidence in the existence of a vulnerability and credibility of technical details. That concept is easy to overlook when administrators sort queues by CVSS alone. A vulnerability can be urgent because the vendor confirms it exists, even if the public does not yet know the exact failing function, code path, or exploit primitive.
This is where Microsoft’s role as vendor matters more than the commentary around the CVE. A vendor-confirmed vulnerability in a current browser build is not rumor. It may be technically under-described, but it is operationally real: the product team has shipped or identified a fixed version, assigned a CVE, and told the ecosystem where the risk sits.
For attackers, the lack of public detail is only a temporary obstacle. Once a patched mobile browser build exists, researchers and adversaries can compare versions, inspect Chromium-related changes where applicable, and look for behavioral differences. That does not mean exploitation is inevitable, but it does mean defenders should not confuse “no public proof of concept” with “no one can figure this out.”
Microsoft’s wording for CVE-2026-58297 centers on unauthorized access to private personal information over a network. That phrasing is broad, and defenders should resist the urge to narrow it without evidence. The public record does not establish that passwords, cookies, passkeys, payment cards, or enterprise tokens are specifically exposed. It establishes that Microsoft considers the confidentiality impact high enough to warrant a high-severity rating.
The distinction matters because overclaiming vulnerability impact can be as damaging as underreacting to it. If security teams tell users “your passwords were stolen,” they may be inventing facts. If they tell users “this is only a privacy bug,” they may be minimizing a browser-class disclosure issue whose practical impact depends on what the victim was doing when exposed.
The safest enterprise posture is to treat the bug as a potentially sensitive data exposure in a mobile browser used for work and personal browsing. That does not require panic. It requires update enforcement, version visibility, and a short-term review of whether high-risk users — executives, administrators, finance teams, help desk staff, and anyone with privileged cloud access — are running vulnerable builds.
On a desktop, user interaction can mean a user must open a malicious document, visit a crafted page, or approve a prompt. On Android, interaction is the normal operating model. Links arrive through Teams, Outlook, SMS, Slack, QR codes, authenticator flows, social apps, and password reset messages. The line between “the user was tricked” and “the user used the device normally” is thin.
Mobile operating systems also amplify link-handling complexity. A tap may move the user from email to browser to identity provider to installed app and back again. Edge for Android may be part of that chain even when the user does not consciously think of themselves as “using a browser.” That makes required interaction a meaningful exploit condition, but not a comforting one.
For administrators, the correct reading is not “this can only happen if users do something foolish.” It is “this likely needs a browsing or link-opening event.” That distinction changes the response: awareness helps, but patching helps more.
The affected product line listed by public CVE trackers is Microsoft Edge Chromium-based for Android. That does not automatically mean Chrome for Android or every Chromium-derived browser is affected. CVE naming can attach to a vendor’s specific implementation, wrapper code, sync behavior, UI surface, identity integration, or platform-specific configuration. Without Microsoft publishing a root cause, it would be irresponsible to declare this a wider Chromium bug.
Still, Chromium’s ecosystem gravity matters. Attackers understand the engine family. Security researchers know how to diff browser builds. Enterprise defenders often treat mobile browsers as interchangeable until a vulnerability reminds them that each vendor’s integration choices can create distinct risk.
Microsoft’s mobile Edge build is not just Chromium with a blue icon. It carries Microsoft account integration, enterprise management hooks, sync behavior, tracking prevention choices, Copilot-era service integration, and policy surfaces meant to make it fit into a Microsoft estate. Any one of those layers can turn a browser flaw into an organizational concern.
Consumer Android devices typically update apps automatically, but “typically” is doing a lot of work. Auto-updates may be disabled, delayed by battery settings, constrained by network preferences, blocked by regional rollout timing, or held back on devices with limited storage. A user can be nominally protected by the Play Store update model and still run a stale browser for days or weeks.
Enterprise Android management improves the situation, but it does not eliminate it. Android Enterprise can enforce app installation and manage update behavior, yet many organizations still lack clean reporting on the exact version of every mobile browser in active use. Bring-your-own-device policies make this worse, particularly when personal devices are allowed to access work resources through mobile browsers outside full device management.
This is why a high-severity mobile browser CVE becomes a governance issue. The patch exists, but the question for IT is whether the organization can prove deployment. A vulnerability management program that sees Windows patch levels clearly but treats Android app versions as a fog bank is only half-modernized.
If this were a Windows Server vulnerability, administrators would know where to look: inventory, patch rings, maintenance windows, compensating controls, logs, and exceptions. If this were a pure consumer app bug, the advice would mostly be “update now.” Edge for Android sits between those worlds, where the device may be personally owned, the identity may be corporate, and the browser session may bridge both.
That matters most for conditional access and mobile application management. Organizations that rely on app protection policies may assume they have contained corporate data within managed apps. But browser-mediated access often tests the edges of those assumptions, especially when users open links from unmanaged contexts or authenticate through flows that shift between apps.
The right response is not to ban mobile browsing or declare BYOD dead. It is to admit that mobile browsers need the same visibility and urgency as desktop browsers. If Edge is permitted as an access path to corporate data, Edge’s version should be visible to the people responsible for protecting that data.
The confidentiality rating is the part administrators should notice first. A high confidentiality impact means the bug’s worst credible outcome is not a trivial leak. In browser terms, confidentiality is often the domain that matters most, because browsers are the place users bring secrets: session state, private documents, identity flows, intranet content, customer data, and personal information.
The integrity and availability dimensions reported by aggregators are less intuitive for an information disclosure bug, and public descriptions should be treated cautiously until Microsoft provides more detail. CVSS fields can reflect technical consequences that do not map neatly to a one-sentence advisory. Defenders should avoid building elaborate theories from the vector alone.
What CVSS can do is help prioritize action. A high-severity, network-reachable, no-privileges-required browser vulnerability on mobile devices deserves quick remediation even without a known exploit in the wild. It may not outrank an actively exploited domain controller flaw, but it should not be parked behind cosmetic application updates.
Modern browser vulnerabilities are particularly sensitive because patches are public artifacts. If the advisory says exactly which component mishandled which data under which conditions, attackers get a map. If the advisory says only that a vulnerable version exists and a fixed version is available, defenders get enough to patch while attackers get less of a head start.
That tradeoff frustrates serious administrators because it forces action under uncertainty. You may not know whether the bug affects a feature your users rely on heavily. You may not know whether a network gateway, safe browsing tool, or mobile threat defense product would have blocked a plausible exploit path. You may not even know whether the vulnerable code path is common.
But uncertainty is not a reason to wait. It is the defining condition of browser patching. The browser security model assumes rapid updates because the attack surface is too large, too exposed, and too valuable to defend primarily through after-the-fact analysis.
For Intune-managed environments, the work likely belongs in a blend of app inventory, compliance reporting, conditional access assumptions, and user communication. Administrators should not assume that because Edge is a Microsoft app, it is automatically current everywhere Microsoft identity is used. The Microsoft ecosystem is integrated, but app update state is still a device reality.
For unmanaged or lightly managed BYOD, the best available control may be communication plus access policy. Organizations can require current browser versions for sensitive access where tooling allows it, but many will discover gaps between what policy says and what telemetry can prove. That discovery is useful even if it is uncomfortable.
Security teams should also watch for follow-up reporting from Microsoft, CVE databases, and reputable vulnerability researchers. If technical details emerge, the response may need to shift from routine patching to targeted hunting or user notification. As of the initial disclosure window, however, the public evidence supports rapid updating rather than speculative incident declarations.
The more interesting burden falls on Microsoft. The company does not need to publish exploit-ready details, but it should provide enough plain-language guidance for administrators to understand the blast radius. If the exposure is limited to a particular feature, authentication flow, content type, or browsing condition, saying so would help defenders prioritize without materially helping attackers.
Microsoft has improved its security communication over the years, but MSRC entries can still read like they were optimized for databases rather than humans. That is tolerable for low-risk issues. For a high-severity mobile browser vulnerability involving private personal information, a little more operational clarity would go a long way.
This is especially true because Edge is part of Microsoft’s broader pitch for secure enterprise browsing. If Microsoft wants organizations to standardize on Edge across desktop and mobile, then Edge mobile advisories need to speak to enterprise reality. The audience is not only CVE scanners; it is the people responsible for whether employees can safely tap a work link on a phone.
The organizations that handle this well will be the ones that already treat mobile apps as part of the vulnerability management estate. They will know which browsers are permitted, which versions are installed, which users are exposed, and how quickly updates land. The organizations that struggle will be the ones that can produce beautiful Windows patch dashboards while guessing about the Android devices accessing the same data.
That gap is no longer defensible. Mobile devices are not secondary endpoints for many users; they are the first place a suspicious link is opened, the fastest path to approve an identity prompt, and the most convenient way to reach corporate data outside the office. A mobile browser vulnerability is therefore not a side quest. It is part of the main security story.
The practical take is not dramatic, but it is firm:
Microsoft’s Android Browser Problem Is Really an Identity Problem
Edge for Android is not just “the Windows browser, but smaller.” For many Microsoft-heavy organizations, it is the mobile doorway into Entra ID, Microsoft 365, Outlook on the web, SharePoint, Teams links, enterprise SaaS apps, and managed browsing policies. A flaw that exposes private personal information over the network therefore lands in a different category from an obscure UI bug or a low-impact crash.According to Microsoft’s Security Update Guide, CVE-2026-58297 is classified as an information disclosure vulnerability in Microsoft Edge for Android. Third-party CVE aggregators tracking the MSRC entry list the affected product as Microsoft Edge Chromium-based for Android before 150.0.4078.48, with a CVSS 3.1 base score of 7.1, a “High” severity rating, network attack vector, low attack complexity, no privileges required, and required user interaction.
That combination matters. “Network,” “low complexity,” and “no privileges required” tell administrators that the bug does not belong in the comfortable category of local-only attacks requiring prior compromise. “User interaction required” softens the rating, but only slightly, because mobile browsing is almost entirely user interaction: tapping links, opening tabs, approving prompts, and following redirects through apps that all want to become the default handler for something.
The affected version boundary is also notable. A fix at or after Edge 150.0.4078.48 implies the remediation path is straightforward for consumers: update the app. For enterprises, the path is less tidy, because managed Android fleets often depend on staged rollouts, Android Enterprise policy timing, Play Store update behavior, and the stubborn reality that mobile devices spend long stretches outside the tidy patch windows administrators design on paper.
The Advisory Says Little Because the Patch Is the Message
MSRC advisories are often terse by design, especially when disclosing browser vulnerabilities close to release. In this case, Microsoft’s public guidance does not appear to include exploit code, a detailed root cause, or a technical walk-through of the vulnerable component. That absence is not a reason to ignore the issue; it is part of the standard choreography of coordinated vulnerability disclosure.The user-supplied MSRC text points to a key scoring idea: confidence in the existence of a vulnerability and credibility of technical details. That concept is easy to overlook when administrators sort queues by CVSS alone. A vulnerability can be urgent because the vendor confirms it exists, even if the public does not yet know the exact failing function, code path, or exploit primitive.
This is where Microsoft’s role as vendor matters more than the commentary around the CVE. A vendor-confirmed vulnerability in a current browser build is not rumor. It may be technically under-described, but it is operationally real: the product team has shipped or identified a fixed version, assigned a CVE, and told the ecosystem where the risk sits.
For attackers, the lack of public detail is only a temporary obstacle. Once a patched mobile browser build exists, researchers and adversaries can compare versions, inspect Chromium-related changes where applicable, and look for behavioral differences. That does not mean exploitation is inevitable, but it does mean defenders should not confuse “no public proof of concept” with “no one can figure this out.”
Information Disclosure Is the Browser Bug That Sounds Boring Until It Isn’t
Information disclosure vulnerabilities have a branding problem. They do not carry the cinematic punch of remote code execution, and they rarely trigger the same visceral reaction as ransomware or wormable network bugs. But in a browser, “information” can mean account identifiers, tokens, browsing context, sensitive page data, autofill-adjacent material, redirect parameters, or private data exposed through an unexpected boundary failure.Microsoft’s wording for CVE-2026-58297 centers on unauthorized access to private personal information over a network. That phrasing is broad, and defenders should resist the urge to narrow it without evidence. The public record does not establish that passwords, cookies, passkeys, payment cards, or enterprise tokens are specifically exposed. It establishes that Microsoft considers the confidentiality impact high enough to warrant a high-severity rating.
The distinction matters because overclaiming vulnerability impact can be as damaging as underreacting to it. If security teams tell users “your passwords were stolen,” they may be inventing facts. If they tell users “this is only a privacy bug,” they may be minimizing a browser-class disclosure issue whose practical impact depends on what the victim was doing when exposed.
The safest enterprise posture is to treat the bug as a potentially sensitive data exposure in a mobile browser used for work and personal browsing. That does not require panic. It requires update enforcement, version visibility, and a short-term review of whether high-risk users — executives, administrators, finance teams, help desk staff, and anyone with privileged cloud access — are running vulnerable builds.
User Interaction Is Not Much of a Barrier on a Phone
The CVSS vector reportedly requires user interaction, which will tempt some readers to file CVE-2026-58297 below server-side bugs and zero-click mobile exploits. That instinct is understandable. It is also dangerous when applied too mechanically to mobile browsers.On a desktop, user interaction can mean a user must open a malicious document, visit a crafted page, or approve a prompt. On Android, interaction is the normal operating model. Links arrive through Teams, Outlook, SMS, Slack, QR codes, authenticator flows, social apps, and password reset messages. The line between “the user was tricked” and “the user used the device normally” is thin.
Mobile operating systems also amplify link-handling complexity. A tap may move the user from email to browser to identity provider to installed app and back again. Edge for Android may be part of that chain even when the user does not consciously think of themselves as “using a browser.” That makes required interaction a meaningful exploit condition, but not a comforting one.
For administrators, the correct reading is not “this can only happen if users do something foolish.” It is “this likely needs a browsing or link-opening event.” That distinction changes the response: awareness helps, but patching helps more.
The Chromium Connection Cuts Both Ways
Edge is Chromium-based, and that fact shapes how defenders should think about the bug even when the public advisory names Microsoft Edge for Android rather than generic Chromium. Chromium gives Microsoft a modern, broadly scrutinized browser engine and a rapid upstream patching model. It also means Edge shares architectural assumptions, rendering complexity, and mobile browser attack surfaces familiar to attackers.The affected product line listed by public CVE trackers is Microsoft Edge Chromium-based for Android. That does not automatically mean Chrome for Android or every Chromium-derived browser is affected. CVE naming can attach to a vendor’s specific implementation, wrapper code, sync behavior, UI surface, identity integration, or platform-specific configuration. Without Microsoft publishing a root cause, it would be irresponsible to declare this a wider Chromium bug.
Still, Chromium’s ecosystem gravity matters. Attackers understand the engine family. Security researchers know how to diff browser builds. Enterprise defenders often treat mobile browsers as interchangeable until a vulnerability reminds them that each vendor’s integration choices can create distinct risk.
Microsoft’s mobile Edge build is not just Chromium with a blue icon. It carries Microsoft account integration, enterprise management hooks, sync behavior, tracking prevention choices, Copilot-era service integration, and policy surfaces meant to make it fit into a Microsoft estate. Any one of those layers can turn a browser flaw into an organizational concern.
The Real Exposure Is Patch Visibility, Not Patch Availability
For individual users, the advice is easy: update Microsoft Edge for Android through Google Play and verify the installed version is 150.0.4078.48 or later. That is the kind of instruction security writers give so often it becomes wallpaper. The hard part is knowing whether it actually happened.Consumer Android devices typically update apps automatically, but “typically” is doing a lot of work. Auto-updates may be disabled, delayed by battery settings, constrained by network preferences, blocked by regional rollout timing, or held back on devices with limited storage. A user can be nominally protected by the Play Store update model and still run a stale browser for days or weeks.
Enterprise Android management improves the situation, but it does not eliminate it. Android Enterprise can enforce app installation and manage update behavior, yet many organizations still lack clean reporting on the exact version of every mobile browser in active use. Bring-your-own-device policies make this worse, particularly when personal devices are allowed to access work resources through mobile browsers outside full device management.
This is why a high-severity mobile browser CVE becomes a governance issue. The patch exists, but the question for IT is whether the organization can prove deployment. A vulnerability management program that sees Windows patch levels clearly but treats Android app versions as a fog bank is only half-modernized.
Edge on Android Sits in the Messy Middle of Consumer and Corporate Risk
Microsoft Edge for Android occupies a peculiar place in the security stack. It is a consumer app distributed through a consumer app store, but it is also a corporate access point for organizations standardized on Microsoft services. That dual identity complicates incident response.If this were a Windows Server vulnerability, administrators would know where to look: inventory, patch rings, maintenance windows, compensating controls, logs, and exceptions. If this were a pure consumer app bug, the advice would mostly be “update now.” Edge for Android sits between those worlds, where the device may be personally owned, the identity may be corporate, and the browser session may bridge both.
That matters most for conditional access and mobile application management. Organizations that rely on app protection policies may assume they have contained corporate data within managed apps. But browser-mediated access often tests the edges of those assumptions, especially when users open links from unmanaged contexts or authenticate through flows that shift between apps.
The right response is not to ban mobile browsing or declare BYOD dead. It is to admit that mobile browsers need the same visibility and urgency as desktop browsers. If Edge is permitted as an access path to corporate data, Edge’s version should be visible to the people responsible for protecting that data.
CVSS Tells You the Shape of Risk, Not the Story
The reported CVSS 3.1 score of 7.1 gives CVE-2026-58297 a useful shorthand: High. But CVSS is a compression algorithm for risk, not a complete threat model. It tells us the attack can be network-based, low-complexity, unauthenticated, and user-assisted, with serious confidentiality impact. It does not tell us who is likely to exploit it, what data is exposed, or how easy it is to weaponize in a real campaign.The confidentiality rating is the part administrators should notice first. A high confidentiality impact means the bug’s worst credible outcome is not a trivial leak. In browser terms, confidentiality is often the domain that matters most, because browsers are the place users bring secrets: session state, private documents, identity flows, intranet content, customer data, and personal information.
The integrity and availability dimensions reported by aggregators are less intuitive for an information disclosure bug, and public descriptions should be treated cautiously until Microsoft provides more detail. CVSS fields can reflect technical consequences that do not map neatly to a one-sentence advisory. Defenders should avoid building elaborate theories from the vector alone.
What CVSS can do is help prioritize action. A high-severity, network-reachable, no-privileges-required browser vulnerability on mobile devices deserves quick remediation even without a known exploit in the wild. It may not outrank an actively exploited domain controller flaw, but it should not be parked behind cosmetic application updates.
Sparse Detail Is a Feature of Modern Browser Security
Security professionals often complain that vendors disclose too little. The complaint is fair in the abstract: defenders benefit from knowing attack preconditions, vulnerable configurations, exploit indicators, and root cause categories. But browser vendors operate in a world where too much detail can become a recipe.Modern browser vulnerabilities are particularly sensitive because patches are public artifacts. If the advisory says exactly which component mishandled which data under which conditions, attackers get a map. If the advisory says only that a vulnerable version exists and a fixed version is available, defenders get enough to patch while attackers get less of a head start.
That tradeoff frustrates serious administrators because it forces action under uncertainty. You may not know whether the bug affects a feature your users rely on heavily. You may not know whether a network gateway, safe browsing tool, or mobile threat defense product would have blocked a plausible exploit path. You may not even know whether the vulnerable code path is common.
But uncertainty is not a reason to wait. It is the defining condition of browser patching. The browser security model assumes rapid updates because the attack surface is too large, too exposed, and too valuable to defend primarily through after-the-fact analysis.
The Admin Playbook Is Shorter Than the Risk Register
The immediate enterprise response should be practical and unglamorous. Confirm whether Microsoft Edge for Android is allowed, required, or merely tolerated in the environment. Then determine how many devices are running a version older than 150.0.4078.48 and how quickly managed devices can be pushed to the fixed build.For Intune-managed environments, the work likely belongs in a blend of app inventory, compliance reporting, conditional access assumptions, and user communication. Administrators should not assume that because Edge is a Microsoft app, it is automatically current everywhere Microsoft identity is used. The Microsoft ecosystem is integrated, but app update state is still a device reality.
For unmanaged or lightly managed BYOD, the best available control may be communication plus access policy. Organizations can require current browser versions for sensitive access where tooling allows it, but many will discover gaps between what policy says and what telemetry can prove. That discovery is useful even if it is uncomfortable.
Security teams should also watch for follow-up reporting from Microsoft, CVE databases, and reputable vulnerability researchers. If technical details emerge, the response may need to shift from routine patching to targeted hunting or user notification. As of the initial disclosure window, however, the public evidence supports rapid updating rather than speculative incident declarations.
Users Should Update, But Microsoft Should Explain the Blast Radius
For everyday Edge on Android users, the message is refreshingly simple: update the browser. Open Google Play, check Microsoft Edge, apply the latest update, and verify the version if you are in a high-risk role or using the device for work. That advice is boring because the mobile app store model was designed to make this kind of fix boring.The more interesting burden falls on Microsoft. The company does not need to publish exploit-ready details, but it should provide enough plain-language guidance for administrators to understand the blast radius. If the exposure is limited to a particular feature, authentication flow, content type, or browsing condition, saying so would help defenders prioritize without materially helping attackers.
Microsoft has improved its security communication over the years, but MSRC entries can still read like they were optimized for databases rather than humans. That is tolerable for low-risk issues. For a high-severity mobile browser vulnerability involving private personal information, a little more operational clarity would go a long way.
This is especially true because Edge is part of Microsoft’s broader pitch for secure enterprise browsing. If Microsoft wants organizations to standardize on Edge across desktop and mobile, then Edge mobile advisories need to speak to enterprise reality. The audience is not only CVE scanners; it is the people responsible for whether employees can safely tap a work link on a phone.
The Edge Patch Is a Small Test of Mobile Security Maturity
CVE-2026-58297 will probably not be remembered as one of the defining vulnerabilities of the year unless exploitation details or real-world abuse emerge. But it is a useful test case because the right response is obvious and still easy to mishandle. A high-severity mobile browser bug should trigger a quick, measurable update campaign, not a vague hope that app stores will take care of everything.The organizations that handle this well will be the ones that already treat mobile apps as part of the vulnerability management estate. They will know which browsers are permitted, which versions are installed, which users are exposed, and how quickly updates land. The organizations that struggle will be the ones that can produce beautiful Windows patch dashboards while guessing about the Android devices accessing the same data.
That gap is no longer defensible. Mobile devices are not secondary endpoints for many users; they are the first place a suspicious link is opened, the fastest path to approve an identity prompt, and the most convenient way to reach corporate data outside the office. A mobile browser vulnerability is therefore not a side quest. It is part of the main security story.
The practical take is not dramatic, but it is firm:
- Microsoft disclosed CVE-2026-58297 on July 3, 2026, as a high-severity information disclosure flaw in Microsoft Edge for Android.
- Public CVE trackers list Microsoft Edge Chromium-based for Android versions before 150.0.4078.48 as affected.
- The reported CVSS profile points to a network-reachable, low-complexity issue requiring no attacker privileges but requiring user interaction.
- The public advisory does not establish exploit-in-the-wild activity or identify exactly what private personal information may be exposed.
- Users should update Edge for Android immediately, and administrators should verify app versions rather than assuming automatic updates have completed.
- Enterprises should treat mobile browser version visibility as a core vulnerability management requirement, not a convenience feature.
References
- Primary source: MSRC
Published: 2026-07-03T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: securityvulnerability.io
CVE-2026-58297 : Information Disclosure Vulnerability in Microsoft Edge for Android
Learn about the information disclosure vulnerability in Microsoft Edge for Android that affects user privacy. Explore CVE-2026-58297 details.securityvulnerability.io - Related coverage: aha.org
h isac tlp white microsoft edge addresses exploited zero day vulnerability cve 2024 7971 8 23 2024
PDF documentwww.aha.org
- Related coverage: buildings.honeywell.com
The purpose of this document is to identify the patches that have been delivered by Microsoft® which have been tested against Pro-Watch
PDF documentbuildings.honeywell.com
- Related coverage: hhs.gov