Google disclosed CVE-2026-14105 on June 30, 2026, as a low-severity Chrome Speech flaw fixed in Chrome 150.0.7871.47, while NVD and CISA subsequently published sharply different CVSS assessments for the same same-origin-policy bypass. That disagreement is the story. A bug Google describes as a narrow policy-enforcement failure has become a useful case study in how browser vulnerabilities are now interpreted by databases, vendors, and defenders under very different incentives. For Windows users and administrators, the practical answer is simple: update Chrome and Chromium-based browsers quickly, but do not mistake the highest score in the feed for the most complete risk model.
CVE-2026-14105 is not, on its face, the kind of Chrome vulnerability that usually dominates emergency patch cycles. The description published through Chrome and reflected by the National Vulnerability Database says the flaw involved “insufficient policy enforcement” in Speech, allowing a remote attacker to bypass the same-origin policy with a crafted HTML page in Chrome versions before 150.0.7871.47. Google’s Chromium severity for the issue is listed as Low.
That last word matters. Browser teams do not assign “Low” to mean “irrelevant,” but they usually reserve higher severities for memory corruption, sandbox escapes, universal cross-site scripting, code execution, or bugs with direct confidentiality impact. A same-origin-policy bypass can be serious, but the devil is in the boundary that was crossed, what data could actually be reached, whether the user had to interact, and whether another vulnerability was needed to turn it into something more.
NVD’s initial analysis landed at a CVSS 3.1 base score of 4.3, or Medium. Its vector describes a network-reachable bug with low attack complexity, no privileges required, user interaction required, unchanged scope, no confidentiality impact, low integrity impact, and no availability impact. In plain English, NVD appears to have treated the bug as a web-delivered policy bypass that could tamper with something limited, but not as a full browser compromise.
CISA’s ADP enrichment, however, attached a 9.6 Critical score with changed scope and high impacts to confidentiality, integrity, and availability. That is an enormous gap. It is not a rounding error or a philosophical difference between “low” and “medium”; it is the difference between “schedule this into the normal browser update cadence” and “why is this not at the top of the patch dashboard?”
That is why the phrase “bypass same origin policy” tends to raise eyebrows even when the affected component sounds peripheral. Speech features sit in that awkward browser territory where user-facing convenience, permissions, media surfaces, accessibility, and web platform APIs intersect. When policy enforcement in such a component is wrong, the interesting question is not whether Speech itself is fashionable; it is whether that component became a side door around a more fundamental web security rule.
Still, not every same-origin-policy bypass is equivalent. Some leaks are narrow, timing-based, origin-specific, gesture-dependent, or limited to state changes rather than readable data. Some require the target site to use a particular API or to expose a particular pattern. Some are dangerous mainly as exploit-chain material, where they help turn another bug from theoretical to practical.
That nuance is likely why Google’s own advisory language is restrained. Chrome’s stable-channel notes for the June 30 desktop update, as identified in the CVE record and summarized by Malwarebytes, shipped Chrome 150.0.7871.46/.47 for Windows and Mac and 150.0.7871.46 for Linux, with a very large batch of security fixes. CVE-2026-14105 was one tile in that mosaic, not the headline critical bug.
That does not necessarily mean one party is incompetent. It means the public vulnerability ecosystem is trying to compress a messy technical fact pattern into fields that downstream tools can sort, color, alert on, and escalate. Once the score enters scanners, dashboards, ticketing systems, and compliance reports, it can become more operationally important than the underlying prose.
CISA’s SSVC fields for this CVE reportedly list exploitation as “none,” automatable as “no,” and technical impact as “total.” That combination is odd enough to merit human attention. If exploitation is not observed and the attack is not automatable, a Critical CVSS score may still be possible in theory, but it should not be read as proof of active mass exploitation.
This is the trap for defenders. A Critical number looks definitive, while the vulnerability text looks modest. In reality, both are summaries of partial information. Until Google opens more of the Chromium issue history or researchers publish a technical write-up, the safest reading is that CVE-2026-14105 is patched, plausible from the web, requires user interaction, and may have more theoretical impact under one scoring model than Google’s severity label suggests.
When a browser release fixes hundreds of flaws, triage by single-CVE drama becomes less useful than deployment discipline. The browser is now one of the highest-value enterprise applications on every Windows endpoint. It is a document renderer, identity front end, password vault, collaboration shell, extension host, PDF viewer, WebRTC client, and application runtime. Any large Chrome security update should be treated less like a consumer app refresh and more like an operating-system-facing patch.
For unmanaged users, Chrome’s automatic updater usually does the quiet work. But the update is only complete after the browser restarts, and many users keep sessions alive for days. On Windows, that means the important user behavior is not just “Chrome says update available,” but “Chrome has relaunched into 150.0.7871.47 or later.”
For managed fleets, the risk is policy drag. Enterprises often stage browser rollouts to avoid breaking web apps, extensions, authentication flows, or media-heavy internal tools. That caution is understandable, but every delay widens the window in which public CVE data can be turned into proof-of-concept research or attacker experimentation.
Edge is the special case for WindowsForum readers because it is both a Chromium browser and a Microsoft-managed Windows default. Microsoft usually ships Edge security updates on its own channel, and enterprise administrators may manage it through Microsoft policies rather than Google’s. The operational point is simple: checking Chrome is not enough if users also run Edge or another Chromium derivative.
This is particularly important for vulnerabilities in web platform behavior rather than browser-brand features. A bug in a Google account integration feature might be Chrome-specific. A bug in Chromium’s handling of origin boundaries, parsing, rendering, PDF, WebRTC, media, or permissions is more likely to have downstream relevance. Speech sits close enough to the web platform that administrators should watch derivative-browser advisories rather than assume Chrome is the only affected surface.
The consumer version of this advice is less elegant but more useful: update every browser you actually use. Windows users often keep Edge as the default for system links, Chrome for daily browsing, and another Chromium browser for privacy or testing. Attackers do not care which icon you meant to click.
For CVE-2026-14105, the known affected configuration shown in the change history is the Google Chrome application CPE with versions up to, but excluding, 150.0.7871.47. That is the meaningful product mapping for the CVE as published. The “missing CPE” language is a general NVD workflow prompt rather than proof that the record lacks all product identification.
The harder question is whether additional CPEs should appear for downstream Chromium-based browsers. Usually, those vendors receive their own advisories, version ranges, and sometimes separate CPE mappings if the vulnerability is confirmed in their builds. NVD’s Chrome entry should not be treated as a complete inventory of every Chromium-derived product that may need patching.
This is where vulnerability scanners can mislead both ways. A scanner that keys only on Google Chrome may under-report exposure in Edge or other Chromium browsers. A scanner that broadly maps Chromium CVEs to every derivative browser may over-report until vendors confirm patched builds. The right operational posture is to track vendor-specific updates while understanding that the underlying engine risk may propagate.
Same-origin-policy issues are particularly chain-friendly because they affect trust boundaries rather than memory safety alone. An attacker may not need code execution if the goal is to alter state, confuse a web app, abuse an authenticated session, or extract a narrow but valuable signal. Conversely, a bug that looks like a limited policy bypass may become more powerful when paired with a permissions weakness, extension behavior, or site-specific design flaw.
That said, defenders should resist the opposite panic. Nothing in the public CVE data indicates observed exploitation for CVE-2026-14105, and CISA’s own SSVC entry reportedly marks exploitation as none. There is also no public technical detail, at least in the accessible advisory material, showing that the bug produces arbitrary code execution or a reliable drive-by compromise.
So the measured response is not “drop everything because CISA says 9.6.” It is “do not let Chrome lag behind while arguing over whether this one CVE is Low, Medium, or Critical.” The browser update contains many fixes, and the aggregate risk of postponing it is stronger than the drama around any single score.
A Speech bug that bypasses same-origin policy is therefore not just a small defect in a niche API. It is another reminder that the web platform’s attack surface is no longer defined only by HTML, JavaScript, and cookies. Modern sites ask browsers to broker microphones, cameras, GPUs, Bluetooth devices, USB devices, HID devices, file handles, notifications, local models, payment flows, and identity tokens.
Every one of those APIs needs a coherent answer to the same questions: which origin asked, which user gesture authorized it, what data can flow back, what can persist, and what happens inside iframes or embedded contexts. “Insufficient policy enforcement” is the bland phrase that appears when one of those answers is wrong.
The industry’s move toward AI-assisted and voice-driven interfaces will only increase the pressure on these surfaces. Speech features are not going away. If anything, they are likely to become more deeply integrated into browsers and operating systems, especially on Windows machines where productivity software, web apps, and accessibility tools overlap.
The most mature organizations already know this. They enforce browser version baselines, watch for pending relaunches, inventory extensions, and treat managed browser policies as part of the security stack. Less mature environments still rely on automatic updates and user restarts, which works until it does not.
The operational friction is real. Browser updates can break legacy extensions, old enterprise portals, line-of-business apps, media players, and brittle identity workflows. Reports on Reddit after Chrome 150’s release included users complaining about changes affecting native video controls and Manifest V2 extension workarounds, though such anecdotes are not the same thing as confirmed security regressions. They do, however, explain why some administrators hesitate before forcing a fast rollout.
But the answer to fragility is testing rings, not indefinite delay. Push Chrome and Edge updates first to IT and pilot groups, then to broad production with a short deadline. Track relaunch compliance. Keep rollback options narrow and time-limited. The browser is too exposed to be governed by the slowest internal web app.
Checking that version is mundane but important. In Chrome, the About page triggers an update check and shows whether a relaunch is required. In managed Windows environments, administrators should verify installed versions through their endpoint-management tools rather than assume update policy equals update completion.
Edge and other Chromium-based browsers require separate checks. The version number will not necessarily match Chrome’s exactly, because vendors ship their own builds. What matters is whether the vendor has released a build incorporating the Chromium fix set corresponding to the June 30 Chrome security update.
The longer a browser remains behind the fixed branch, the less relevant the original severity debate becomes. Public vulnerability data is a map. Patch diffing is a road. Attackers are very good at using one to find the other.
That uncertainty is not a failure of disclosure so much as a feature of browser security. Vendors often restrict issue details until most users are patched. That protects users, but it also leaves defenders reading tea leaves from CVSS vectors, CWE tags, and terse release notes. The result is a vulnerability culture that is simultaneously overspecified and underexplained.
The best reading is conservative but not alarmist. Treat CVE-2026-14105 as a real browser boundary bug fixed in Chrome 150.0.7871.47. Treat the Critical ADP score as a signal to look carefully, not as proof of a known crisis. Treat Google’s Low severity as useful vendor context, not as a reason to defer the update.
Most of all, treat the Chrome 150 update as the security event, not this one CVE in isolation. A browser release containing hundreds of security fixes is exactly the kind of patch that should move quickly through Windows fleets.
A Low-Severity Chrome Bug Walked Into a Critical-Risk Pipeline
CVE-2026-14105 is not, on its face, the kind of Chrome vulnerability that usually dominates emergency patch cycles. The description published through Chrome and reflected by the National Vulnerability Database says the flaw involved “insufficient policy enforcement” in Speech, allowing a remote attacker to bypass the same-origin policy with a crafted HTML page in Chrome versions before 150.0.7871.47. Google’s Chromium severity for the issue is listed as Low.That last word matters. Browser teams do not assign “Low” to mean “irrelevant,” but they usually reserve higher severities for memory corruption, sandbox escapes, universal cross-site scripting, code execution, or bugs with direct confidentiality impact. A same-origin-policy bypass can be serious, but the devil is in the boundary that was crossed, what data could actually be reached, whether the user had to interact, and whether another vulnerability was needed to turn it into something more.
NVD’s initial analysis landed at a CVSS 3.1 base score of 4.3, or Medium. Its vector describes a network-reachable bug with low attack complexity, no privileges required, user interaction required, unchanged scope, no confidentiality impact, low integrity impact, and no availability impact. In plain English, NVD appears to have treated the bug as a web-delivered policy bypass that could tamper with something limited, but not as a full browser compromise.
CISA’s ADP enrichment, however, attached a 9.6 Critical score with changed scope and high impacts to confidentiality, integrity, and availability. That is an enormous gap. It is not a rounding error or a philosophical difference between “low” and “medium”; it is the difference between “schedule this into the normal browser update cadence” and “why is this not at the top of the patch dashboard?”
The Same-Origin Policy Is Boring Until It Fails
The same-origin policy is one of the browser’s oldest and most important security boundaries. It is the rule that generally prevents a page from one origin from reading or manipulating sensitive content belonging to another origin. Without it, the modern web collapses into an ambient-authentication disaster, because every site you visit would be in a position to abuse whatever you are logged into elsewhere.That is why the phrase “bypass same origin policy” tends to raise eyebrows even when the affected component sounds peripheral. Speech features sit in that awkward browser territory where user-facing convenience, permissions, media surfaces, accessibility, and web platform APIs intersect. When policy enforcement in such a component is wrong, the interesting question is not whether Speech itself is fashionable; it is whether that component became a side door around a more fundamental web security rule.
Still, not every same-origin-policy bypass is equivalent. Some leaks are narrow, timing-based, origin-specific, gesture-dependent, or limited to state changes rather than readable data. Some require the target site to use a particular API or to expose a particular pattern. Some are dangerous mainly as exploit-chain material, where they help turn another bug from theoretical to practical.
That nuance is likely why Google’s own advisory language is restrained. Chrome’s stable-channel notes for the June 30 desktop update, as identified in the CVE record and summarized by Malwarebytes, shipped Chrome 150.0.7871.46/.47 for Windows and Mac and 150.0.7871.46 for Linux, with a very large batch of security fixes. CVE-2026-14105 was one tile in that mosaic, not the headline critical bug.
The Score Disagreement Is a Warning About Automated Urgency
The most striking feature of CVE-2026-14105 is not the vulnerability description. It is the scoring contradiction. Google calls the Chromium severity Low; NVD scores it Medium; CISA ADP scores it Critical.That does not necessarily mean one party is incompetent. It means the public vulnerability ecosystem is trying to compress a messy technical fact pattern into fields that downstream tools can sort, color, alert on, and escalate. Once the score enters scanners, dashboards, ticketing systems, and compliance reports, it can become more operationally important than the underlying prose.
CISA’s SSVC fields for this CVE reportedly list exploitation as “none,” automatable as “no,” and technical impact as “total.” That combination is odd enough to merit human attention. If exploitation is not observed and the attack is not automatable, a Critical CVSS score may still be possible in theory, but it should not be read as proof of active mass exploitation.
This is the trap for defenders. A Critical number looks definitive, while the vulnerability text looks modest. In reality, both are summaries of partial information. Until Google opens more of the Chromium issue history or researchers publish a technical write-up, the safest reading is that CVE-2026-14105 is patched, plausible from the web, requires user interaction, and may have more theoretical impact under one scoring model than Google’s severity label suggests.
Chrome 150 Was Already a Patch-Management Event
CVE-2026-14105 arrived inside a noisy Chrome update, not as a lonely advisory. Malwarebytes described the June 30 Chrome release as another “whopper” update, noting that Google’s stable-channel update included hundreds of security fixes. That scale changes how administrators should think about individual CVEs.When a browser release fixes hundreds of flaws, triage by single-CVE drama becomes less useful than deployment discipline. The browser is now one of the highest-value enterprise applications on every Windows endpoint. It is a document renderer, identity front end, password vault, collaboration shell, extension host, PDF viewer, WebRTC client, and application runtime. Any large Chrome security update should be treated less like a consumer app refresh and more like an operating-system-facing patch.
For unmanaged users, Chrome’s automatic updater usually does the quiet work. But the update is only complete after the browser restarts, and many users keep sessions alive for days. On Windows, that means the important user behavior is not just “Chrome says update available,” but “Chrome has relaunched into 150.0.7871.47 or later.”
For managed fleets, the risk is policy drag. Enterprises often stage browser rollouts to avoid breaking web apps, extensions, authentication flows, or media-heavy internal tools. That caution is understandable, but every delay widens the window in which public CVE data can be turned into proof-of-concept research or attacker experimentation.
Windows Users Live in the Chromium Blast Radius
This is a Chrome CVE, but Windows users should not read that as “Google-only.” Microsoft Edge, Brave, Vivaldi, Opera, and many other browsers inherit large portions of Chromium’s engine and security model, though each vendor’s exposure depends on its branch point, feature configuration, and patch timing. A Chromium bug can therefore become a broader Windows desktop issue even when the CVE entry names Google Chrome.Edge is the special case for WindowsForum readers because it is both a Chromium browser and a Microsoft-managed Windows default. Microsoft usually ships Edge security updates on its own channel, and enterprise administrators may manage it through Microsoft policies rather than Google’s. The operational point is simple: checking Chrome is not enough if users also run Edge or another Chromium derivative.
This is particularly important for vulnerabilities in web platform behavior rather than browser-brand features. A bug in a Google account integration feature might be Chrome-specific. A bug in Chromium’s handling of origin boundaries, parsing, rendering, PDF, WebRTC, media, or permissions is more likely to have downstream relevance. Speech sits close enough to the web platform that administrators should watch derivative-browser advisories rather than assume Chrome is the only affected surface.
The consumer version of this advice is less elegant but more useful: update every browser you actually use. Windows users often keep Edge as the default for system links, Chrome for daily browsing, and another Chromium browser for privacy or testing. Attackers do not care which icon you meant to click.
The CPE Question Is Less Mysterious Than It Looks
The user-facing NVD record raises the familiar “Are we missing a CPE here?” prompt while also showing a Chrome CPE configuration for versions before 150.0.7871.47. That is confusing, but not unusual. NVD’s enrichment pipeline often evolves over the first days after publication as CPEs, references, CWEs, and CVSS vectors are added or corrected.For CVE-2026-14105, the known affected configuration shown in the change history is the Google Chrome application CPE with versions up to, but excluding, 150.0.7871.47. That is the meaningful product mapping for the CVE as published. The “missing CPE” language is a general NVD workflow prompt rather than proof that the record lacks all product identification.
The harder question is whether additional CPEs should appear for downstream Chromium-based browsers. Usually, those vendors receive their own advisories, version ranges, and sometimes separate CPE mappings if the vulnerability is confirmed in their builds. NVD’s Chrome entry should not be treated as a complete inventory of every Chromium-derived product that may need patching.
This is where vulnerability scanners can mislead both ways. A scanner that keys only on Google Chrome may under-report exposure in Edge or other Chromium browsers. A scanner that broadly maps Chromium CVEs to every derivative browser may over-report until vendors confirm patched builds. The right operational posture is to track vendor-specific updates while understanding that the underlying engine risk may propagate.
“Low” Does Not Mean “Leave It for Next Quarter”
Google’s Low severity is not a permission slip to ignore the patch. Browser vulnerabilities age quickly. Once a CVE is public, attackers and researchers can compare patched and unpatched code, inspect commits where available, and build hypotheses about exploitability. Even if a flaw is not initially severe enough for standalone compromise, it can become useful as part of a chain.Same-origin-policy issues are particularly chain-friendly because they affect trust boundaries rather than memory safety alone. An attacker may not need code execution if the goal is to alter state, confuse a web app, abuse an authenticated session, or extract a narrow but valuable signal. Conversely, a bug that looks like a limited policy bypass may become more powerful when paired with a permissions weakness, extension behavior, or site-specific design flaw.
That said, defenders should resist the opposite panic. Nothing in the public CVE data indicates observed exploitation for CVE-2026-14105, and CISA’s own SSVC entry reportedly marks exploitation as none. There is also no public technical detail, at least in the accessible advisory material, showing that the bug produces arbitrary code execution or a reliable drive-by compromise.
So the measured response is not “drop everything because CISA says 9.6.” It is “do not let Chrome lag behind while arguing over whether this one CVE is Low, Medium, or Critical.” The browser update contains many fixes, and the aggregate risk of postponing it is stronger than the drama around any single score.
The Speech Surface Deserves More Security Attention
Speech APIs are easy to underestimate because they are often discussed in terms of convenience: dictation, accessibility, voice input, transcription, and richer web apps. But browser security history has repeatedly shown that “edge” features become interesting when they cross permissions, user gestures, device access, and origin boundaries. The more capable the browser becomes, the more places policy enforcement must be exactly right.A Speech bug that bypasses same-origin policy is therefore not just a small defect in a niche API. It is another reminder that the web platform’s attack surface is no longer defined only by HTML, JavaScript, and cookies. Modern sites ask browsers to broker microphones, cameras, GPUs, Bluetooth devices, USB devices, HID devices, file handles, notifications, local models, payment flows, and identity tokens.
Every one of those APIs needs a coherent answer to the same questions: which origin asked, which user gesture authorized it, what data can flow back, what can persist, and what happens inside iframes or embedded contexts. “Insufficient policy enforcement” is the bland phrase that appears when one of those answers is wrong.
The industry’s move toward AI-assisted and voice-driven interfaces will only increase the pressure on these surfaces. Speech features are not going away. If anything, they are likely to become more deeply integrated into browsers and operating systems, especially on Windows machines where productivity software, web apps, and accessibility tools overlap.
The Enterprise Lesson Is to Patch the Browser Like Infrastructure
For years, many organizations treated browser updates as a desktop-support concern. That model is obsolete. A modern browser is infrastructure, and a Chromium security release is closer to a perimeter-control update than a cosmetic app patch. CVE-2026-14105 illustrates why: the affected boundary is the same-origin policy, a foundational control that protects authenticated enterprise web sessions.The most mature organizations already know this. They enforce browser version baselines, watch for pending relaunches, inventory extensions, and treat managed browser policies as part of the security stack. Less mature environments still rely on automatic updates and user restarts, which works until it does not.
The operational friction is real. Browser updates can break legacy extensions, old enterprise portals, line-of-business apps, media players, and brittle identity workflows. Reports on Reddit after Chrome 150’s release included users complaining about changes affecting native video controls and Manifest V2 extension workarounds, though such anecdotes are not the same thing as confirmed security regressions. They do, however, explain why some administrators hesitate before forcing a fast rollout.
But the answer to fragility is testing rings, not indefinite delay. Push Chrome and Edge updates first to IT and pilot groups, then to broad production with a short deadline. Track relaunch compliance. Keep rollback options narrow and time-limited. The browser is too exposed to be governed by the slowest internal web app.
Version Numbers Are the Only Reliable Comfort
The fixed Chrome version in the public CVE record is 150.0.7871.47. Google’s stable-channel update also used closely related platform-specific build numbers, with Malwarebytes reporting 150.0.7871.46/.47 for Windows and Mac, 150.0.7871.46 for Linux, and 150.0.7871.63 for Android. For Windows desktop users focused on this CVE, the clean target is Chrome 150.0.7871.47 or later.Checking that version is mundane but important. In Chrome, the About page triggers an update check and shows whether a relaunch is required. In managed Windows environments, administrators should verify installed versions through their endpoint-management tools rather than assume update policy equals update completion.
Edge and other Chromium-based browsers require separate checks. The version number will not necessarily match Chrome’s exactly, because vendors ship their own builds. What matters is whether the vendor has released a build incorporating the Chromium fix set corresponding to the June 30 Chrome security update.
The longer a browser remains behind the fixed branch, the less relevant the original severity debate becomes. Public vulnerability data is a map. Patch diffing is a road. Attackers are very good at using one to find the other.
The Real Signal Is Hidden Between the Scores
CVE-2026-14105 is a small public description attached to a large private reality. The public knows the affected component, the class of failure, the fixed Chrome version, the broad attack shape, and three conflicting severity interpretations. The public does not yet know the exact exploit primitive, the conditions required, the target data or action, or why CISA’s ADP model rated the impact so much higher than Google and NVD.That uncertainty is not a failure of disclosure so much as a feature of browser security. Vendors often restrict issue details until most users are patched. That protects users, but it also leaves defenders reading tea leaves from CVSS vectors, CWE tags, and terse release notes. The result is a vulnerability culture that is simultaneously overspecified and underexplained.
The best reading is conservative but not alarmist. Treat CVE-2026-14105 as a real browser boundary bug fixed in Chrome 150.0.7871.47. Treat the Critical ADP score as a signal to look carefully, not as proof of a known crisis. Treat Google’s Low severity as useful vendor context, not as a reason to defer the update.
Most of all, treat the Chrome 150 update as the security event, not this one CVE in isolation. A browser release containing hundreds of security fixes is exactly the kind of patch that should move quickly through Windows fleets.
The Chrome 150 Lesson Is Discipline Over Drama
For WindowsForum readers, the practical lesson is less about memorizing CVSS vectors and more about keeping the browser layer current. CVE-2026-14105 is interesting because the scoring is inconsistent, but the remediation path is not.- Chrome users should move to version 150.0.7871.47 or later on Windows to pick up the fix for CVE-2026-14105.
- Administrators should verify completed browser relaunches, because downloaded browser updates do not protect sessions still running old code.
- Edge and other Chromium-based browsers should be checked separately, since Chrome’s CPE entry does not automatically prove every downstream browser is patched.
- The CISA Critical score should trigger review, but the public record does not show active exploitation for this CVE.
- The NVD CPE entry for Google Chrome before 150.0.7871.47 appears to be present, while broader Chromium-derived product mapping depends on vendor-specific advisories.
- Same-origin-policy bypasses deserve attention even when vendor severity is Low, because browser boundary bugs can become useful pieces in larger exploit chains.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:55-07:00
NVD - CVE-2026-14105
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:55-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-14105 - Google Chrome Same Origin Policy Bypass
Insufficient policy enforcement in Speech in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)cvefeed.io