Google Chrome before version 150.0.7871.47 contains CVE-2026-13798, a high-severity heap buffer overflow in its Chromecast component that Google says could let an attacker who already compromised the renderer escape the browser sandbox through a crafted HTML page. That wording is dry, but the security story is not: this is the kind of Chrome flaw that matters less because of its brand-name component and more because it sits on the boundary between “a bad tab” and “a bad machine.” The National Vulnerability Database entry, published June 30, 2026 and modified July 2, has not yet received a full NIST CVSS assessment, while CISA’s ADP enrichment assigns it a 9.6 critical score. The practical answer for Windows users and administrators is simple: if Chrome is below 150.0.7871.47, treat it as exposed and update.
The first trap in reading CVE-2026-13798 is the word “Chromecast.” Many desktop users will see that and mentally downgrade the issue, assuming it concerns a dongle, a living-room device, or a feature they never use. That would be a mistake.
In Chrome’s security model, components matter because they create attack surfaces, not because users consciously launch them. A flaw in a casting-related path can still be reachable from browser content if the right preconditions are present. Google’s CVE language says the attacker must first have compromised the renderer process, which means this is not described as a one-click direct operating-system takeover from a clean browser state.
But that caveat cuts both ways. Modern browser exploitation is often chained. One bug gets code running inside the renderer, another bug breaks out of the sandbox, and a third step may establish persistence or steal data depending on the target environment. CVE-2026-13798 is explicitly described as a possible sandbox escape, and that is why it deserves more attention than a routine component bug.
The NVD entry repeats Google’s description and classifies the weakness as CWE-122, a heap-based buffer overflow. That is an old class of vulnerability with a modern browser twist: memory corruption in a hardened, multi-process application is rarely useful in isolation, but it becomes dangerous when paired with the right primitive and the right execution context.
The timing matters because vulnerability databases often trail vendor advisories. In this case, the CVE was received from Chrome on June 30, NIST added initial analysis on July 1, and CISA-ADP modified enrichment on July 1 and July 2. That is not unusual; the public vulnerability pipeline is not a single source of instant truth, but a set of overlapping systems that fill in details over time.
The result is an entry that looks slightly unfinished. NIST’s own CVSS fields are still marked as not assessed, while CISA-ADP supplies a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H and a 9.6 score. That vector says a network-delivered attack with low complexity and no privileges is possible, but user interaction is required and the scope changes because the sandbox boundary is crossed.
That distinction is important for forum readers who live in patch dashboards. “NVD N/A” does not mean “not serious.” It means NIST has not yet published its own scoring. CISA’s enrichment and Google’s own severity label already put the issue firmly in the patch-now category.
The safer reading is to follow the CVE description and Google’s fixed-version threshold: Chrome 150.0.7871.47 or later should be considered remediated for this CVE. If an enterprise scanner flags only versions below .46, it may miss machines on .46 that still fall under the “prior to .47” wording. If it flags all versions below .47, it aligns with the CVE’s plain-language remediation boundary.
This is not merely pedantry. In Windows fleets, Chrome versions can differ by channel, architecture, update policy, user privilege model, and whether Chrome is installed per-user or system-wide. A one-build discrepancy can turn into thousands of endpoints marked compliant or non-compliant.
Administrators should also remember that Chrome-based browsers are not automatically covered by Chrome’s own version number. Microsoft Edge, Brave, Vivaldi, Opera, and Electron-based applications consume Chromium code on their own schedules. CVE-2026-13798 is recorded against Google Chrome, but the underlying Chromium bug may have implications beyond Google’s browser depending on whether downstream projects include the affected Chromecast code and when they merged the fix.
In practical terms, the important CPE is Google Chrome. The operating-system CPEs in NVD configurations often describe platforms on which an application runs, not separate vulnerable products in the way an administrator might intuitively read them. A Windows CPE appearing in an AND configuration does not mean Windows itself contains the Chrome Chromecast bug; it means the vulnerable application configuration is scoped to Chrome running on a platform.
The political answer is that CPEs remain one of the weakest links in vulnerability management. They are necessary for automation, but they do not map cleanly to how modern software is packaged, embedded, forked, or updated. A single Chromium flaw may touch Google Chrome, Chromium builds, Linux distribution packages, mobile variants, embedded browsers, and third-party applications — but the CVE record may initially name only the product that issued the advisory.
That is why security teams should treat CPEs as starting points, not gospel. For CVE-2026-13798, the operational question is not whether NVD’s CPE list is philosophically complete. It is whether every browser in the estate that uses affected Chromium code has received a fixed build.
A renderer compromise might come from a separate JavaScript engine bug, a DOM issue, a media parser flaw, or another memory-corruption vulnerability. Once that compromise exists, the sandbox is supposed to contain it. A sandbox escape turns containment into merely an obstacle.
This is why CISA’s vector showing changed scope is meaningful. Scope changes in CVSS indicate that exploitation crosses a security authority boundary. In browser language, that is the jump from “the attacker owns a process designed to be disposable” to “the attacker may reach capabilities the browser deliberately withheld.”
The current public record does not say CVE-2026-13798 is being exploited in the wild. CISA’s SSVC enrichment lists exploitation as “none,” and that should be stated clearly. But absence of observed exploitation is not a reason to delay a Chrome security update, especially when the bug class and impact profile fit an exploit-chain role.
Chrome has layers of defenses against this. Site isolation, sandboxing, memory allocators, control-flow protections, compiler hardening, and process separation all exist to make memory corruption harder to exploit. The existence of those mitigations is why many memory bugs receive nuanced descriptions rather than instant catastrophe labels.
But the mitigations are also why a bug described as a sandbox escape draws attention. If an attacker can move from a compromised renderer through a vulnerable component into a more privileged context, they are attacking the browser’s central promise. The user may see only a web page; the attacker sees a chain of trust boundaries.
The Chromecast component makes the story more interesting because casting features have to broker communication between browser content, local network discovery, media control, and device integration. Those are rich seams for bugs because they connect web-facing logic to platform-facing capability. Even if this particular issue requires a renderer foothold, the component’s position in the architecture explains why a memory safety flaw there is not trivial.
The patch process should therefore look more like infrastructure hygiene than help-desk advice. Managed Chrome environments should verify update policies, force relaunch where appropriate, and audit stale sessions. Chrome can download updates in the background, but a browser that has not restarted may still be running vulnerable code.
Windows shops have an additional wrinkle: users often run multiple Chromium-based browsers. Microsoft Edge may be patched through Edge’s own update mechanism, Chrome through Google Update, and portable or user-installed browsers through neither. Vulnerability scanners that look only for system-wide Chrome installations can miss per-user installs under profile directories.
The same logic applies to virtual desktops, golden images, kiosk systems, lab machines, and jump boxes. A dormant browser image can become a vulnerable browser the moment it is cloned or powered on. For a sandbox-escape-class issue, the right question is not “Did we approve the update?” but “Can we prove the vulnerable binary is gone?”
This practice frustrates researchers and defenders who want exploitability details immediately. It also prevents attackers from receiving a free exploit roadmap while lagging users remain exposed. The trade-off is imperfect, but in browser security it is hard to avoid.
For administrators, the lack of public proof-of-concept code should not change priority. The public description already supplies enough: remote attacker, crafted HTML page, renderer compromise precondition, sandbox escape potential, heap buffer overflow, Chrome before 150.0.7871.47. That is sufficient to justify fast rollout.
For enthusiasts, it is worth resisting the urge to overread the silence. We do not know from the public record whether the bug is easy to weaponize, whether it was found internally or externally, whether exploit primitives are reliable, or whether downstream Chromium projects share exposure. We know enough to patch; we do not know enough to dramatize.
Google’s severity reflects Chromium’s internal rubric, exploit assumptions, component architecture, and bug-chain context. CVSS tries to model technical impact in a standardized way across vendors. A sandbox escape can score extremely high because it changes scope and threatens confidentiality, integrity, and availability, even if exploitation requires a prior renderer compromise and user interaction.
This is why defenders should avoid treating severity labels as a single universal scale. A Chrome “High” can be more urgent than a “Critical” in a product with no exposed attack surface, depending on deployment, exploit maturity, and asset value. In this case, both labels point in the same operational direction: update promptly.
The real nuance is prioritization among many Chrome fixes. The June 30 stable update appears to have addressed a large batch of vulnerabilities, not just CVE-2026-13798. Security teams should not cherry-pick this one CVE and declare victory; they should deploy the entire stable update and then verify the resulting version.
That restart gap is where Chrome patching often fails. A browser can report that an update is available or staged, while the running process remains old. For a vulnerability tied to crafted web content, that gap is not academic; the browser is exposed precisely while users continue browsing.
Managed Chrome policies can help by setting relaunch notification periods and enforcing restarts after updates. But those policies are only useful if admins actually measure compliance. The endpoint inventory should capture running Chrome versions, not merely installed package versions.
There is also a communications angle. Users understand “restart to finish updating” better than they understand CVSS. A short, firm message that Chrome must be relaunched to complete a security update is more effective than a long advisory pasted from a vulnerability database.
Microsoft Edge users should watch Microsoft’s own release notes rather than assuming Chrome’s version number applies. Edge has its own build numbers, update channel, and patch cadence. The same is true for other Chromium derivatives, which may ship the relevant fix under their own versioning schemes.
Electron deserves special mention because it hides Chromium inside desktop applications. Teams, Slack-like tools, password managers, code editors, admin consoles, and niche line-of-business apps may bundle browser engines that users never think to update. Whether CVE-2026-13798 affects a given Electron app depends on its Chromium base and included features, but the broader lesson is recurring: browser bugs do not always live only in browsers.
This is where asset management must evolve. A software inventory that can identify “Google Chrome” is useful. One that can identify embedded Chromium runtimes across the estate is better. The organizations that can answer that question quickly are the ones least likely to be surprised by the next browser-chain advisory.
The CPE uncertainty should not paralyze anyone. If scanners disagree, use the vendor-fixed version as the enforcement point. If NVD’s platform configuration looks odd, remember that the vulnerable product is Chrome, not Windows itself. If a dashboard says “NVD score unavailable,” remember that CISA’s enrichment and Google’s own advisory already supply enough risk signal.
The most dangerous response would be to file this under “Chromecast” and move on. The component name is incidental. The security boundary is the story.
The Chromecast Label Is a Distraction From the Sandbox Story
The first trap in reading CVE-2026-13798 is the word “Chromecast.” Many desktop users will see that and mentally downgrade the issue, assuming it concerns a dongle, a living-room device, or a feature they never use. That would be a mistake.In Chrome’s security model, components matter because they create attack surfaces, not because users consciously launch them. A flaw in a casting-related path can still be reachable from browser content if the right preconditions are present. Google’s CVE language says the attacker must first have compromised the renderer process, which means this is not described as a one-click direct operating-system takeover from a clean browser state.
But that caveat cuts both ways. Modern browser exploitation is often chained. One bug gets code running inside the renderer, another bug breaks out of the sandbox, and a third step may establish persistence or steal data depending on the target environment. CVE-2026-13798 is explicitly described as a possible sandbox escape, and that is why it deserves more attention than a routine component bug.
The NVD entry repeats Google’s description and classifies the weakness as CWE-122, a heap-based buffer overflow. That is an old class of vulnerability with a modern browser twist: memory corruption in a hardened, multi-process application is rarely useful in isolation, but it becomes dangerous when paired with the right primitive and the right execution context.
Google Patched First, the Databases Are Still Catching Up
According to Google’s Chrome Releases blog, the Stable Channel update for desktop was issued on June 30, 2026, with Windows and macOS moving to the 150.0.7871.46/.47 line and Linux to 150.0.7871.46. The CVE record states that Chrome prior to 150.0.7871.47 is affected, which is the version threshold administrators should use when writing detection logic or compliance queries.The timing matters because vulnerability databases often trail vendor advisories. In this case, the CVE was received from Chrome on June 30, NIST added initial analysis on July 1, and CISA-ADP modified enrichment on July 1 and July 2. That is not unusual; the public vulnerability pipeline is not a single source of instant truth, but a set of overlapping systems that fill in details over time.
The result is an entry that looks slightly unfinished. NIST’s own CVSS fields are still marked as not assessed, while CISA-ADP supplies a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H and a 9.6 score. That vector says a network-delivered attack with low complexity and no privileges is possible, but user interaction is required and the scope changes because the sandbox boundary is crossed.
That distinction is important for forum readers who live in patch dashboards. “NVD N/A” does not mean “not serious.” It means NIST has not yet published its own scoring. CISA’s enrichment and Google’s own severity label already put the issue firmly in the patch-now category.
The Version Boundary Is Messier Than the Risk Boundary
There is an oddity in the record worth calling out: the NIST change history visible in the supplied NVD text says a CPE configuration was added for Google Chrome versions up to, but excluding, 150.0.7871.46, while the CVE description and affected-version language point to “prior to 150.0.7871.47.” That sort of mismatch is exactly the kind of thing that makes asset inventory teams distrust vulnerability feeds.The safer reading is to follow the CVE description and Google’s fixed-version threshold: Chrome 150.0.7871.47 or later should be considered remediated for this CVE. If an enterprise scanner flags only versions below .46, it may miss machines on .46 that still fall under the “prior to .47” wording. If it flags all versions below .47, it aligns with the CVE’s plain-language remediation boundary.
This is not merely pedantry. In Windows fleets, Chrome versions can differ by channel, architecture, update policy, user privilege model, and whether Chrome is installed per-user or system-wide. A one-build discrepancy can turn into thousands of endpoints marked compliant or non-compliant.
Administrators should also remember that Chrome-based browsers are not automatically covered by Chrome’s own version number. Microsoft Edge, Brave, Vivaldi, Opera, and Electron-based applications consume Chromium code on their own schedules. CVE-2026-13798 is recorded against Google Chrome, but the underlying Chromium bug may have implications beyond Google’s browser depending on whether downstream projects include the affected Chromecast code and when they merged the fix.
The Missing CPE Question Has a Real Answer and a Political One
The user-facing NVD prompt asks, “Are we missing a CPE here?” In narrow terms, yes, the CPE picture appears incomplete or at least unsettled. The NVD text shown in the change history includes Chrome plus operating-system platform CPEs for Windows, Linux kernel, and macOS, but the visible “Known Affected Software Configurations” area is still loading or not fully represented in the supplied view.In practical terms, the important CPE is Google Chrome. The operating-system CPEs in NVD configurations often describe platforms on which an application runs, not separate vulnerable products in the way an administrator might intuitively read them. A Windows CPE appearing in an AND configuration does not mean Windows itself contains the Chrome Chromecast bug; it means the vulnerable application configuration is scoped to Chrome running on a platform.
The political answer is that CPEs remain one of the weakest links in vulnerability management. They are necessary for automation, but they do not map cleanly to how modern software is packaged, embedded, forked, or updated. A single Chromium flaw may touch Google Chrome, Chromium builds, Linux distribution packages, mobile variants, embedded browsers, and third-party applications — but the CVE record may initially name only the product that issued the advisory.
That is why security teams should treat CPEs as starting points, not gospel. For CVE-2026-13798, the operational question is not whether NVD’s CPE list is philosophically complete. It is whether every browser in the estate that uses affected Chromium code has received a fixed build.
Renderer Compromise Is a Precondition, Not a Comfort Blanket
Google’s wording says the attacker must have compromised the renderer process. That sounds reassuring until you remember that the renderer is exactly where hostile web content tries to land. The sandbox exists because browsers assume renderers are exposed to untrusted code every day.A renderer compromise might come from a separate JavaScript engine bug, a DOM issue, a media parser flaw, or another memory-corruption vulnerability. Once that compromise exists, the sandbox is supposed to contain it. A sandbox escape turns containment into merely an obstacle.
This is why CISA’s vector showing changed scope is meaningful. Scope changes in CVSS indicate that exploitation crosses a security authority boundary. In browser language, that is the jump from “the attacker owns a process designed to be disposable” to “the attacker may reach capabilities the browser deliberately withheld.”
The current public record does not say CVE-2026-13798 is being exploited in the wild. CISA’s SSVC enrichment lists exploitation as “none,” and that should be stated clearly. But absence of observed exploitation is not a reason to delay a Chrome security update, especially when the bug class and impact profile fit an exploit-chain role.
Heap Overflows Still Earn Their Reputation
Heap buffer overflows are not fashionable in the way speculative-execution attacks or AI supply-chain bugs are fashionable, but they remain a workhorse of serious exploitation. They occur when software writes beyond the bounds of memory allocated on the heap, potentially corrupting adjacent data structures. In a browser, those structures may include objects that influence control flow, type interpretation, permissions, or inter-process communication.Chrome has layers of defenses against this. Site isolation, sandboxing, memory allocators, control-flow protections, compiler hardening, and process separation all exist to make memory corruption harder to exploit. The existence of those mitigations is why many memory bugs receive nuanced descriptions rather than instant catastrophe labels.
But the mitigations are also why a bug described as a sandbox escape draws attention. If an attacker can move from a compromised renderer through a vulnerable component into a more privileged context, they are attacking the browser’s central promise. The user may see only a web page; the attacker sees a chain of trust boundaries.
The Chromecast component makes the story more interesting because casting features have to broker communication between browser content, local network discovery, media control, and device integration. Those are rich seams for bugs because they connect web-facing logic to platform-facing capability. Even if this particular issue requires a renderer foothold, the component’s position in the architecture explains why a memory safety flaw there is not trivial.
Windows Admins Should Treat Chrome as Infrastructure
For many organizations, Chrome is not “just an app.” It is a front door to SaaS, identity, internal dashboards, cloud consoles, HR systems, privileged admin portals, and password managers. A sandbox escape in that context is not simply a consumer-browser concern; it is an enterprise control-plane concern.The patch process should therefore look more like infrastructure hygiene than help-desk advice. Managed Chrome environments should verify update policies, force relaunch where appropriate, and audit stale sessions. Chrome can download updates in the background, but a browser that has not restarted may still be running vulnerable code.
Windows shops have an additional wrinkle: users often run multiple Chromium-based browsers. Microsoft Edge may be patched through Edge’s own update mechanism, Chrome through Google Update, and portable or user-installed browsers through neither. Vulnerability scanners that look only for system-wide Chrome installations can miss per-user installs under profile directories.
The same logic applies to virtual desktops, golden images, kiosk systems, lab machines, and jump boxes. A dormant browser image can become a vulnerable browser the moment it is cloned or powered on. For a sandbox-escape-class issue, the right question is not “Did we approve the update?” but “Can we prove the vulnerable binary is gone?”
The Public Bug Link Will Stay Thin Until It No Longer Matters
The Chromium issue tracker reference for CVE-2026-13798 is marked in the NVD record, but access to full bug details is commonly restricted after security releases. That is normal for Chrome. Google routinely limits access to technical bug details until a majority of users have received the fix, and sometimes longer if the bug affects shared third-party code.This practice frustrates researchers and defenders who want exploitability details immediately. It also prevents attackers from receiving a free exploit roadmap while lagging users remain exposed. The trade-off is imperfect, but in browser security it is hard to avoid.
For administrators, the lack of public proof-of-concept code should not change priority. The public description already supplies enough: remote attacker, crafted HTML page, renderer compromise precondition, sandbox escape potential, heap buffer overflow, Chrome before 150.0.7871.47. That is sufficient to justify fast rollout.
For enthusiasts, it is worth resisting the urge to overread the silence. We do not know from the public record whether the bug is easy to weaponize, whether it was found internally or externally, whether exploit primitives are reliable, or whether downstream Chromium projects share exposure. We know enough to patch; we do not know enough to dramatize.
The CISA Score Says “Critical,” Google Says “High,” and Both Can Be Right
One apparent inconsistency is that Chromium labels the issue “High,” while CISA-ADP gives it a 9.6 critical CVSS score. That is not necessarily a contradiction. Vendor severity and CVSS scoring answer different questions.Google’s severity reflects Chromium’s internal rubric, exploit assumptions, component architecture, and bug-chain context. CVSS tries to model technical impact in a standardized way across vendors. A sandbox escape can score extremely high because it changes scope and threatens confidentiality, integrity, and availability, even if exploitation requires a prior renderer compromise and user interaction.
This is why defenders should avoid treating severity labels as a single universal scale. A Chrome “High” can be more urgent than a “Critical” in a product with no exposed attack surface, depending on deployment, exploit maturity, and asset value. In this case, both labels point in the same operational direction: update promptly.
The real nuance is prioritization among many Chrome fixes. The June 30 stable update appears to have addressed a large batch of vulnerabilities, not just CVE-2026-13798. Security teams should not cherry-pick this one CVE and declare victory; they should deploy the entire stable update and then verify the resulting version.
The Enterprise Risk Is the Restart Gap
Chrome’s updater is good enough that many home users will receive the fix without knowing the CVE exists. The enterprise problem is different. Large fleets accumulate machines that have downloaded but not applied updates, browsers that stay open for weeks, and users who ignore relaunch prompts because every tab is “important.”That restart gap is where Chrome patching often fails. A browser can report that an update is available or staged, while the running process remains old. For a vulnerability tied to crafted web content, that gap is not academic; the browser is exposed precisely while users continue browsing.
Managed Chrome policies can help by setting relaunch notification periods and enforcing restarts after updates. But those policies are only useful if admins actually measure compliance. The endpoint inventory should capture running Chrome versions, not merely installed package versions.
There is also a communications angle. Users understand “restart to finish updating” better than they understand CVSS. A short, firm message that Chrome must be relaunched to complete a security update is more effective than a long advisory pasted from a vulnerability database.
Browser Monoculture Makes Every Chromium Patch a Supply-Chain Event
CVE-2026-13798 is recorded as a Chrome vulnerability, but Chromium’s dominance means every serious Chrome security fix has a shadow life. Edge, Brave, Vivaldi, Opera, Electron applications, embedded webviews, and Linux distribution Chromium builds all depend on portions of the same upstream ecosystem. Not every downstream product is necessarily vulnerable to every upstream bug, but the dependency graph is too broad to ignore.Microsoft Edge users should watch Microsoft’s own release notes rather than assuming Chrome’s version number applies. Edge has its own build numbers, update channel, and patch cadence. The same is true for other Chromium derivatives, which may ship the relevant fix under their own versioning schemes.
Electron deserves special mention because it hides Chromium inside desktop applications. Teams, Slack-like tools, password managers, code editors, admin consoles, and niche line-of-business apps may bundle browser engines that users never think to update. Whether CVE-2026-13798 affects a given Electron app depends on its Chromium base and included features, but the broader lesson is recurring: browser bugs do not always live only in browsers.
This is where asset management must evolve. A software inventory that can identify “Google Chrome” is useful. One that can identify embedded Chromium runtimes across the estate is better. The organizations that can answer that question quickly are the ones least likely to be surprised by the next browser-chain advisory.
The Patch Is Small; the Lesson Is Not
The narrow remediation is easy: update Chrome to 150.0.7871.47 or later and restart the browser. The broader lesson is that browser security is now a continuous operational discipline, not an occasional desktop-maintenance task. A sandbox escape in a widely deployed browser deserves the same urgency as a serious flaw in a VPN client or remote-management agent.The CPE uncertainty should not paralyze anyone. If scanners disagree, use the vendor-fixed version as the enforcement point. If NVD’s platform configuration looks odd, remember that the vulnerable product is Chrome, not Windows itself. If a dashboard says “NVD score unavailable,” remember that CISA’s enrichment and Google’s own advisory already supply enough risk signal.
The most dangerous response would be to file this under “Chromecast” and move on. The component name is incidental. The security boundary is the story.
The July 2026 Chrome Fix Belongs on the Short List
This is one of those browser advisories where the action items are more valuable than the drama. The public record is still sparse, but the operational path is clear.- Chrome installations should be updated to 150.0.7871.47 or later, with a browser restart required to ensure the patched code is actually running.
- Vulnerability teams should treat “prior to 150.0.7871.47” as the safer detection threshold if feeds disagree about the .46 and .47 boundary.
- CISA’s 9.6 CVSS score should be read alongside Google’s “High” severity label, not as a contradiction of it.
- The current public record does not show known exploitation in the wild, but the bug’s sandbox-escape role makes delayed patching hard to justify.
- Administrators should check Chromium-based browsers and embedded runtimes separately rather than assuming Google Chrome coverage equals Chromium coverage.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:59-07:00
NVD - CVE-2026-13798
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:59-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-13798 - Google Chrome Chromecast Heap Buffer Overflow Sandbox Escape
Heap buffer overflow in Chromecast in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)cvefeed.io - Related coverage: vulnerability.circl.lu
Vulnerability-Lookup
Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.vulnerability.circl.lu