Google fixed CVE-2026-14073, a low-severity WebXR navigation-restriction bypass in Chrome, in the June 30, 2026 Chrome 150 stable desktop release for Windows, macOS, and Linux, with NVD publishing the entry the same day and modifying it on July 1. The bug is not the kind of headline-grabbing browser flaw that sends incident responders sprinting toward emergency war rooms. But it is exactly the kind of small policy failure that explains why browser patching has become a weekly operational discipline rather than a quarterly maintenance chore.
As documented by Google’s Chrome Releases blog and the National Vulnerability Database, CVE-2026-14073 involved insufficient validation of untrusted input in WebXR, allowing a remote attacker to bypass navigation restrictions through a crafted HTML page. CISA’s ADP enrichment assigned it a CVSS 3.1 score of 4.3, while Chromium classified it as Low. That mismatch between “low” in vendor severity and “medium” in CVSS terms is the story: modern browser risk is less about any single bug than about how many browser subsystems are now trusted to enforce security boundaries on behalf of users.
The fix landed inside Chrome 150.0.7871.46/.47 for Windows and macOS and 150.0.7871.46 for Linux, according to Google’s June 30 Stable Channel update. Google said the release included 433 security fixes, a number large enough to make any individual CVE feel like a footnote. CVE-2026-14073 is one of those footnotes, but the footnote matters.
WebXR is not the everyday surface area most Windows users think about when they open Chrome to check mail, approve an invoice, or join a meeting. It is the browser API family that allows web content to interact with virtual reality and augmented reality experiences. That makes it a relatively specialized feature, but not a harmless one. Once an API connects immersive presentation, navigation, device state, user gestures, and web content, policy enforcement becomes the product.
The NVD description is short, as CVE descriptions usually are. A crafted HTML page could bypass navigation restrictions because WebXR did not sufficiently validate untrusted input. There is no public indication in the NVD record that the bug was being exploited in the wild, and CISA’s SSVC entry recorded exploitation as “none,” automation as “no,” and technical impact as “partial.” That is reassuring, but it is not a reason to ignore it.
The practical lesson is that browser security increasingly lives in the seams between features. WebXR does not need to be your organization’s most-used API to become part of your attack surface. If it ships in Chrome, if it is reachable from web content, and if it is governed by browser security policies, then it belongs in the same patch-management conversation as V8, Blink, GPU, WebUSB, WebRTC, and the rest of Chromium’s sprawling machinery.
That said, “Low” can be a dangerously soothing word in browser security. In enterprise patch dashboards, low-severity findings often sink beneath server-side remote code execution bugs, VPN flaws, privilege escalations, and actively exploited zero-days. That triage instinct is rational. It is also how client-side browser bugs can linger on machines that quietly become the most exposed endpoints in the organization.
A navigation-restriction bypass is not merely a cosmetic defect. Navigation controls are part of how browsers keep web content from pushing users, sessions, or contexts into places they were not supposed to go. A bug that weakens those restrictions may be useful in phishing chains, user-interface deception, consent-flow manipulation, or exploit staging, even if it does not by itself own the machine.
The more honest way to read CVE-2026-14073 is this: it is probably not an emergency, but it is still a browser security boundary failure. That distinction matters. Emergency patching is reserved for active exploitation and high-impact flaws; routine patching exists because a browser is a constantly updated defensive system, and small cracks accumulate.
That makes navigation policy especially sensitive. In a traditional tab, the address bar and page boundaries are familiar anchors. In immersive or semi-immersive contexts, users may rely more heavily on browser-controlled transitions, permission prompts, and trusted UI conventions. If a crafted page can bypass navigation restrictions, the attacker’s advantage is not necessarily technical wizardry; it may be confusion.
This is where “insufficient policy enforcement” becomes more interesting than the CVSS score. The phrase sounds bureaucratic, but in browser engineering it usually means the browser had a rule and some path through the code failed to apply it consistently. The bug may live in an edge case, but the edge case matters because attackers love inconsistent rules.
Google’s public advisory, like most Chrome security notes, does not disclose the detailed bug mechanics while users are still updating. That is standard practice, and for good reason. Browser bugs are often reproducible once enough implementation detail leaks, and Chromium-based browsers share enough code that one vendor’s disclosure can become another vendor’s scramble.
That is not necessarily a catastrophic error, but it is the kind of machine-readable detail that can produce messy results downstream. A scanner, asset inventory system, or vulnerability management platform may interpret version boundaries differently depending on how it ingests CPEs, vendor advisories, and CVE JSON. For Windows admins, the human answer is straightforward: get Chrome to the fixed Chrome 150 build offered for your platform. For tooling, straightforward is rarely the default.
This is why vendor advisories still matter. NVD is invaluable, but it is not the source of first disclosure here. Google’s Chrome Releases blog is the authoritative record for the Chrome update, while NVD and CISA enrich the vulnerability with scoring, weakness classification, and structured metadata. When those layers do not line up perfectly, administrators should privilege the vendor’s fixed-version guidance and use NVD as enrichment rather than gospel.
The discrepancy also underscores a broader problem with browser CVEs. Chrome’s release train moves quickly, and stable-channel versioning can differ slightly by platform. Windows and Mac received the 150.0.7871.46/.47 range, while Linux was listed at 150.0.7871.46. A rigid “less than this exact version” rule may be less useful than asking whether the channel has received the June 30 Chrome 150 security update.
Chrome can download an update without fully applying it until the browser restarts. In enterprises where users keep sessions open for days, that can leave machines technically “updated” in the console but still running the vulnerable binary. The right control is not panic. It is a relaunch policy that balances user disruption against the reality that Chrome is now one of the most security-sensitive applications on the endpoint.
CVE-2026-14073 does not justify exceptional treatment on its own. It does justify checking whether the June 30 Chrome 150 update has landed across the fleet. The same release carried hundreds of fixes, including critical and high-severity vulnerabilities in components such as Extensions, GPU, ANGLE, Dawn, WebUSB, and other browser internals. If an organization focuses only on the WebXR bug, it is looking through the wrong end of the telescope.
The right enterprise conclusion is that this CVE is a useful compliance marker. If Chrome 150 is not current on a meaningful percentage of endpoints several days after release, the issue is not WebXR. The issue is that the organization’s browser maintenance process is too slow for the software it depends on.
Modern exploit chains often combine small weaknesses. One bug creates a misleading state. Another bypasses a policy. A third escapes a sandbox or abuses a renderer flaw. CVE-2026-14073 is not publicly known to be part of such a chain, but the defensive mindset should assume that attackers collect primitives, not just complete exploits.
This is why “requires user interaction” is not the comfort it used to be. In a browser context, user interaction may mean visiting a link, clicking through a page, entering an immersive session, or responding to a prompt that appears plausible. The gap between “the user has to do something” and “the attacker can realistically induce the user to do it” is often narrower than CVSS makes it look.
There is also a social-engineering angle to navigation. Restrictions around navigation are partly designed to prevent content from forcing transitions that violate user expectations or browser policy. If WebXR creates a context where those expectations are already unfamiliar, a bypass becomes more than a technical curiosity. It becomes another way for hostile content to shape the user’s path.
That does not mean every Chromium-based browser was equally affected by CVE-2026-14073 at the same moment. The public record names Google Chrome, and downstream exposure depends on branch, build, feature flags, and integration choices. But administrators who standardize on Chromium-based browsers should not treat Chrome CVEs as Chrome-only news by default.
Microsoft Edge admins in particular should watch the corresponding Edge release cadence whenever Chromium stable absorbs a large security batch. Microsoft typically rebases Edge on Chromium updates, but timing and version numbers differ. The operational rule is simple: if Chrome shipped hundreds of security fixes, check the Edge stable channel too. The same goes for Electron-heavy environments, where applications may carry embedded Chromium versions that lag behind the browser installed on the desktop.
This is the uncomfortable reality of web-platform sprawl. Security teams have spent years inventorying operating systems and server packages, but the browser engine has become a runtime in its own right. A vulnerability in a niche API can surface through a normal browser, a packaged desktop app, a kiosk, a headset workflow, or a vendor product that quietly embeds Chromium.
The browser’s attack surface is no longer limited to HTML, JavaScript, cookies, and downloads. It includes USB, Bluetooth, GPU acceleration, media codecs, payment APIs, authentication flows, local file handling, AI-adjacent services, graphics pipelines, and immersive web features. Each new capability brings new policy checks, new permission prompts, and new ways for untrusted content to interact with trusted browser code.
CVE-2026-14073 is a small example of that larger bargain. Users want the web to be an application platform. Developers want APIs that reach deeper into devices. Vendors want browsers to compete as operating environments. Security teams inherit the consequences.
That does not mean the answer is to disable every advanced feature. Blanket lockdowns often break legitimate workflows and push users toward unsanctioned alternatives. But it does mean organizations should know which browser features they allow, which policies they enforce, and which departments actually need specialized APIs such as WebXR.
For high-security environments, reducing exposed browser capabilities is still a valid strategy. Browser hardening, site isolation, extension control, update enforcement, and feature governance are not glamorous controls. They are the controls that turn a sprawling client application into something manageable.
For CVE-2026-14073, the restricted Chromium issue means we do not have a public patch diff narrative that explains the precise validation failure. We know the affected component, the broad weakness class, the impact, and the fixed Chrome version. That is enough for patch prioritization, but not enough for deep exploit analysis.
Security teams should resist filling that gap with speculation. There is no public evidence from NVD or CISA that the bug is being exploited. There is no public proof-of-concept cited in the official records. There is no basis for describing it as a zero-day. The correct posture is measured urgency: patch because the fix is available and bundled with many other fixes, not because this specific CVE is known to be burning down networks.
This is where responsible security communication matters. Overstating a low-severity bug trains users to ignore warnings. Understating browser policy bypasses teaches administrators to postpone updates. The right middle ground is to say plainly that CVE-2026-14073 is modest in isolation and still worth closing quickly.
Patch management tends to treat CVEs as separate tickets. Browser releases do not behave that way. The unit of remediation is the browser build, not the individual vulnerability. If you install the fixed Chrome 150 build, you close CVE-2026-14073 and hundreds of other issues at once. If you delay because this one is Low, you also delay fixes for more serious bugs in the same package.
That is especially important for WindowsForum readers running mixed home labs, small-business fleets, or lightly managed environments. A browser may be the most frequently exposed application on the machine. It touches identity providers, admin consoles, cloud dashboards, remote-management portals, banking sites, developer tools, and internal apps. The browser is not “user software” in the old dismissive sense. It is privileged infrastructure with a friendly icon.
The best response to Chrome 150 is not to chase every CVE individually unless you are doing research or vendor validation. The best response is to verify that Chrome has moved to the fixed stable channel, that relaunches have occurred, and that Chromium-based alternatives are not lagging silently.
As documented by Google’s Chrome Releases blog and the National Vulnerability Database, CVE-2026-14073 involved insufficient validation of untrusted input in WebXR, allowing a remote attacker to bypass navigation restrictions through a crafted HTML page. CISA’s ADP enrichment assigned it a CVSS 3.1 score of 4.3, while Chromium classified it as Low. That mismatch between “low” in vendor severity and “medium” in CVSS terms is the story: modern browser risk is less about any single bug than about how many browser subsystems are now trusted to enforce security boundaries on behalf of users.
Chrome 150 Turns a Small WebXR Bug Into a Bigger Browser Lesson
The fix landed inside Chrome 150.0.7871.46/.47 for Windows and macOS and 150.0.7871.46 for Linux, according to Google’s June 30 Stable Channel update. Google said the release included 433 security fixes, a number large enough to make any individual CVE feel like a footnote. CVE-2026-14073 is one of those footnotes, but the footnote matters.WebXR is not the everyday surface area most Windows users think about when they open Chrome to check mail, approve an invoice, or join a meeting. It is the browser API family that allows web content to interact with virtual reality and augmented reality experiences. That makes it a relatively specialized feature, but not a harmless one. Once an API connects immersive presentation, navigation, device state, user gestures, and web content, policy enforcement becomes the product.
The NVD description is short, as CVE descriptions usually are. A crafted HTML page could bypass navigation restrictions because WebXR did not sufficiently validate untrusted input. There is no public indication in the NVD record that the bug was being exploited in the wild, and CISA’s SSVC entry recorded exploitation as “none,” automation as “no,” and technical impact as “partial.” That is reassuring, but it is not a reason to ignore it.
The practical lesson is that browser security increasingly lives in the seams between features. WebXR does not need to be your organization’s most-used API to become part of your attack surface. If it ships in Chrome, if it is reachable from web content, and if it is governed by browser security policies, then it belongs in the same patch-management conversation as V8, Blink, GPU, WebUSB, WebRTC, and the rest of Chromium’s sprawling machinery.
The Severity Label Is Accurate, But It Is Also Too Comforting
Chromium’s Low severity rating is not nonsense. Based on the public description, CVE-2026-14073 does not hand an attacker code execution, sandbox escape, credential theft, or direct memory disclosure. It requires user interaction, has low integrity impact in CISA’s CVSS vector, and does not appear to compromise confidentiality or availability.That said, “Low” can be a dangerously soothing word in browser security. In enterprise patch dashboards, low-severity findings often sink beneath server-side remote code execution bugs, VPN flaws, privilege escalations, and actively exploited zero-days. That triage instinct is rational. It is also how client-side browser bugs can linger on machines that quietly become the most exposed endpoints in the organization.
A navigation-restriction bypass is not merely a cosmetic defect. Navigation controls are part of how browsers keep web content from pushing users, sessions, or contexts into places they were not supposed to go. A bug that weakens those restrictions may be useful in phishing chains, user-interface deception, consent-flow manipulation, or exploit staging, even if it does not by itself own the machine.
The more honest way to read CVE-2026-14073 is this: it is probably not an emergency, but it is still a browser security boundary failure. That distinction matters. Emergency patching is reserved for active exploitation and high-impact flaws; routine patching exists because a browser is a constantly updated defensive system, and small cracks accumulate.
WebXR Makes the Browser’s Trust Problem More Physical
WebXR sits at an awkward frontier. It brings web content closer to device capabilities, immersive sessions, and user presence than old-fashioned document browsing ever did. The web page is no longer just a rectangle of text and images. It can become a spatial environment with different expectations around focus, movement, prompts, and transitions.That makes navigation policy especially sensitive. In a traditional tab, the address bar and page boundaries are familiar anchors. In immersive or semi-immersive contexts, users may rely more heavily on browser-controlled transitions, permission prompts, and trusted UI conventions. If a crafted page can bypass navigation restrictions, the attacker’s advantage is not necessarily technical wizardry; it may be confusion.
This is where “insufficient policy enforcement” becomes more interesting than the CVSS score. The phrase sounds bureaucratic, but in browser engineering it usually means the browser had a rule and some path through the code failed to apply it consistently. The bug may live in an edge case, but the edge case matters because attackers love inconsistent rules.
Google’s public advisory, like most Chrome security notes, does not disclose the detailed bug mechanics while users are still updating. That is standard practice, and for good reason. Browser bugs are often reproducible once enough implementation detail leaks, and Chromium-based browsers share enough code that one vendor’s disclosure can become another vendor’s scramble.
The CPE Trail Shows Why Vulnerability Data Still Frustrates Admins
The NVD change history for CVE-2026-14073 contains a small oddity that will look familiar to anyone who has built vulnerability workflows around CPEs. NIST’s initial analysis added a Chrome CPE for versions up to, but excluding, 150.0.7871.46, while the CVE description says Chrome prior to 150.0.7871.47. The same configuration also appears under an AND relationship with Windows, Linux kernel, and macOS operating-system CPEs.That is not necessarily a catastrophic error, but it is the kind of machine-readable detail that can produce messy results downstream. A scanner, asset inventory system, or vulnerability management platform may interpret version boundaries differently depending on how it ingests CPEs, vendor advisories, and CVE JSON. For Windows admins, the human answer is straightforward: get Chrome to the fixed Chrome 150 build offered for your platform. For tooling, straightforward is rarely the default.
This is why vendor advisories still matter. NVD is invaluable, but it is not the source of first disclosure here. Google’s Chrome Releases blog is the authoritative record for the Chrome update, while NVD and CISA enrich the vulnerability with scoring, weakness classification, and structured metadata. When those layers do not line up perfectly, administrators should privilege the vendor’s fixed-version guidance and use NVD as enrichment rather than gospel.
The discrepancy also underscores a broader problem with browser CVEs. Chrome’s release train moves quickly, and stable-channel versioning can differ slightly by platform. Windows and Mac received the 150.0.7871.46/.47 range, while Linux was listed at 150.0.7871.46. A rigid “less than this exact version” rule may be less useful than asking whether the channel has received the June 30 Chrome 150 security update.
Windows Shops Should Treat This as a Patch Hygiene Test
For unmanaged users, the mitigation is boring: open Chrome, let the browser update, and relaunch. For managed Windows environments, the story is about whether Chrome updates are actually flowing, whether relaunches are enforced, and whether reporting reflects the running version rather than the downloaded-but-not-applied version. Browser patching fails most often in that final inch.Chrome can download an update without fully applying it until the browser restarts. In enterprises where users keep sessions open for days, that can leave machines technically “updated” in the console but still running the vulnerable binary. The right control is not panic. It is a relaunch policy that balances user disruption against the reality that Chrome is now one of the most security-sensitive applications on the endpoint.
CVE-2026-14073 does not justify exceptional treatment on its own. It does justify checking whether the June 30 Chrome 150 update has landed across the fleet. The same release carried hundreds of fixes, including critical and high-severity vulnerabilities in components such as Extensions, GPU, ANGLE, Dawn, WebUSB, and other browser internals. If an organization focuses only on the WebXR bug, it is looking through the wrong end of the telescope.
The right enterprise conclusion is that this CVE is a useful compliance marker. If Chrome 150 is not current on a meaningful percentage of endpoints several days after release, the issue is not WebXR. The issue is that the organization’s browser maintenance process is too slow for the software it depends on.
The Crafted HTML Page Is Still the Oldest Trick in the Browser Book
The attack vector described by NVD is almost mundane: a remote attacker uses a crafted HTML page, and the user must interact with it. That sounds less alarming than a wormable network exploit, but it is also the normal shape of browser exploitation. Users browse. Attackers build pages. The browser mediates the fight.Modern exploit chains often combine small weaknesses. One bug creates a misleading state. Another bypasses a policy. A third escapes a sandbox or abuses a renderer flaw. CVE-2026-14073 is not publicly known to be part of such a chain, but the defensive mindset should assume that attackers collect primitives, not just complete exploits.
This is why “requires user interaction” is not the comfort it used to be. In a browser context, user interaction may mean visiting a link, clicking through a page, entering an immersive session, or responding to a prompt that appears plausible. The gap between “the user has to do something” and “the attacker can realistically induce the user to do it” is often narrower than CVSS makes it look.
There is also a social-engineering angle to navigation. Restrictions around navigation are partly designed to prevent content from forcing transitions that violate user expectations or browser policy. If WebXR creates a context where those expectations are already unfamiliar, a bypass becomes more than a technical curiosity. It becomes another way for hostile content to shape the user’s path.
Chromium’s Scale Makes Low-Severity Bugs Hard to Dismiss
Chrome is not merely a browser; it is the reference implementation for much of the modern web platform. Chromium code flows into Microsoft Edge, Brave, Vivaldi, Opera, Electron applications, embedded browsers, and countless downstream products. A low-severity Chrome bug may have a different impact depending on where the code lands and how quickly each downstream project updates.That does not mean every Chromium-based browser was equally affected by CVE-2026-14073 at the same moment. The public record names Google Chrome, and downstream exposure depends on branch, build, feature flags, and integration choices. But administrators who standardize on Chromium-based browsers should not treat Chrome CVEs as Chrome-only news by default.
Microsoft Edge admins in particular should watch the corresponding Edge release cadence whenever Chromium stable absorbs a large security batch. Microsoft typically rebases Edge on Chromium updates, but timing and version numbers differ. The operational rule is simple: if Chrome shipped hundreds of security fixes, check the Edge stable channel too. The same goes for Electron-heavy environments, where applications may carry embedded Chromium versions that lag behind the browser installed on the desktop.
This is the uncomfortable reality of web-platform sprawl. Security teams have spent years inventorying operating systems and server packages, but the browser engine has become a runtime in its own right. A vulnerability in a niche API can surface through a normal browser, a packaged desktop app, a kiosk, a headset workflow, or a vendor product that quietly embeds Chromium.
The Real Risk Is Not WebXR Adoption, But Browser Feature Creep
Many readers will reasonably ask whether WebXR is enabled, used, or relevant in their environment. In some organizations, the answer may be “barely.” That can reduce practical exposure. It does not eliminate the lesson.The browser’s attack surface is no longer limited to HTML, JavaScript, cookies, and downloads. It includes USB, Bluetooth, GPU acceleration, media codecs, payment APIs, authentication flows, local file handling, AI-adjacent services, graphics pipelines, and immersive web features. Each new capability brings new policy checks, new permission prompts, and new ways for untrusted content to interact with trusted browser code.
CVE-2026-14073 is a small example of that larger bargain. Users want the web to be an application platform. Developers want APIs that reach deeper into devices. Vendors want browsers to compete as operating environments. Security teams inherit the consequences.
That does not mean the answer is to disable every advanced feature. Blanket lockdowns often break legitimate workflows and push users toward unsanctioned alternatives. But it does mean organizations should know which browser features they allow, which policies they enforce, and which departments actually need specialized APIs such as WebXR.
For high-security environments, reducing exposed browser capabilities is still a valid strategy. Browser hardening, site isolation, extension control, update enforcement, and feature governance are not glamorous controls. They are the controls that turn a sprawling client application into something manageable.
Google’s Restricted Details Policy Is Annoying and Necessary
Google’s advisory notes that access to bug details and links may remain restricted until most users have updated, and that restrictions may continue when the bug affects third-party libraries used elsewhere. This frustrates defenders who want to understand exact exploitability, but it is a reasonable tradeoff for browser vulnerabilities. Publishing a detailed recipe before the patch has reached enough machines would help attackers more than administrators.For CVE-2026-14073, the restricted Chromium issue means we do not have a public patch diff narrative that explains the precise validation failure. We know the affected component, the broad weakness class, the impact, and the fixed Chrome version. That is enough for patch prioritization, but not enough for deep exploit analysis.
Security teams should resist filling that gap with speculation. There is no public evidence from NVD or CISA that the bug is being exploited. There is no public proof-of-concept cited in the official records. There is no basis for describing it as a zero-day. The correct posture is measured urgency: patch because the fix is available and bundled with many other fixes, not because this specific CVE is known to be burning down networks.
This is where responsible security communication matters. Overstating a low-severity bug trains users to ignore warnings. Understating browser policy bypasses teaches administrators to postpone updates. The right middle ground is to say plainly that CVE-2026-14073 is modest in isolation and still worth closing quickly.
The Chrome 150 Release Is the Bigger Patch Event
The Chrome 150 stable release is much larger than this one CVE. Google’s post lists 433 security fixes, including numerous critical and high-severity flaws across core browser components. That volume makes individual vulnerability triage difficult, but it also strengthens the case for rapid adoption of the whole release.Patch management tends to treat CVEs as separate tickets. Browser releases do not behave that way. The unit of remediation is the browser build, not the individual vulnerability. If you install the fixed Chrome 150 build, you close CVE-2026-14073 and hundreds of other issues at once. If you delay because this one is Low, you also delay fixes for more serious bugs in the same package.
That is especially important for WindowsForum readers running mixed home labs, small-business fleets, or lightly managed environments. A browser may be the most frequently exposed application on the machine. It touches identity providers, admin consoles, cloud dashboards, remote-management portals, banking sites, developer tools, and internal apps. The browser is not “user software” in the old dismissive sense. It is privileged infrastructure with a friendly icon.
The best response to Chrome 150 is not to chase every CVE individually unless you are doing research or vendor validation. The best response is to verify that Chrome has moved to the fixed stable channel, that relaunches have occurred, and that Chromium-based alternatives are not lagging silently.
The June 30 WebXR Fix Leaves Administrators With a Short Checklist
CVE-2026-14073 is unlikely to be the most dangerous Chrome flaw patched this summer, but it is a clean example of how small browser policy failures should be handled. Treat it as a reminder to validate process, not as an excuse for alarm.- Chrome users should update to the fixed Chrome 150 stable build and relaunch the browser so the patched binary is actually running.
- Windows administrators should confirm fleet versions through management tooling rather than assuming Chrome’s auto-update mechanism has completed the job.
- Security teams should prioritize the full June 30 Chrome 150 security release, not just the WebXR CVE, because Google bundled hundreds of fixes into the same update.
- Organizations using Microsoft Edge or other Chromium-based browsers should verify their vendors’ corresponding updates instead of assuming Chrome’s fix automatically covers them.
- Environments with no business need for immersive web features should review browser policy options and reduce unnecessary API exposure where doing so does not break legitimate workflows.
- Vulnerability managers should treat NVD and CISA enrichment as useful signals while still deferring to Google’s Chrome release guidance for fixed-version interpretation.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:58-07:00
NVD - CVE-2026-14073
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:58-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-14073 - Google Chrome WebXR Navigation Restriction Bypass
Insufficient validation of untrusted input in WebXR in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)cvefeed.io - Related coverage: radar.offseq.com
CVE-2026-14073: Insufficient policy enforcement in Google Chrome - Live Threat Intelligence - Threat Radar | OffSeq.com
Detailed information about CVE-2026-14073: Insufficient policy enforcement in Google Chrome affecting Google Chrome. Get real-time updates, technical details, aradar.offseq.com - Official source: nist.gov
National Vulnerability Database
NIST maintains the National Vulnerability Database (NVD), a repository of information on software and hardware flaws that can compromise computer security. This is a key piece of the nation’s cybersecurity infrastructure.www.nist.gov - Related coverage: labs.cloudsecurityalliance.org
NVD Enrichment Triage: Enterprise Vulnerability Programs Must Adapt
PDF documentlabs.cloudsecurityalliance.org