Google fixed CVE-2026-13796 in Chrome 150.0.7871.47 for Windows and macOS on June 30, 2026, addressing a high-severity Chromecast integer overflow that could let an attacker escape Chrome’s sandbox after first compromising the renderer. The vulnerability is not a garden-variety “visit a bad page and lose the machine” bug, but it sits in the uncomfortable second stage of the modern browser exploit chain. NVD’s entry, Chrome’s own release notes, and CISA’s enrichment all point to the same lesson: the browser sandbox is still the prize, and the metadata around browser bugs is now part of the operational risk.
The practical answer for administrators is simple: Chrome below 150.0.7871.47 should not remain in production on Windows or macOS, and Chromium-based fleets should be checked against their vendors’ lag time. The more interesting answer is that CVE-2026-13796 exposes how much modern patch triage depends on imperfect public data — especially when NVD, Chrome, and CISA describe the same bug through different lenses.
CVE-2026-13796 is described by NVD as an integer overflow in Chromecast in Google Chrome prior to 150.0.7871.47. The attack path requires a remote attacker who has already compromised the renderer process, then uses a crafted HTML page to potentially perform a sandbox escape. Google classified the Chromium security severity as High, while CISA’s ADP enrichment assigned a CVSS 3.1 score of 9.6, which lands in Critical territory.
That difference is not just bureaucratic noise. Chrome’s severity labels are usually shaped by project-specific exploitability assumptions and internal security architecture; CVSS attempts to describe impact in a more generalized way. A bug that requires renderer compromise may sound conditional, but in browser exploitation, renderer compromise is often the first rung of the ladder rather than the end state.
The renderer is where untrusted web content is supposed to be contained. If an attacker can pair a renderer exploit with a sandbox escape, the browser’s most important boundary starts to collapse. That is why a vulnerability can be “High” in Chromium’s release notes and still deserve urgent attention from enterprise defenders.
The Chromecast component makes the issue easy to misread. Many Windows users will see “Chromecast” and think of a living-room dongle, not a desktop browser attack surface. In Chromium, however, casting support is part of a much broader browser feature set, and bugs in those subsystems can matter even when the user is not actively throwing a tab to a television.
That is the first trap for administrators. Massive browser security releases create the illusion that individual bugs matter less because they arrive in bulk. In reality, bulk patch drops make prioritization harder because the most consequential bugs may be mixed with dozens or hundreds of lower-signal entries.
CVE-2026-13796 was one of several Chromecast-related high-severity issues listed in the same Chrome 150 release. Google’s notes also referenced Chromecast bugs involving insufficient validation, heap buffer overflow, integer overflow, and use-after-free conditions. That cluster matters because repeated findings in the same area can suggest concentrated code churn, focused internal review, or a component that has become newly interesting to researchers and attackers.
Google reported CVE-2026-13796 internally on March 11, according to the Chrome release entry. The public CVE landed at the end of June. That lag is normal for coordinated browser security work, but it also means defenders see the most actionable version of the risk only after the fix is already shipping.
On the evidence available, yes, the CPE metadata appears at least potentially inconsistent with the CVE description and Chrome’s Windows/Mac fixed version. The CVE description says “prior to 150.0.7871.47.” The Chrome release says Windows and Mac received 150.0.7871.46/.47. NVD’s change history, however, shows a vulnerable CPE range excluding 150.0.7871.46, which could cause automated tools to treat 150.0.7871.46 as fixed even where the relevant fixed build is 150.0.7871.47.
That does not automatically mean every scanner will get the answer wrong. Some products supplement NVD CPEs with vendor advisories, browser version detection, package metadata, or their own curated vulnerability intelligence. But any environment relying heavily on raw NVD CPE matching should treat this entry as one that needs manual review.
The safest operational line is to use Google’s advisory and the CVE description as the governing facts: for Windows and macOS, move to 150.0.7871.47 or later. If a tool reports 150.0.7871.46 as clean for CVE-2026-13796 without explaining platform nuance, that finding deserves skepticism rather than blind acceptance.
The “user interaction required” part is the browser reality: someone has to land on or interact with malicious content. The “changed scope” and high impact fields are the warning flare. A sandbox escape is dangerous precisely because it crosses a trust boundary that is supposed to limit the damage from web content.
CISA’s SSVC enrichment listed exploitation as none, automatable as no, and technical impact as total. That is a useful split. There is no public indication from the data provided that CVE-2026-13796 is being exploited in the wild, but the consequence of successful exploitation is severe enough to justify fast patching.
This is where patch teams often get stuck between two bad instincts. One instinct says no known exploitation means the issue can wait. The other says a critical score means emergency everything. The saner reading is narrower: this is not evidence of an active fire, but it is exactly the kind of bug that should not survive the next maintenance window.
CVE-2026-13796 requires prior renderer compromise, which makes it a chain component. That can sound reassuring until one remembers how exploit chains are built. Attackers do not need every step to be packaged under the same CVE, and they do not need the sandbox escape to be the first bug a user encounters.
A crafted HTML page that can participate in such a chain is still a web-scale risk. It can be delivered through phishing, malvertising, compromised websites, or watering-hole attacks. The user does not need to install software, approve an extension, or authenticate to a service for the browser to become the first point of contact.
For enterprises, the relevant exposure is not limited to Chrome as a standalone consumer app. Chrome is often the front door to SaaS identity, admin consoles, device management portals, source repositories, and remote access tools. A sandbox escape in that context is not just a workstation problem; it can become an identity and lateral-movement problem.
For managed Windows fleets, Chrome itself is usually the easy part. Google Update, enterprise policies, and browser version reporting make it relatively straightforward to push and verify current builds. The harder work is finding the Chromium copies nobody thinks about: app runtimes, bundled browsers in conferencing tools, kiosk shells, thin-client packages, and line-of-business software that quietly embeds a web engine.
CVE-2026-13796 is a Chrome CVE, not a universal statement about every Chromium-derived product. But once a fix lands in Chromium, downstream consumers need to answer whether they include the affected component and whether they have pulled the corrected code. Administrators should not assume absence from a vendor advisory equals absence of risk.
This is also why CPE precision matters. If vulnerability management tooling maps only “Google Chrome” cleanly but misses Chromium derivatives, an organization can patch the obvious browser while leaving the same class of browser-engine exposure elsewhere. The CPE question is not bookkeeping; it is asset discovery by another name.
Security teams sometimes treat CVE metadata as if it were a compiled binary: precise, finished, and authoritative. It is often closer to a living news file. Descriptions, CPEs, CWE mappings, CVSS vectors, references, and affected-version ranges can change as agencies enrich, normalize, or correct entries.
That matters because automated workflows frequently convert those fields directly into action. A CVSS score opens a ticket. A CPE match assigns an asset. A CWE label feeds a dashboard. A version range determines whether a patch is marked complete.
For CVE-2026-13796, the most defensible workflow is to privilege the vendor advisory for fixed versions, use CISA’s score as a severity signal, and treat NVD CPE data as useful but not final. That sounds obvious until a dashboard says otherwise.
For administrators, the task is less about clicking update and more about proving closure. Version reporting should distinguish Windows, macOS, and Linux builds rather than flattening them into a single “Chrome 150” bucket. That distinction matters because this CVE’s public text points to 150.0.7871.47 as the relevant fixed threshold.
Enterprises should also check whether browser restart policies are actually completing the update. Chrome can download an update and still leave users running the old vulnerable process until restart. In security terms, “pending relaunch” is not patched; it is a promissory note.
The final verification step is scanner sanity. If a vulnerability tool marks Chrome 150.0.7871.46 on Windows or macOS as fixed for CVE-2026-13796 solely because of the NVD CPE range, security teams should validate that logic against Google’s release text. Conversely, if a tool flags Linux 150.0.7871.46 without platform context, it may be applying the Windows/Mac threshold too broadly.
The practical answer for administrators is simple: Chrome below 150.0.7871.47 should not remain in production on Windows or macOS, and Chromium-based fleets should be checked against their vendors’ lag time. The more interesting answer is that CVE-2026-13796 exposes how much modern patch triage depends on imperfect public data — especially when NVD, Chrome, and CISA describe the same bug through different lenses.
Chrome’s Chromecast Bug Is Really a Sandbox Story
CVE-2026-13796 is described by NVD as an integer overflow in Chromecast in Google Chrome prior to 150.0.7871.47. The attack path requires a remote attacker who has already compromised the renderer process, then uses a crafted HTML page to potentially perform a sandbox escape. Google classified the Chromium security severity as High, while CISA’s ADP enrichment assigned a CVSS 3.1 score of 9.6, which lands in Critical territory.That difference is not just bureaucratic noise. Chrome’s severity labels are usually shaped by project-specific exploitability assumptions and internal security architecture; CVSS attempts to describe impact in a more generalized way. A bug that requires renderer compromise may sound conditional, but in browser exploitation, renderer compromise is often the first rung of the ladder rather than the end state.
The renderer is where untrusted web content is supposed to be contained. If an attacker can pair a renderer exploit with a sandbox escape, the browser’s most important boundary starts to collapse. That is why a vulnerability can be “High” in Chromium’s release notes and still deserve urgent attention from enterprise defenders.
The Chromecast component makes the issue easy to misread. Many Windows users will see “Chromecast” and think of a living-room dongle, not a desktop browser attack surface. In Chromium, however, casting support is part of a much broader browser feature set, and bugs in those subsystems can matter even when the user is not actively throwing a tab to a television.
The June 30 Chrome 150 Release Was a Patch Train, Not a Footnote
Google’s Chrome Releases blog announced Chrome 150’s stable-channel promotion on Tuesday, June 30, 2026, for Windows, macOS, and Linux. The release shipped Chrome 150.0.7871.46 for Linux and 150.0.7871.46/.47 for Windows and Mac, with rollout expected over the following days and weeks. Google also said the update contained 433 security fixes, a number large enough to bury any single CVE in the scrolling machinery of a release post.That is the first trap for administrators. Massive browser security releases create the illusion that individual bugs matter less because they arrive in bulk. In reality, bulk patch drops make prioritization harder because the most consequential bugs may be mixed with dozens or hundreds of lower-signal entries.
CVE-2026-13796 was one of several Chromecast-related high-severity issues listed in the same Chrome 150 release. Google’s notes also referenced Chromecast bugs involving insufficient validation, heap buffer overflow, integer overflow, and use-after-free conditions. That cluster matters because repeated findings in the same area can suggest concentrated code churn, focused internal review, or a component that has become newly interesting to researchers and attackers.
Google reported CVE-2026-13796 internally on March 11, according to the Chrome release entry. The public CVE landed at the end of June. That lag is normal for coordinated browser security work, but it also means defenders see the most actionable version of the risk only after the fix is already shipping.
The CPE Mismatch Is Not Just Cosmetic
The user-facing NVD page raises a very specific concern: the description says Chrome prior to 150.0.7871.47 is affected, while the NVD change history shows an added CPE configuration for Google Chrome versions up to, but excluding, 150.0.7871.46. That is exactly the sort of detail vulnerability managers cannot hand-wave away.On the evidence available, yes, the CPE metadata appears at least potentially inconsistent with the CVE description and Chrome’s Windows/Mac fixed version. The CVE description says “prior to 150.0.7871.47.” The Chrome release says Windows and Mac received 150.0.7871.46/.47. NVD’s change history, however, shows a vulnerable CPE range excluding 150.0.7871.46, which could cause automated tools to treat 150.0.7871.46 as fixed even where the relevant fixed build is 150.0.7871.47.
That does not automatically mean every scanner will get the answer wrong. Some products supplement NVD CPEs with vendor advisories, browser version detection, package metadata, or their own curated vulnerability intelligence. But any environment relying heavily on raw NVD CPE matching should treat this entry as one that needs manual review.
The safest operational line is to use Google’s advisory and the CVE description as the governing facts: for Windows and macOS, move to 150.0.7871.47 or later. If a tool reports 150.0.7871.46 as clean for CVE-2026-13796 without explaining platform nuance, that finding deserves skepticism rather than blind acceptance.
CISA’s Score Turns a Conditional Bug Into a Boardroom Number
CISA’s ADP enrichment gives CVE-2026-13796 a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. In plain English, that means network attack vector, low attack complexity, no privileges required, user interaction required, changed scope, and high confidentiality, integrity, and availability impact.The “user interaction required” part is the browser reality: someone has to land on or interact with malicious content. The “changed scope” and high impact fields are the warning flare. A sandbox escape is dangerous precisely because it crosses a trust boundary that is supposed to limit the damage from web content.
CISA’s SSVC enrichment listed exploitation as none, automatable as no, and technical impact as total. That is a useful split. There is no public indication from the data provided that CVE-2026-13796 is being exploited in the wild, but the consequence of successful exploitation is severe enough to justify fast patching.
This is where patch teams often get stuck between two bad instincts. One instinct says no known exploitation means the issue can wait. The other says a critical score means emergency everything. The saner reading is narrower: this is not evidence of an active fire, but it is exactly the kind of bug that should not survive the next maintenance window.
Renderer Compromise Is the Assumption Attackers Build Around
Browser security has spent years moving from “prevent every memory bug” toward “contain the inevitable memory bug.” Site isolation, sandboxing, process separation, and hardened IPC boundaries all assume that web content is hostile and that some renderer bugs will eventually be exploitable. A sandbox escape is therefore not merely another vulnerability class; it is an attack on the fallback plan.CVE-2026-13796 requires prior renderer compromise, which makes it a chain component. That can sound reassuring until one remembers how exploit chains are built. Attackers do not need every step to be packaged under the same CVE, and they do not need the sandbox escape to be the first bug a user encounters.
A crafted HTML page that can participate in such a chain is still a web-scale risk. It can be delivered through phishing, malvertising, compromised websites, or watering-hole attacks. The user does not need to install software, approve an extension, or authenticate to a service for the browser to become the first point of contact.
For enterprises, the relevant exposure is not limited to Chrome as a standalone consumer app. Chrome is often the front door to SaaS identity, admin consoles, device management portals, source repositories, and remote access tools. A sandbox escape in that context is not just a workstation problem; it can become an identity and lateral-movement problem.
Windows Administrators Should Watch the Chromium Lag
WindowsForum readers know the uncomfortable truth: “Chrome patched” does not mean “Chromium ecosystem patched.” Microsoft Edge, Brave, Vivaldi, Opera, Electron applications, embedded WebView runtimes, and vendor-bundled Chromium components all move on their own schedules. Some inherit fixes quickly; others trail.For managed Windows fleets, Chrome itself is usually the easy part. Google Update, enterprise policies, and browser version reporting make it relatively straightforward to push and verify current builds. The harder work is finding the Chromium copies nobody thinks about: app runtimes, bundled browsers in conferencing tools, kiosk shells, thin-client packages, and line-of-business software that quietly embeds a web engine.
CVE-2026-13796 is a Chrome CVE, not a universal statement about every Chromium-derived product. But once a fix lands in Chromium, downstream consumers need to answer whether they include the affected component and whether they have pulled the corrected code. Administrators should not assume absence from a vendor advisory equals absence of risk.
This is also why CPE precision matters. If vulnerability management tooling maps only “Google Chrome” cleanly but misses Chromium derivatives, an organization can patch the obvious browser while leaving the same class of browser-engine exposure elsewhere. The CPE question is not bookkeeping; it is asset discovery by another name.
The Metadata Wobble Is a Warning About Automated Triage
NVD’s page for CVE-2026-13796 shows no NIST CVSS score yet, while CISA-ADP provides a 9.6 Critical score. The weakness mapping also changed: CISA added CWE-190, then removed it, while Chrome’s source entry lists CWE-472. That is an odd pairing for a bug described as an integer overflow, and it illustrates how public vulnerability records can evolve messily after publication.Security teams sometimes treat CVE metadata as if it were a compiled binary: precise, finished, and authoritative. It is often closer to a living news file. Descriptions, CPEs, CWE mappings, CVSS vectors, references, and affected-version ranges can change as agencies enrich, normalize, or correct entries.
That matters because automated workflows frequently convert those fields directly into action. A CVSS score opens a ticket. A CPE match assigns an asset. A CWE label feeds a dashboard. A version range determines whether a patch is marked complete.
For CVE-2026-13796, the most defensible workflow is to privilege the vendor advisory for fixed versions, use CISA’s score as a severity signal, and treat NVD CPE data as useful but not final. That sounds obvious until a dashboard says otherwise.
The Patch Is Straightforward, the Verification Is Not
For individual users, the fix path is simple: open Chrome’s About page, let the browser check for updates, and restart into 150.0.7871.47 or later on Windows and macOS. Linux users should follow their distribution or Google package channel, with Chrome 150.0.7871.46 listed in Google’s stable-channel announcement for that platform.For administrators, the task is less about clicking update and more about proving closure. Version reporting should distinguish Windows, macOS, and Linux builds rather than flattening them into a single “Chrome 150” bucket. That distinction matters because this CVE’s public text points to 150.0.7871.47 as the relevant fixed threshold.
Enterprises should also check whether browser restart policies are actually completing the update. Chrome can download an update and still leave users running the old vulnerable process until restart. In security terms, “pending relaunch” is not patched; it is a promissory note.
The final verification step is scanner sanity. If a vulnerability tool marks Chrome 150.0.7871.46 on Windows or macOS as fixed for CVE-2026-13796 solely because of the NVD CPE range, security teams should validate that logic against Google’s release text. Conversely, if a tool flags Linux 150.0.7871.46 without platform context, it may be applying the Windows/Mac threshold too broadly.
The Chromecast CVE Leaves Administrators With a Narrow But Important Checklist
CVE-2026-13796 is not a panic story, but it is a discipline story. The vulnerability sits at the point where browser exploit chains, imperfect metadata, and fleet reality intersect.- Chrome on Windows and macOS should be updated to 150.0.7871.47 or later, because both the CVE description and Google’s release channel point to that build as the safe threshold.
- The NVD CPE range shown in the change history appears potentially inconsistent with the “prior to 150.0.7871.47” description, so scanner results should be manually checked.
- CISA’s 9.6 Critical score reflects the impact of a successful sandbox escape, even though the Chromium project labels the issue High.
- There is no public indication in the provided record that CVE-2026-13796 is being exploited in the wild, but the bug is serious enough to patch promptly.
- Chromium-based browsers and embedded runtimes should be reviewed separately, because Google Chrome’s patch does not automatically prove downstream products are current.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:56-07:00
NVD - CVE-2026-13796
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:56-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-13796 - Google Chrome Chromecast Sandbox Escape
Integer 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: labs.cloudsecurityalliance.org
NVD Enrichment Triage: Enterprise Vulnerability Programs Must Adapt
PDF documentlabs.cloudsecurityalliance.org