Google Chrome CVE-2026-13774, published by NVD on June 30, 2026 and modified on July 2, affects Chrome before version 150.0.7871.47 on Windows, macOS, and Linux through a critical use-after-free flaw in the browser’s Extensions component. The short answer to the CPE question is that the Chrome application CPE is present in NVD’s enrichment, but the way it is wrapped with operating-system CPEs can make the listing look stranger than it really is. This is not a missing-product case so much as a reminder that browser vulnerabilities often sit awkwardly inside CPE’s older product-and-platform grammar. For administrators, the practical priority is simpler: get Chrome and Chromium-derived browsers past the fixed build, then revisit extension trust as a first-class attack surface.
That distinction matters. A malicious extension is not merely “content” rendered by the browser; it is code the user has granted a privileged foothold inside the browser’s trust model. Extensions can sit close to identity, session cookies, page contents, enterprise SaaS workflows, and browser-managed secrets. A memory-safety bug in that neighborhood is the kind of issue that turns a bad install decision into something much closer to a host compromise scenario.
The advisory trail is also unusually clean. Chrome received the CVE on June 30, NIST added CVSS and CPE enrichment on July 1, and CISA-ADP modified its SSVC timestamp on July 2. That sequence suggests the public metadata is still settling, but the fixed-version boundary is not ambiguous: Chrome before 150.0.7871.47 is the vulnerable range identified in the NVD record.
That means the core Chrome CPE is not missing. If anything, the enrichment is trying to express that the affected application is Google Chrome when running on the major desktop platforms. The “Are we missing a CPE?” prompt is a standard NVD feedback mechanism, not proof that no CPE exists.
Still, the structure is worth scrutinizing. The CPE model often struggles with cross-platform applications because the vulnerable thing is the browser, not the operating system. Adding Windows, macOS, and Linux as configuration constraints may be useful for scanners trying to narrow applicability, but it can also create the impression that the OS itself is a vulnerable product. It is not. The vulnerable software named in the CVE is Chrome.
There is also a small metadata oddity in the affected-version JSON shown in the CVE record: the version field displays 150.0.7871.47 while also saying versions less than 150.0.7871.47 are affected. That is a common artifact of CVE version-range encoding rather than a claim that the fixed build is vulnerable. The plain-language description and CPE range both point to the same conclusion: update to 150.0.7871.47 or later.
The CVSS vector is notable: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. In ordinary English, NVD says the attack is network-reachable, requires high attack complexity, needs no privileges, requires no user interaction under the CVSS definition, does not cross security scope, and can severely affect confidentiality, integrity, and availability.
That “UI:N” field may look surprising because the description says the attacker must convince a user to install a malicious extension. CVSS user interaction does not always map neatly to social engineering prerequisites that happen before exploitation. The installation step is part of the attack path, but once the malicious extension is present, the crafted extension can trigger the vulnerability without an additional victim click in the vulnerable component.
That is why administrators should resist downgrading the risk just because the attacker needs an extension install. In managed environments, extension installation is often the weakest policy layer in the browser stack. Users install productivity add-ons, password helpers, AI summarizers, PDF tools, shopping assistants, and internal workflow extensions with a speed that outpaces most approval processes.
For home users, the response is familiar: open Chrome’s About page, allow the browser to update, and restart it. For enterprise administrators, the work is more layered. Chrome auto-update can be fast, but fleet reality is messy: pinned versions, VDI images, kiosk systems, packaging delays, proxy-cached installers, and delayed restarts all create pockets of exposure.
The extension angle should change the patch conversation. If an exploit depends on malicious extension installation, then version compliance is only one control. Extension allowlisting, blocking sideloaded extensions, reviewing externally installed extensions, and auditing enterprise policy drift are equally important.
That is especially true in Windows-heavy environments, where Chrome often coexists with Edge and other Chromium-based browsers. A Chrome CVE does not automatically mean every Chromium browser is vulnerable in exactly the same way at exactly the same time. But shared Chromium code means administrators should check vendor-specific advisories and build numbers rather than assuming the Chrome fix has no relevance elsewhere.
In this case, the relevant Chrome CPE appears in NVD’s July 1 enrichment. If a scanner still says no applicable CPE exists, the problem may be local ingestion lag, a vendor plugin delay, or an inability to interpret the AND/OR configuration correctly. That is different from NVD missing the Chrome product entirely.
The more subtle issue is platform binding. The NVD configuration says Chrome before 150.0.7871.47 in combination with Windows, Linux kernel, or macOS. That is technically useful for desktop coverage, but it can miss nuance around packaging and derivatives. Linux distributions may ship Chromium packages under distribution-specific names. Enterprise-managed browsers may report product identity differently. Mobile Chrome, ChromeOS, and embedded Chromium are not automatically covered by the same desktop CPE expression.
That is why mature teams do not rely on CPE alone for browser emergencies. They combine CPE-based detection with installed software inventory, browser self-reported version telemetry, endpoint management data, and policy state. For Chrome, the version string is the control point administrators can actually verify.
Chrome has spent years investing in sandboxing, site isolation, memory allocators, exploit mitigations, and increasingly memory-safe rewrites where feasible. Yet use-after-free flaws remain a recurring theme because browsers are enormous C++ systems with decades of performance-sensitive code paths. The Extensions subsystem adds another layer of complexity because it mediates between web content, privileged browser APIs, extension processes, permissions, service workers, and user-granted capabilities.
The security model assumes extensions are constrained by permissions and review. A memory-corruption bug attacks the implementation underneath that model. Once the attacker has a malicious extension installed, the browser is no longer merely defending against hostile websites; it is defending against code that the user has invited inside the perimeter.
That is why extension ecosystems are an enduring security paradox. They are one of the reasons users choose a browser, and one of the reasons enterprises can adapt browsers to real workflows. They are also a supply-chain channel, a social-engineering surface, and a privileged API layer wrapped in branding that often feels safer than it is.
The better question is whether the organization can answer four operational questions quickly. Which Chrome versions are installed? Which endpoints have not restarted after receiving the update? Which extensions are installed and how were they installed? Which policies allow users to add new extensions without review?
If the answer to any of those questions is “we need to check several consoles,” CVE-2026-13774 is a useful stress test. Browser security has moved from the old desktop patch model into an identity-and-policy model. The browser is now where users authenticate, approve OAuth grants, run SaaS workloads, paste secrets into AI tools, and bridge personal and corporate accounts.
Microsoft shops have an additional wrinkle. Many organizations hardened Windows, deployed Defender, enforced BitLocker, and centralized identity, but left browser extension policy as a softer user-experience concession. That bargain is getting worse. A Critical browser extension vulnerability makes the extension catalog look less like customization and more like executable code distribution.
A crafted malicious extension also does not need mass adoption to matter. A threat actor targeting finance, legal, healthcare, government, or software development teams may only need a handful of installs. The browser is full of high-value data: admin consoles, source repositories, cloud dashboards, ticketing systems, webmail, SSO sessions, and password-manager interactions.
That makes extension governance a security control, not a productivity preference. Allowlisting is unpopular because it creates friction. But unmanaged extension installation is effectively unmanaged code execution inside the most sensitive application most users run all day.
This is where security teams should be careful with messaging. Telling users “do not install bad extensions” is not a control. Restricting extension installation to approved IDs, reviewing permissions, blocking developer-mode sideloading where possible, and monitoring for new extensions are controls.
Large browser security releases create operational tension. On one hand, administrators want to move quickly because attackers reverse-engineer patches. On the other hand, browser updates can break legacy extensions, internal web apps, media playback paths, automation frameworks, and kiosk workflows. The Reddit complaints already surfacing around Chrome 150 and extension compatibility are anecdotal, but they reflect a real enterprise concern: the security fix can arrive bundled with behavioral changes users notice immediately.
That tension should not become an excuse for delay. It should become an argument for better rings. A small pilot group, rapid validation of business-critical apps, and forced update deadlines are more defensible than either blind immediate deployment or open-ended deferral. Browsers update too frequently for every release to become a bespoke crisis.
The fixed-version line also matters for extended stable deployments. Organizations using extended channels often do so to reduce change velocity, but security fixes still need a defined path to endpoints. If the browser sits below the fixed version because a packaging team is waiting for a monthly maintenance window, the attacker is the only party benefiting from that calendar.
Security teams should therefore separate stable facts from still-moving metadata. The stable facts are the affected product, the fixed version boundary, the weakness class, the extension-based attack prerequisite, and the high-impact confidentiality, integrity, and availability consequences. The moving pieces include downstream scanner mappings, distribution-specific package status, derivative browser advisories, and any later exploitation intelligence.
CISA-ADP’s SSVC entry currently says exploitation is “none,” automatable is “no,” and technical impact is “total.” That does not mean the vulnerability is harmless. It means there is no public indication in that enrichment that exploitation is underway, and the attack path is not considered readily automatable in the SSVC sense. A malicious-extension exploit chain can still be highly effective in targeted operations.
This is a place where risk teams should avoid both panic and complacency. The absence of known exploitation on July 1 is not a guarantee on July 10. Conversely, a Critical Chromium severity does not mean every unpatched endpoint is being actively compromised. The sane response is controlled urgency.
The Vulnerability Is in Chrome, but the Blast Radius Runs Through Extensions
CVE-2026-13774 is not a drive-by webpage bug in the usual sense. According to the NVD entry sourced from Chrome, exploitation requires an attacker to convince a user to install a malicious Chrome extension, which then abuses a use-after-free flaw in the Extensions component to execute arbitrary code. Google’s Chromium security severity is listed as Critical, while NVD and CISA-ADP currently score it as CVSS 3.1 8.1 High.That distinction matters. A malicious extension is not merely “content” rendered by the browser; it is code the user has granted a privileged foothold inside the browser’s trust model. Extensions can sit close to identity, session cookies, page contents, enterprise SaaS workflows, and browser-managed secrets. A memory-safety bug in that neighborhood is the kind of issue that turns a bad install decision into something much closer to a host compromise scenario.
The advisory trail is also unusually clean. Chrome received the CVE on June 30, NIST added CVSS and CPE enrichment on July 1, and CISA-ADP modified its SSVC timestamp on July 2. That sequence suggests the public metadata is still settling, but the fixed-version boundary is not ambiguous: Chrome before 150.0.7871.47 is the vulnerable range identified in the NVD record.
NVD’s CPE Entry Is There, Even If It Reads Like a Riddle
The user-facing confusion comes from the “Known Affected Software Configurations” section. NVD’s initial analysis added a CPE configuration that includescpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* with versions up to but excluding 150.0.7871.47. It then combines that application CPE with platform CPEs for Microsoft Windows, Linux kernel, and Apple macOS.That means the core Chrome CPE is not missing. If anything, the enrichment is trying to express that the affected application is Google Chrome when running on the major desktop platforms. The “Are we missing a CPE?” prompt is a standard NVD feedback mechanism, not proof that no CPE exists.
Still, the structure is worth scrutinizing. The CPE model often struggles with cross-platform applications because the vulnerable thing is the browser, not the operating system. Adding Windows, macOS, and Linux as configuration constraints may be useful for scanners trying to narrow applicability, but it can also create the impression that the OS itself is a vulnerable product. It is not. The vulnerable software named in the CVE is Chrome.
There is also a small metadata oddity in the affected-version JSON shown in the CVE record: the version field displays 150.0.7871.47 while also saying versions less than 150.0.7871.47 are affected. That is a common artifact of CVE version-range encoding rather than a claim that the fixed build is vulnerable. The plain-language description and CPE range both point to the same conclusion: update to 150.0.7871.47 or later.
“Critical” and “High” Are Not Actually Contradicting Each Other
The severity labels look inconsistent only if you treat them as coming from the same system. Chromium’s “Critical” rating is Google’s internal security severity for the bug class and product impact. NVD’s “High” score is a CVSS 3.1 calculation with a base score of 8.1.The CVSS vector is notable: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. In ordinary English, NVD says the attack is network-reachable, requires high attack complexity, needs no privileges, requires no user interaction under the CVSS definition, does not cross security scope, and can severely affect confidentiality, integrity, and availability.
That “UI:N” field may look surprising because the description says the attacker must convince a user to install a malicious extension. CVSS user interaction does not always map neatly to social engineering prerequisites that happen before exploitation. The installation step is part of the attack path, but once the malicious extension is present, the crafted extension can trigger the vulnerability without an additional victim click in the vulnerable component.
That is why administrators should resist downgrading the risk just because the attacker needs an extension install. In managed environments, extension installation is often the weakest policy layer in the browser stack. Users install productivity add-ons, password helpers, AI summarizers, PDF tools, shopping assistants, and internal workflow extensions with a speed that outpaces most approval processes.
The Patch Is the Easy Part; Extension Governance Is the Hard Part
Google’s Stable Channel update moved desktop Chrome to the 150.0.7871.46 and 150.0.7871.47 line, with public reporting from PCWorld and others noting a very large security payload in the Chrome 150 release. The specific CVE at issue, CVE-2026-13774, is listed by Chrome as a Critical use-after-free in Extensions tied to Chromium issue 506558270.For home users, the response is familiar: open Chrome’s About page, allow the browser to update, and restart it. For enterprise administrators, the work is more layered. Chrome auto-update can be fast, but fleet reality is messy: pinned versions, VDI images, kiosk systems, packaging delays, proxy-cached installers, and delayed restarts all create pockets of exposure.
The extension angle should change the patch conversation. If an exploit depends on malicious extension installation, then version compliance is only one control. Extension allowlisting, blocking sideloaded extensions, reviewing externally installed extensions, and auditing enterprise policy drift are equally important.
That is especially true in Windows-heavy environments, where Chrome often coexists with Edge and other Chromium-based browsers. A Chrome CVE does not automatically mean every Chromium browser is vulnerable in exactly the same way at exactly the same time. But shared Chromium code means administrators should check vendor-specific advisories and build numbers rather than assuming the Chrome fix has no relevance elsewhere.
The CPE Question Exposes a Bigger Scanner Problem
Security teams live and die by asset inventory, and CPE is one of the languages scanners use to decide whether something is vulnerable. When a CPE entry is delayed, incomplete, or oddly modeled, vulnerability management tools can produce false negatives, false positives, or confusing “unknown applicability” states.In this case, the relevant Chrome CPE appears in NVD’s July 1 enrichment. If a scanner still says no applicable CPE exists, the problem may be local ingestion lag, a vendor plugin delay, or an inability to interpret the AND/OR configuration correctly. That is different from NVD missing the Chrome product entirely.
The more subtle issue is platform binding. The NVD configuration says Chrome before 150.0.7871.47 in combination with Windows, Linux kernel, or macOS. That is technically useful for desktop coverage, but it can miss nuance around packaging and derivatives. Linux distributions may ship Chromium packages under distribution-specific names. Enterprise-managed browsers may report product identity differently. Mobile Chrome, ChromeOS, and embedded Chromium are not automatically covered by the same desktop CPE expression.
That is why mature teams do not rely on CPE alone for browser emergencies. They combine CPE-based detection with installed software inventory, browser self-reported version telemetry, endpoint management data, and policy state. For Chrome, the version string is the control point administrators can actually verify.
Use-After-Free Bugs Keep Surviving Because Browsers Are Still Memory Machines
The weakness enumeration for CVE-2026-13774 is CWE-416, use after free. This class of bug occurs when software continues to reference memory after it has been freed, creating the possibility that an attacker can influence what occupies that memory later. In a complex browser, those mistakes can become code execution bugs.Chrome has spent years investing in sandboxing, site isolation, memory allocators, exploit mitigations, and increasingly memory-safe rewrites where feasible. Yet use-after-free flaws remain a recurring theme because browsers are enormous C++ systems with decades of performance-sensitive code paths. The Extensions subsystem adds another layer of complexity because it mediates between web content, privileged browser APIs, extension processes, permissions, service workers, and user-granted capabilities.
The security model assumes extensions are constrained by permissions and review. A memory-corruption bug attacks the implementation underneath that model. Once the attacker has a malicious extension installed, the browser is no longer merely defending against hostile websites; it is defending against code that the user has invited inside the perimeter.
That is why extension ecosystems are an enduring security paradox. They are one of the reasons users choose a browser, and one of the reasons enterprises can adapt browsers to real workflows. They are also a supply-chain channel, a social-engineering surface, and a privileged API layer wrapped in branding that often feels safer than it is.
Windows Admins Should Treat This as a Browser Policy Test
For WindowsForum readers, the immediate question is not whether Windows is vulnerable because the NVD record lists a Windows CPE. Windows is listed as a platform. The vulnerable product is Chrome, and the remediation is a Chrome update plus extension control.The better question is whether the organization can answer four operational questions quickly. Which Chrome versions are installed? Which endpoints have not restarted after receiving the update? Which extensions are installed and how were they installed? Which policies allow users to add new extensions without review?
If the answer to any of those questions is “we need to check several consoles,” CVE-2026-13774 is a useful stress test. Browser security has moved from the old desktop patch model into an identity-and-policy model. The browser is now where users authenticate, approve OAuth grants, run SaaS workloads, paste secrets into AI tools, and bridge personal and corporate accounts.
Microsoft shops have an additional wrinkle. Many organizations hardened Windows, deployed Defender, enforced BitLocker, and centralized identity, but left browser extension policy as a softer user-experience concession. That bargain is getting worse. A Critical browser extension vulnerability makes the extension catalog look less like customization and more like executable code distribution.
The Real Risk Is Not Just One Bad Extension
The CVE description imagines an attacker convincing a user to install a malicious extension. That sounds like a one-off phishing story, but the extension ecosystem has broader failure modes. Extensions can be acquired by new owners, updated after gaining a user base, impersonate legitimate tools, request broader permissions over time, or target niche enterprise workflows where users are more likely to trust them.A crafted malicious extension also does not need mass adoption to matter. A threat actor targeting finance, legal, healthcare, government, or software development teams may only need a handful of installs. The browser is full of high-value data: admin consoles, source repositories, cloud dashboards, ticketing systems, webmail, SSO sessions, and password-manager interactions.
That makes extension governance a security control, not a productivity preference. Allowlisting is unpopular because it creates friction. But unmanaged extension installation is effectively unmanaged code execution inside the most sensitive application most users run all day.
This is where security teams should be careful with messaging. Telling users “do not install bad extensions” is not a control. Restricting extension installation to approved IDs, reviewing permissions, blocking developer-mode sideloading where possible, and monitoring for new extensions are controls.
Chrome 150’s Security Payload Raises the Stakes
Public reporting around Chrome 150 has emphasized the sheer volume of security fixes in this release, with PCWorld reporting hundreds of fixes and multiple Critical CVEs in the stable-channel update. Whether the final count is described as 382, nearly 400, or more depending on how internal and external bugs are counted, the larger point is clear: this is not a routine cosmetic update.Large browser security releases create operational tension. On one hand, administrators want to move quickly because attackers reverse-engineer patches. On the other hand, browser updates can break legacy extensions, internal web apps, media playback paths, automation frameworks, and kiosk workflows. The Reddit complaints already surfacing around Chrome 150 and extension compatibility are anecdotal, but they reflect a real enterprise concern: the security fix can arrive bundled with behavioral changes users notice immediately.
That tension should not become an excuse for delay. It should become an argument for better rings. A small pilot group, rapid validation of business-critical apps, and forced update deadlines are more defensible than either blind immediate deployment or open-ended deferral. Browsers update too frequently for every release to become a bespoke crisis.
The fixed-version line also matters for extended stable deployments. Organizations using extended channels often do so to reduce change velocity, but security fixes still need a defined path to endpoints. If the browser sits below the fixed version because a packaging team is waiting for a monthly maintenance window, the attacker is the only party benefiting from that calendar.
The Metadata Is Still Young, So Do Not Overfit the Details
The CVE was published on June 30 and modified twice in the following two days. NVD says CVSS 4.0 is not yet provided, CVSS 2.0 is not yet assessed, and the CPE enrichment was added during initial NIST analysis on July 1. That is normal for a fresh browser CVE.Security teams should therefore separate stable facts from still-moving metadata. The stable facts are the affected product, the fixed version boundary, the weakness class, the extension-based attack prerequisite, and the high-impact confidentiality, integrity, and availability consequences. The moving pieces include downstream scanner mappings, distribution-specific package status, derivative browser advisories, and any later exploitation intelligence.
CISA-ADP’s SSVC entry currently says exploitation is “none,” automatable is “no,” and technical impact is “total.” That does not mean the vulnerability is harmless. It means there is no public indication in that enrichment that exploitation is underway, and the attack path is not considered readily automatable in the SSVC sense. A malicious-extension exploit chain can still be highly effective in targeted operations.
This is a place where risk teams should avoid both panic and complacency. The absence of known exploitation on July 1 is not a guarantee on July 10. Conversely, a Critical Chromium severity does not mean every unpatched endpoint is being actively compromised. The sane response is controlled urgency.
The CPE Is Present, but the Inventory Still Needs Proof
Here is the concrete read for WindowsForum readers and administrators staring at the NVD entry and wondering whether their tooling is wrong: the Chrome application CPE has been added, and it identifies Google Chrome versions before 150.0.7871.47 as vulnerable. The Windows, Linux, and macOS CPEs are platform qualifiers, not separate root causes. If your scanner does not show the CVE against Chrome installations, investigate feed freshness and CPE interpretation before assuming the CVE record lacks a mapping.- Chrome before 150.0.7871.47 is the affected desktop version range named in the CVE metadata.
- The vulnerability is a CWE-416 use-after-free issue in Chrome’s Extensions component.
- Exploitation requires a malicious Chrome extension, which makes extension policy part of the mitigation rather than an optional hardening step.
- NVD’s CPE enrichment includes the Google Chrome application CPE and platform qualifiers for Windows, Linux, and macOS.
- Administrators should verify actual browser versions and restart status, not just whether an update package was approved.
- CISA-ADP currently records no known exploitation, but the technical impact is still assessed as total.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:01-07:00
NVD - CVE-2026-13774
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:01-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: radar.offseq.com
CVE-2026-13774: Use after free in Google Chrome - Live Threat Intelligence - Threat Radar | OffSeq.com
Detailed information about CVE-2026-13774: Use after free in Google Chrome affecting Google Chrome. Get real-time updates, technical details, and mitigation strradar.offseq.com - Related coverage: vuldb.com
CVE-2026-13774 Google Chrome Extensions use after free (ID 506558 / Nessus ID 324031)
A weakness has been identified in Google Chrome. The identification of this vulnerability is CVE-2026-13774. The affected component should be upgraded.vuldb.com