Google patched CVE-2026-14085 in Chrome 150.0.7871.47 for Windows and Mac on June 30, 2026, closing a low-severity Chromium CSS side-channel flaw that could let a remote attacker leak cross-origin data through a crafted HTML page. The bug is easy to dismiss because Google rated it “Low,” but the interesting part is not the label. It is what the label hides: modern browser privacy boundaries are now complicated enough that CSS, once treated as presentation plumbing, keeps showing up as a security surface.
The Chrome Releases blog says Chrome 150 was promoted to stable on June 30, 2026, for Windows, Mac, and Linux, with rollout over the following days and weeks. The Windows and Mac builds moved to 150.0.7871.46/.47, while Linux moved to 150.0.7871.46. In the same release note, Google said the update included 433 security fixes, an unusually large bundle even by Chrome’s increasingly industrial patch cadence.
CVE-2026-14085 appears deep in that list, not among the critical memory corruption bugs or the high-severity ANGLE, Skia, V8, Dawn, and browser process issues. Google’s own line item describes it simply: “Side-channel information leakage in CSS,” reported by Google on May 14, 2026. NVD’s entry, published June 30 and modified July 1, adds the operational description: Chrome before 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
That wording matters. This is not described as arbitrary code execution, sandbox escape, persistence, or credential theft. It is an information disclosure issue requiring user interaction: the victim needs to load a malicious or attacker-controlled page. CISA’s ADP enrichment gives it a CVSS 3.1 score of 6.5, which lands as Medium, because the confidentiality impact can be high even when the exploit path is not fully automatic.
The result is the kind of browser vulnerability that frustrates simple patch-priority systems. Google calls it Low in the context of Chromium security triage. CISA’s scoring says Medium. NVD had not yet provided its own NIST vector at the time reflected in the submitted entry. None of those labels is “wrong”; they are answering different questions.
A side channel is a leak through observable behavior rather than an explicit API. The attacker does not need the browser to hand over another site’s contents directly. The attacker needs some measurable difference — timing, layout, resource loading, rendering state, cache behavior, dimension changes, or computed effects — that correlates with information the browser was supposed to keep isolated.
That is why CSS bugs can be subtle. A browser may correctly block JavaScript from reading another origin’s response body, while still letting the page infer something about that response by observing how the rendering engine behaves when a crafted stylesheet, selector, or layout construct is applied. The leak is not a door left open; it is a shadow under the door.
Chrome has spent years tightening those shadows. The Same-Origin Policy, Cross-Origin Resource Sharing, CORP, COEP, COOP, SameSite cookies, storage partitioning, cache partitioning, and anti-fingerprinting mitigations all exist because the old browser model assumed too much innocence from embedded content. CVE-2026-14085 belongs to that same family of failures: not a dramatic “own the machine” bug, but a violation of the browser’s promise that one site cannot quietly learn what another site knows about you.
Chromium’s severity rating is usually influenced by exploitability in the browser’s threat model, the degree of user interaction, the likely reliability of exploitation, and whether the bug chains naturally into stronger primitives. A leak that requires a victim to open a crafted page, does not execute code, does not bypass the sandbox, and does not appear to be exploited in the wild can reasonably land at Low inside Chrome’s release notes.
CVSS, by contrast, compresses a vulnerability into a scoring formula. If a network attacker can trigger the flaw with low complexity, no privileges, required user interaction, unchanged scope, and a high confidentiality impact, Medium is a predictable result. CVSS is useful for triage, but it can make a browser privacy bug look more operationally urgent than the vendor’s own exploitability call.
The practical reading for administrators is simple: do not treat “Low” as “ignore,” but do not panic as though this were a Chrome zero-day RCE. CVE-2026-14085 is a reason to make sure Chrome’s normal update machinery is working. It is not, based on the public record, a reason to trigger emergency incident response on its own.
A malicious page should not be able to read your corporate inbox because you are signed into it in another tab. It should not be able to infer the contents of a private dashboard, probe whether a particular internal document exists, or learn state that only an authenticated session should know. The browser’s security model is built around the idea that origins are hard compartments, even when pages embed images, frames, styles, scripts, and other resources from across the web.
Side-channel flaws are dangerous precisely because they nibble at those compartments without breaking them visibly. An attacker may not get a clean file download or a database dump. Instead, the attacker may get enough bits to answer a targeted question: Is the user logged in? Does this URL return a different size for this account? Does a hidden resource exist? Does a particular state change alter rendering time?
For most home users, that sounds remote. For targeted users — administrators, developers, executives, support staff, journalists, and anyone with privileged browser sessions — it is more consequential. The modern browser is not just a document viewer. It is the front end for identity, cloud control planes, line-of-business apps, and internal knowledge systems.
The wider answer is more delicate. CVE-2026-14085 is a Chromium vulnerability, and Chromium is the upstream engine for more than Google Chrome. Microsoft Edge, Brave, Vivaldi, Opera, and other Chromium-based browsers may inherit upstream flaws depending on whether the vulnerable code path is present and how quickly each vendor pulls and ships the fix. But CVE records often list the product and vendor that assigned or disclosed the issue first, not every downstream product that may need a corresponding update.
For Windows admins, Microsoft Edge is the obvious second browser to check. Microsoft’s Edge security release notes say that Edge Stable version 150.0.4078.48, released July 2, 2026, incorporated the latest Chromium project security updates. Microsoft did not necessarily enumerate CVE-2026-14085 in the excerpted release note at publication time, but the phrasing is the familiar Edge pattern for absorbing Chromium security fixes.
That means the absence of a downstream CPE in a CVE entry should not be treated as proof that a Chromium-based browser is safe. It may mean the downstream vendor has not published its own mapping, the CPE enrichment has not caught up, the product’s code path differs, or the advisory is intentionally scoped to Google Chrome. Asset management systems should therefore track browser versions and vendor advisories, not just one CVE-to-CPE row.
Chrome’s rapid-update model helps consumers because most machines patch quietly. It complicates enterprises because some environments pin versions, stage rollouts, test extensions, or route browser updates through software distribution tools. If Chrome 150.0.7871.47 is available but a fleet is stuck on an earlier build for compatibility reasons, the exposure is not theoretical simply because Google marked one item Low.
The issue also lands at an awkward moment for organizations that use multiple Chromium browsers. A machine may have Edge as the default, Chrome for developer tooling, a vendor-mandated Chromium fork for a legacy workflow, and WebView2 embedded inside business applications. Not all of those update channels move together. Not all of them show up in the same dashboard.
The sane operational move is boring: verify versions. Chrome’s own help page triggers an update check for consumer builds. Enterprise admins should confirm managed Chrome baselines, check Edge Stable on Windows endpoints, and inspect any packaged Chromium runtime that does not follow the normal evergreen update stream. The vulnerability itself may be low-drama, but the inventory problem around browsers remains high-drama.
That volume creates a communications problem. Users cannot meaningfully understand 433 fixes. Admins cannot manually reason about every CVE before approving a browser update. Security teams cannot build a bespoke response for each low-severity leak without drowning in process.
So the real message of Chrome 150 is not “this one CSS bug is terrifying.” It is that the browser has become one of the densest pieces of exposed software on the endpoint, and its security depends on constant, mostly invisible maintenance. A single Chrome release can patch enough issues to resemble a quarterly operating system update.
This is also why attackers love browsers. The browser consumes attacker-controlled content by design. It parses hostile HTML, CSS, JavaScript, images, fonts, video, GPU shaders, compressed streams, PDFs, and device APIs, all while holding authenticated sessions to valuable services. The miracle is not that bugs exist. The miracle is that the web works as safely as it does.
CSS remains stubborn because it is both declarative and powerful. It lets documents react to state. It lets layout engines make decisions. It lets pages conditionally load resources, adapt to media, transform content, and produce observable differences. Every one of those features is useful; every one can become part of an inference attack if paired with the right primitive.
CVE-2026-14085’s public description is sparse, and Google commonly restricts bug details until most users have received a fix. That restraint is sensible, but it leaves defenders with a familiar gap: enough information to patch, not enough to fully model exploit mechanics. In browser security, that is usually the correct tradeoff.
The bigger lesson is that information disclosure is no longer a second-class category. In a world of bearer tokens, session cookies, account state, private URLs, and personalized cloud data, small leaks can be chained into useful intelligence. The impact depends less on the label and more on what the victim’s browser can see.
A Chrome bug report can be a recipe. If the issue is in CSS and the description already says cross-origin data can leak through a crafted HTML page, additional implementation detail may let copycat attackers build working probes before the update reaches slow-moving systems. In consumer software, patch availability and patch deployment are not the same event.
The downside is that defenders must operate from metadata. They see the component, the version boundary, the severity, the CVSS vector, the disclosure date, and the advisory language. That is enough to act, but not enough to answer every executive or compliance question with satisfying precision.
This is where security programs need maturity rather than drama. If the browser is below the fixed version, update it. If it cannot be updated, isolate or restrict it. If the asset is high-risk because it belongs to administrators or handles sensitive web apps, prioritize it above ordinary endpoints. Do not wait for exploit code to make a browser privacy bug “real.”
Microsoft’s July 2 Edge Stable release, version 150.0.4078.48, says it incorporated the latest Chromium security updates. That is the line Windows administrators should care about. If Edge is part of the standard desktop image — and in most Windows 10 and Windows 11 environments it is — then Edge’s update state needs the same attention as Chrome’s.
There is also an application-platform angle. Edge WebView2 is now a common way for Windows applications to embed web content. WebView2 generally benefits from Evergreen runtime updates, but organizations that use fixed-version runtimes or tightly controlled app packaging should verify their assumptions. Chromium security fixes do not protect a frozen runtime that never receives them.
The broader Chromium ecosystem has always been a strength and a risk. Shared engine work means security fixes can propagate widely. Shared code also means a bug in one layer can matter to many products, each with its own cadence, telemetry, release channel, and advisory language. CVE-2026-14085 is a reminder that “Chromium-based” is not a patch status.
But calming is not the same as dismissive. A user-assisted crafted-page attack is still the web’s native threat model. Phishing, malvertising, compromised legitimate sites, poisoned search results, and targeted links all exist to make victims load attacker-controlled content. “User interaction required” is a lower barrier than it sounds when the required interaction is browsing.
The confidentiality impact is the reason this deserves attention. A bug that leaks cross-origin data may not give the attacker a shell, but it can erode the boundaries that make web SSO tolerable. In a corporate environment, authenticated browser state is often more valuable than local files.
That is why patching should be measured by exposure, not by adjectives. A low-severity browser bug on a kiosk with no sensitive sessions is one thing. The same class of bug on an administrator workstation logged into cloud consoles and internal dashboards is another.
A Low-Severity Bug Lands in a Very Large Patch Train
The Chrome Releases blog says Chrome 150 was promoted to stable on June 30, 2026, for Windows, Mac, and Linux, with rollout over the following days and weeks. The Windows and Mac builds moved to 150.0.7871.46/.47, while Linux moved to 150.0.7871.46. In the same release note, Google said the update included 433 security fixes, an unusually large bundle even by Chrome’s increasingly industrial patch cadence.CVE-2026-14085 appears deep in that list, not among the critical memory corruption bugs or the high-severity ANGLE, Skia, V8, Dawn, and browser process issues. Google’s own line item describes it simply: “Side-channel information leakage in CSS,” reported by Google on May 14, 2026. NVD’s entry, published June 30 and modified July 1, adds the operational description: Chrome before 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
That wording matters. This is not described as arbitrary code execution, sandbox escape, persistence, or credential theft. It is an information disclosure issue requiring user interaction: the victim needs to load a malicious or attacker-controlled page. CISA’s ADP enrichment gives it a CVSS 3.1 score of 6.5, which lands as Medium, because the confidentiality impact can be high even when the exploit path is not fully automatic.
The result is the kind of browser vulnerability that frustrates simple patch-priority systems. Google calls it Low in the context of Chromium security triage. CISA’s scoring says Medium. NVD had not yet provided its own NIST vector at the time reflected in the submitted entry. None of those labels is “wrong”; they are answering different questions.
CSS Is No Longer Just Decoration
CSS has spent most of its public life being explained as the web’s styling layer: colors, layout, typography, responsive behavior, animation. That description is still true, but it is now badly incomplete. In a browser, CSS participates in a rendering pipeline that touches network fetches, layout timing, font selection, visited-link protections, media queries, container state, accessibility trees, GPU paths, and cross-origin isolation boundaries.A side channel is a leak through observable behavior rather than an explicit API. The attacker does not need the browser to hand over another site’s contents directly. The attacker needs some measurable difference — timing, layout, resource loading, rendering state, cache behavior, dimension changes, or computed effects — that correlates with information the browser was supposed to keep isolated.
That is why CSS bugs can be subtle. A browser may correctly block JavaScript from reading another origin’s response body, while still letting the page infer something about that response by observing how the rendering engine behaves when a crafted stylesheet, selector, or layout construct is applied. The leak is not a door left open; it is a shadow under the door.
Chrome has spent years tightening those shadows. The Same-Origin Policy, Cross-Origin Resource Sharing, CORP, COEP, COOP, SameSite cookies, storage partitioning, cache partitioning, and anti-fingerprinting mitigations all exist because the old browser model assumed too much innocence from embedded content. CVE-2026-14085 belongs to that same family of failures: not a dramatic “own the machine” bug, but a violation of the browser’s promise that one site cannot quietly learn what another site knows about you.
The Severity Split Is the Story, Not a Contradiction
The most tempting reading of CVE-2026-14085 is that somebody exaggerated or somebody undercalled it. Google says Low. CISA’s ADP score says 6.5 Medium with high confidentiality impact. NVD says it has not yet provided its own assessment. Security dashboards dislike that ambiguity, but ambiguity is normal when a vulnerability sits between theoretical web-platform leakage and practical exploit value.Chromium’s severity rating is usually influenced by exploitability in the browser’s threat model, the degree of user interaction, the likely reliability of exploitation, and whether the bug chains naturally into stronger primitives. A leak that requires a victim to open a crafted page, does not execute code, does not bypass the sandbox, and does not appear to be exploited in the wild can reasonably land at Low inside Chrome’s release notes.
CVSS, by contrast, compresses a vulnerability into a scoring formula. If a network attacker can trigger the flaw with low complexity, no privileges, required user interaction, unchanged scope, and a high confidentiality impact, Medium is a predictable result. CVSS is useful for triage, but it can make a browser privacy bug look more operationally urgent than the vendor’s own exploitability call.
The practical reading for administrators is simple: do not treat “Low” as “ignore,” but do not panic as though this were a Chrome zero-day RCE. CVE-2026-14085 is a reason to make sure Chrome’s normal update machinery is working. It is not, based on the public record, a reason to trigger emergency incident response on its own.
Cross-Origin Data Is the Browser’s Crown Jewel
The phrase cross-origin data can sound abstract until you map it to daily browser life. Your browser is simultaneously logged into webmail, identity providers, SaaS dashboards, banking sites, intranets, cloud consoles, customer portals, and collaboration tools. The reason that works at all is that each site is supposed to be isolated from the others.A malicious page should not be able to read your corporate inbox because you are signed into it in another tab. It should not be able to infer the contents of a private dashboard, probe whether a particular internal document exists, or learn state that only an authenticated session should know. The browser’s security model is built around the idea that origins are hard compartments, even when pages embed images, frames, styles, scripts, and other resources from across the web.
Side-channel flaws are dangerous precisely because they nibble at those compartments without breaking them visibly. An attacker may not get a clean file download or a database dump. Instead, the attacker may get enough bits to answer a targeted question: Is the user logged in? Does this URL return a different size for this account? Does a hidden resource exist? Does a particular state change alter rendering time?
For most home users, that sounds remote. For targeted users — administrators, developers, executives, support staff, journalists, and anyone with privileged browser sessions — it is more consequential. The modern browser is not just a document viewer. It is the front end for identity, cloud control planes, line-of-business apps, and internal knowledge systems.
The CPE Question Has a Narrow Answer and a Wider One
The submitted NVD change history shows that NIST added a CPE configuration for Google Chrome with versions up to, but excluding, 150.0.7871.47. On the narrow question — “Are we missing a CPE here?” — the answer is that the obvious Chrome CPE is present in the NVD record after the July 1 analysis update.The wider answer is more delicate. CVE-2026-14085 is a Chromium vulnerability, and Chromium is the upstream engine for more than Google Chrome. Microsoft Edge, Brave, Vivaldi, Opera, and other Chromium-based browsers may inherit upstream flaws depending on whether the vulnerable code path is present and how quickly each vendor pulls and ships the fix. But CVE records often list the product and vendor that assigned or disclosed the issue first, not every downstream product that may need a corresponding update.
For Windows admins, Microsoft Edge is the obvious second browser to check. Microsoft’s Edge security release notes say that Edge Stable version 150.0.4078.48, released July 2, 2026, incorporated the latest Chromium project security updates. Microsoft did not necessarily enumerate CVE-2026-14085 in the excerpted release note at publication time, but the phrasing is the familiar Edge pattern for absorbing Chromium security fixes.
That means the absence of a downstream CPE in a CVE entry should not be treated as proof that a Chromium-based browser is safe. It may mean the downstream vendor has not published its own mapping, the CPE enrichment has not caught up, the product’s code path differs, or the advisory is intentionally scoped to Google Chrome. Asset management systems should therefore track browser versions and vendor advisories, not just one CVE-to-CPE row.
Windows Shops Should Care Because Browsers Are Managed Infrastructure
For years, desktop browser patching was treated as userland hygiene: important, but separate from the operating system’s main maintenance rhythm. That distinction is now mostly fiction. On Windows fleets, Chrome and Edge are managed infrastructure, and their update posture affects identity security, SaaS exposure, endpoint risk, and incident blast radius.Chrome’s rapid-update model helps consumers because most machines patch quietly. It complicates enterprises because some environments pin versions, stage rollouts, test extensions, or route browser updates through software distribution tools. If Chrome 150.0.7871.47 is available but a fleet is stuck on an earlier build for compatibility reasons, the exposure is not theoretical simply because Google marked one item Low.
The issue also lands at an awkward moment for organizations that use multiple Chromium browsers. A machine may have Edge as the default, Chrome for developer tooling, a vendor-mandated Chromium fork for a legacy workflow, and WebView2 embedded inside business applications. Not all of those update channels move together. Not all of them show up in the same dashboard.
The sane operational move is boring: verify versions. Chrome’s own help page triggers an update check for consumer builds. Enterprise admins should confirm managed Chrome baselines, check Edge Stable on Windows endpoints, and inspect any packaged Chromium runtime that does not follow the normal evergreen update stream. The vulnerability itself may be low-drama, but the inventory problem around browsers remains high-drama.
The 433-Fix Release Makes Individual Bugs Harder to See
CVE-2026-14085 is not alone. Chrome 150’s stable release note is a wall of vulnerability IDs: critical use-after-free bugs, high-severity validation failures, medium implementation flaws, low-severity policy bypasses, side-channel leaks, uninitialized uses, and out-of-bounds reads. Malwarebytes characterized the release as a large update with hundreds of security fixes, while Google’s own advisory counted 433.That volume creates a communications problem. Users cannot meaningfully understand 433 fixes. Admins cannot manually reason about every CVE before approving a browser update. Security teams cannot build a bespoke response for each low-severity leak without drowning in process.
So the real message of Chrome 150 is not “this one CSS bug is terrifying.” It is that the browser has become one of the densest pieces of exposed software on the endpoint, and its security depends on constant, mostly invisible maintenance. A single Chrome release can patch enough issues to resemble a quarterly operating system update.
This is also why attackers love browsers. The browser consumes attacker-controlled content by design. It parses hostile HTML, CSS, JavaScript, images, fonts, video, GPU shaders, compressed streams, PDFs, and device APIs, all while holding authenticated sessions to valuable services. The miracle is not that bugs exist. The miracle is that the web works as safely as it does.
Side Channels Keep Punishing Assumptions
The web platform’s side-channel history is a long argument with optimism. Browser makers expose a feature, researchers discover that it reveals more state than intended, vendors add mitigations, developers complain about compatibility or precision loss, and then the cycle repeats somewhere else. Timing APIs were reduced. Cache behavior was partitioned. Visited link styles were constrained. Cross-origin resource probing became harder. Spectre forced browsers to rethink process isolation and high-resolution measurement.CSS remains stubborn because it is both declarative and powerful. It lets documents react to state. It lets layout engines make decisions. It lets pages conditionally load resources, adapt to media, transform content, and produce observable differences. Every one of those features is useful; every one can become part of an inference attack if paired with the right primitive.
CVE-2026-14085’s public description is sparse, and Google commonly restricts bug details until most users have received a fix. That restraint is sensible, but it leaves defenders with a familiar gap: enough information to patch, not enough to fully model exploit mechanics. In browser security, that is usually the correct tradeoff.
The bigger lesson is that information disclosure is no longer a second-class category. In a world of bearer tokens, session cookies, account state, private URLs, and personalized cloud data, small leaks can be chained into useful intelligence. The impact depends less on the label and more on what the victim’s browser can see.
Google’s Restricted Details Policy Still Makes Sense
Google’s release note repeats its standard warning that access to bug details and links may remain restricted until a majority of users are updated. Security researchers and defenders often bristle at that opacity, especially when they are asked to prioritize fixes without proof-of-concept detail. But browser vendors have a strong case here.A Chrome bug report can be a recipe. If the issue is in CSS and the description already says cross-origin data can leak through a crafted HTML page, additional implementation detail may let copycat attackers build working probes before the update reaches slow-moving systems. In consumer software, patch availability and patch deployment are not the same event.
The downside is that defenders must operate from metadata. They see the component, the version boundary, the severity, the CVSS vector, the disclosure date, and the advisory language. That is enough to act, but not enough to answer every executive or compliance question with satisfying precision.
This is where security programs need maturity rather than drama. If the browser is below the fixed version, update it. If it cannot be updated, isolate or restrict it. If the asset is high-risk because it belongs to administrators or handles sensitive web apps, prioritize it above ordinary endpoints. Do not wait for exploit code to make a browser privacy bug “real.”
Edge, Chrome, and the Chromium Dependency Chain
For WindowsForum readers, the Chrome-only framing is never quite enough. Microsoft Edge is built on Chromium, and Microsoft’s release process trails, merges, and repackages upstream Chromium fixes into Edge’s own versioning scheme. That makes the security story more complicated than “Chrome fixed it, therefore Windows users are done.”Microsoft’s July 2 Edge Stable release, version 150.0.4078.48, says it incorporated the latest Chromium security updates. That is the line Windows administrators should care about. If Edge is part of the standard desktop image — and in most Windows 10 and Windows 11 environments it is — then Edge’s update state needs the same attention as Chrome’s.
There is also an application-platform angle. Edge WebView2 is now a common way for Windows applications to embed web content. WebView2 generally benefits from Evergreen runtime updates, but organizations that use fixed-version runtimes or tightly controlled app packaging should verify their assumptions. Chromium security fixes do not protect a frozen runtime that never receives them.
The broader Chromium ecosystem has always been a strength and a risk. Shared engine work means security fixes can propagate widely. Shared code also means a bug in one layer can matter to many products, each with its own cadence, telemetry, release channel, and advisory language. CVE-2026-14085 is a reminder that “Chromium-based” is not a patch status.
The Real Risk Is Complacency, Not Catastrophe
There is no public indication in the supplied NVD entry that CVE-2026-14085 is being exploited in the wild. CISA’s SSVC enrichment lists exploitation as “none,” automatable as “no,” and technical impact as “partial.” Those are calming signals, and they should be read as such.But calming is not the same as dismissive. A user-assisted crafted-page attack is still the web’s native threat model. Phishing, malvertising, compromised legitimate sites, poisoned search results, and targeted links all exist to make victims load attacker-controlled content. “User interaction required” is a lower barrier than it sounds when the required interaction is browsing.
The confidentiality impact is the reason this deserves attention. A bug that leaks cross-origin data may not give the attacker a shell, but it can erode the boundaries that make web SSO tolerable. In a corporate environment, authenticated browser state is often more valuable than local files.
That is why patching should be measured by exposure, not by adjectives. A low-severity browser bug on a kiosk with no sensitive sessions is one thing. The same class of bug on an administrator workstation logged into cloud consoles and internal dashboards is another.
The Patch Is Small; the Browser Trust Boundary Is Not
The concrete response to CVE-2026-14085 is straightforward, but the lesson is broader than one CSS bug. Treat this as another proof point that browser security is a continuous control, not a monthly chore.- Chrome users should be on 150.0.7871.47 or later on Windows and Mac, while Linux users should confirm they have received the corresponding Chrome 150 stable update available for their platform.
- Windows administrators should verify Microsoft Edge Stable 150.0.4078.48 or a later build where Edge is deployed, because Microsoft says that release incorporated the latest Chromium security updates.
- Asset inventories should not rely solely on the Google Chrome CPE in the NVD entry, because Chromium-based downstream products may require separate vendor advisories and version checks.
- Security teams should treat the Low Chromium rating and Medium CISA score as complementary signals, not as a dispute that needs to be resolved before patching.
- Environments that freeze Chromium runtimes, package custom browsers, or use fixed WebView2 runtimes should receive extra scrutiny because evergreen assumptions may not apply.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:11-07:00
NVD - CVE-2026-14085
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:11-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-14085 - Google Chrome Side-Channel Information Leak
Side-channel information leakage in CSS in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)cvefeed.io - Related coverage: chromereleases.googleblog.com
Chrome Releases: Stable Channel Update for Desktop
The Stable channel has been updated to 149.0.7827.155/.156 for Windows and Mac and 149.0.7827.155 for Linux, which will roll out over the c...chromereleases.googleblog.com
- Related coverage: hivepro.com