Google and Microsoft disclosed CVE-2026-8016 on May 6, 2026, as a use-after-free flaw in Chromium’s WebRTC component affecting Google Chrome before version 148.0.7778.96 and tracked through MSRC for Chromium-based Microsoft Edge. The awkward part is not the patch; it is the risk language around it. Chromium calls the bug “Low” severity, while CISA’s ADP scoring assigns it a CVSS 3.1 score of 8.8, which is firmly “High.” For IT teams, that gap is the story: modern browser security is increasingly governed less by a single severity label than by where the bug lives, how quickly the browser forks absorb it, and whether users actually relaunch.
CVE-2026-8016 is described plainly enough: a use-after-free in WebRTC allowed a remote attacker to execute arbitrary code inside Chrome’s sandbox through a crafted HTML page. In ordinary language, the attacker needs to get the target to load attacker-controlled web content, after which a memory safety bug in the browser’s real-time communications stack can be triggered.
The phrase “inside a sandbox” matters, but it should not lull anyone into indifference. Chrome’s sandbox is a serious containment boundary, and code execution inside it is not the same as full system compromise. But browser exploitation is often a chain, not a single event: one bug gets execution in a renderer or adjacent process, another bug escapes containment, and a third persistence or credential-theft step turns a browser crash into an incident.
That is why the severity mismatch is so jarring. Chromium’s internal security severity of “Low” may reflect the project’s own exploitability judgment, component context, or mitigations. The CISA-ADP vector, by contrast, reads like the classic nightmare path for a browser bug: network attack vector, low complexity, no privileges required, user interaction required, and high confidentiality, integrity, and availability impact.
Both can be true in their own bureaucratic universes. Neither is enough by itself.
That combination has always made WebRTC a rich place for security mistakes. Real-time media code juggles buffers, codecs, network negotiation, device access, permissions, and state transitions that are difficult to reason about cleanly. A use-after-free bug in that environment is not exotic; it is the kind of memory lifetime error that C++ browser engines have spent years trying to fence off with safer allocators, partitioning, fuzzing, and process isolation.
The important point is that WebRTC does not require the victim to download a file or install an extension. The vulnerable surface is reachable through web content, which is why the CVE description’s “crafted HTML page” should land harder than the Chromium severity tag. A malicious site, compromised legitimate site, poisoned ad path, or phishing lure can all be enough to put browser parsing and runtime code under stress.
That does not mean CVE-2026-8016 is known to be exploited in the wild. The public material, as of May 7, does not say that. But vulnerability management is not only about today’s exploit status; it is about how quickly a known bug turns into a commodity test case once a patch ships and attackers can diff the code.
CVE-2026-8016 was not the headline-grabbing critical bug of that release. Chrome 148 reportedly included multiple critical vulnerabilities elsewhere in the browser stack, including memory safety issues in components such as Blink and Chromoting. That matters because enterprises rarely patch for one CVE in isolation; they patch a release train, and this release train carries a large pile of security debt being paid down at once.
For administrators, the practical threshold is simple: Chrome earlier than 148.0.7778.96 is below the fixed line for this vulnerability. On Windows and macOS, seeing 148.0.7778.96 or 148.0.7778.97 means the Chrome side of this particular issue is addressed. On Linux, 148.0.7778.96 is the named fixed version.
The version details are tedious, but tedious is where browser patching succeeds or fails. A fleet dashboard that says “Chrome 148” is comforting; a fleet dashboard that shows exact build numbers is useful. The difference between the two is the difference between assuming an update completed and knowing it did.
That inheritance model is a strength and a nuisance. It means Edge benefits from Chromium’s massive security engineering machine, including Google’s fuzzing, bug bounty pipeline, and rapid stable-channel fixes. It also means Windows administrators must stop thinking of “the browser” as a single vendor patch silo. Chrome, Edge, Brave, Opera, Vivaldi, Electron apps, and embedded Chromium runtimes may all consume related code, but they do not always ship the fix on the same day or advertise it with the same urgency.
Microsoft’s Edge security release notes have long used a formula that should be familiar by now: Edge stable or extended stable releases “incorporate the latest Security Updates of the Chromium project,” sometimes alongside Edge-specific fixes. That phrasing is operationally important. When Chromium ships a memory safety fix, the question for Edge shops becomes not “Is this a Windows Update?” but “Which Edge channel and version absorbed the Chromium patch?”
For managed Windows environments, that distinction can be painful. Edge may update through its own updater, policy-controlled channels, WSUS-adjacent tooling, Intune, Configuration Manager, or a third-party patch platform. Chrome may be governed by Google’s enterprise policies. Other Chromium browsers may sit outside both systems. A single CVE entry on MSRC can therefore expose an inventory problem masquerading as a browser problem.
That is not a failure of any one organization. It is what happens when vulnerability metadata tries to compress exploitability, impact, affected configurations, user interaction, mitigations, and real-world attacker interest into one number. CVE-2026-8016 is a useful example because the narrative fields and the numeric score seem to pull in different directions.
The sane interpretation is that enterprises should treat the bug as patch-now but not panic-now. It is remote, it is reachable through web content, it involves memory safety, and it lives in WebRTC. Those factors justify urgency. At the same time, the public advisory language does not indicate active exploitation, and the described code execution is inside the sandbox, not a standalone system takeover.
This is the uncomfortable middle where most real vulnerability management lives. The internet wants a red siren or a green checkmark. IT operations gets an amber light and a maintenance window.
But from a defender’s perspective, browser-sandbox code execution is not harmless. It can expose browser-origin data, interact with web-session state, become a foothold for further exploit stages, or provide a reliable primitive for exploit chains. Attackers who specialize in browsers do not think in single CVEs; they think in chains of conditions that move from content execution to sandbox escape to privilege escalation or token theft.
The modern browser is also a front door to business identity. Even without a full endpoint compromise, browser abuse can threaten session cookies, single sign-on workflows, password managers, OAuth flows, and sensitive web applications. That is why a bug “inside a sandbox” can still deserve high operational priority.
The most dangerous posture is to equate sandboxing with immunity. Sandboxing reduces blast radius. It does not turn memory corruption into a nuisance.
A vulnerability scanner may correctly flag Chrome and miss an embedded Chromium runtime inside a line-of-business application. It may see Edge through Microsoft’s catalog but fail to represent the same upstream code in an Electron-based desktop app. It may mark a device clean because the primary browser updated while a secondary browser remains stale in a user profile no one inventories.
This is where “Are we missing a CPE?” stops being a form-field curiosity and becomes an enterprise problem. Chromium is not a product so much as an ecosystem. CPEs are good at naming products; they are weaker at capturing inherited code exposure across forks, bundles, runtimes, and repackaged applications.
For most organizations, the defensible response is not to wait for perfect metadata. It is to maintain software inventory that can answer a simpler question: Where do we run Chromium code, and how quickly can each copy be updated?
CVE-2026-8016 has an associated Chromium issue link, but access to Chromium bug details is often restricted during the early update window. That is normal. It prevents instant copycat exploitation while the patch rolls out. It also means defenders should not mistake lack of public technical detail for lack of attacker interest.
The risk curve is especially sharp for endpoints that delay browser restarts. Chrome and Edge may download updates automatically, but the fix does not fully matter until the browser process is running the patched version. In a corporate environment full of always-open tabs, hibernating laptops, virtual desktops, and conference-room PCs, “auto-update enabled” can still leave a meaningful population sitting on old code.
This is why browser patch compliance should measure relaunch completion, not just update availability. A machine that has downloaded Chrome 148 but is still running a pre-148.0.7778.96 process is not a patched machine in the way defenders need it to be.
Enterprises should be particularly wary of extended stable channels. They exist for good reasons: change control, compatibility, testing, and reduced feature churn. But security teams need to understand exactly how those channels receive critical Chromium fixes and how long a given endpoint remains below the fixed version line. Slower feature cadence is not the same thing as slower security response, but the distinction must be validated rather than assumed.
The same logic applies to kiosks, VDI images, golden templates, lab machines, and offline endpoints. Browser updates are often treated as userland housekeeping until a web-facing RCE enters the room. Then suddenly the forgotten Chrome install on a jump box or the neglected Edge build in a base image becomes part of the attack surface.
A good vulnerability management program should not need a zero-day headline to know which browsers are stale. CVE-2026-8016 is not necessarily that kind of emergency. But it is a reminder that browser inventory is endpoint security inventory.
The home-user failure mode is not policy drift; it is deferral. People leave browsers open for weeks. They dismiss relaunch prompts because tabs feel like state, work, and memory. They assume that automatic updates are magic rather than a process that still needs the application to restart.
That behavior is understandable, but it is increasingly dangerous. The browser is the application most users expose to arbitrary hostile input every day. If there is one program on a Windows PC that should not be left unpatched because “I have too many tabs open,” it is the browser.
Password managers, session restore, tab groups, and browser sync have made relaunching less painful than it used to be. The security model assumes users will actually cross that last inch.
This is not unique to Chromium; OpenSSL, libxml, zlib, and countless other libraries have taught the same lesson. But browsers are different because they are simultaneously libraries, runtimes, user interfaces, identity surfaces, and exploit targets. When WebRTC breaks, the vulnerability may sit in a browser tab, a desktop wrapper, a collaboration app, or a device UI.
The uncomfortable truth is that many organizations still patch browsers as if they were consumer apps rather than critical infrastructure. They tolerate drift because “Chrome updates itself.” They assume Edge is covered because “Windows is patched.” They overlook Chromium forks because “nobody uses that browser officially.” Attackers do not have to respect those administrative categories.
CVE-2026-8016 is therefore less interesting as a single memory bug than as a test of dependency awareness. If your tooling can only answer whether Microsoft Update ran successfully, it cannot answer whether your Chromium exposure is fixed.
That sounds mundane, but it is where many organizations lose days. The policy says updates are automatic. The dashboard says deployment is staged. The user says they will restart later. The help desk says the machine has not checked in. Meanwhile, the fixed build exists, the vulnerable build persists, and the exploitability window widens.
Browser security has become a race against user inertia as much as attacker speed. The best organizations now force or strongly encourage relaunches after security updates, communicate why they are doing it, and design exceptions around business need rather than convenience. The worst organizations celebrate update deployment while leaving old browser processes running indefinitely.
CVE-2026-8016 does not require drama to justify discipline. It only requires accepting that a crafted web page is an attack path and that browsers do not protect users with patches they have not actually loaded.
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
A “Low” Chromium Bug With High-Impact Plumbing
CVE-2026-8016 is described plainly enough: a use-after-free in WebRTC allowed a remote attacker to execute arbitrary code inside Chrome’s sandbox through a crafted HTML page. In ordinary language, the attacker needs to get the target to load attacker-controlled web content, after which a memory safety bug in the browser’s real-time communications stack can be triggered.The phrase “inside a sandbox” matters, but it should not lull anyone into indifference. Chrome’s sandbox is a serious containment boundary, and code execution inside it is not the same as full system compromise. But browser exploitation is often a chain, not a single event: one bug gets execution in a renderer or adjacent process, another bug escapes containment, and a third persistence or credential-theft step turns a browser crash into an incident.
That is why the severity mismatch is so jarring. Chromium’s internal security severity of “Low” may reflect the project’s own exploitability judgment, component context, or mitigations. The CISA-ADP vector, by contrast, reads like the classic nightmare path for a browser bug: network attack vector, low complexity, no privileges required, user interaction required, and high confidentiality, integrity, and availability impact.
Both can be true in their own bureaucratic universes. Neither is enough by itself.
WebRTC Keeps Making Browser Bugs Feel Bigger Than Their Labels
WebRTC is not just another browser subsystem. It is the machinery behind peer-to-peer audio, video, and data channels used by conferencing apps, browser-based calling, collaborative tools, customer-support widgets, and a long tail of embedded communications services. It is complex, performance-sensitive code that handles untrusted inputs while trying to keep latency low and compatibility broad.That combination has always made WebRTC a rich place for security mistakes. Real-time media code juggles buffers, codecs, network negotiation, device access, permissions, and state transitions that are difficult to reason about cleanly. A use-after-free bug in that environment is not exotic; it is the kind of memory lifetime error that C++ browser engines have spent years trying to fence off with safer allocators, partitioning, fuzzing, and process isolation.
The important point is that WebRTC does not require the victim to download a file or install an extension. The vulnerable surface is reachable through web content, which is why the CVE description’s “crafted HTML page” should land harder than the Chromium severity tag. A malicious site, compromised legitimate site, poisoned ad path, or phishing lure can all be enough to put browser parsing and runtime code under stress.
That does not mean CVE-2026-8016 is known to be exploited in the wild. The public material, as of May 7, does not say that. But vulnerability management is not only about today’s exploit status; it is about how quickly a known bug turns into a commodity test case once a patch ships and attackers can diff the code.
The Patch Arrived Inside Chrome 148’s Larger Security Sweep
Chrome 148 reached the desktop stable channel on May 5, 2026, with version 148.0.7778.96 for Linux and 148.0.7778.96/97 for Windows and macOS. Google’s release notes describe the update as containing numerous fixes and improvements, and third-party coverage has counted the security fixes in this Chrome 148 wave at well over one hundred.CVE-2026-8016 was not the headline-grabbing critical bug of that release. Chrome 148 reportedly included multiple critical vulnerabilities elsewhere in the browser stack, including memory safety issues in components such as Blink and Chromoting. That matters because enterprises rarely patch for one CVE in isolation; they patch a release train, and this release train carries a large pile of security debt being paid down at once.
For administrators, the practical threshold is simple: Chrome earlier than 148.0.7778.96 is below the fixed line for this vulnerability. On Windows and macOS, seeing 148.0.7778.96 or 148.0.7778.97 means the Chrome side of this particular issue is addressed. On Linux, 148.0.7778.96 is the named fixed version.
The version details are tedious, but tedious is where browser patching succeeds or fails. A fleet dashboard that says “Chrome 148” is comforting; a fleet dashboard that shows exact build numbers is useful. The difference between the two is the difference between assuming an update completed and knowing it did.
Edge Inherits the Chromium Clock, but Not Always the Chromium Label
The user-facing wrinkle for WindowsForum readers is Microsoft Edge. Since the modern Edge is Chromium-based, many Chromium CVEs flow into Microsoft’s world through the MSRC Update Guide rather than arriving as Windows flaws in the traditional Patch Tuesday sense. CVE-2026-8016 is one of those cases: the source is Chrome/Chromium, but Microsoft tracks it because Edge consumes the affected upstream code.That inheritance model is a strength and a nuisance. It means Edge benefits from Chromium’s massive security engineering machine, including Google’s fuzzing, bug bounty pipeline, and rapid stable-channel fixes. It also means Windows administrators must stop thinking of “the browser” as a single vendor patch silo. Chrome, Edge, Brave, Opera, Vivaldi, Electron apps, and embedded Chromium runtimes may all consume related code, but they do not always ship the fix on the same day or advertise it with the same urgency.
Microsoft’s Edge security release notes have long used a formula that should be familiar by now: Edge stable or extended stable releases “incorporate the latest Security Updates of the Chromium project,” sometimes alongside Edge-specific fixes. That phrasing is operationally important. When Chromium ships a memory safety fix, the question for Edge shops becomes not “Is this a Windows Update?” but “Which Edge channel and version absorbed the Chromium patch?”
For managed Windows environments, that distinction can be painful. Edge may update through its own updater, policy-controlled channels, WSUS-adjacent tooling, Intune, Configuration Manager, or a third-party patch platform. Chrome may be governed by Google’s enterprise policies. Other Chromium browsers may sit outside both systems. A single CVE entry on MSRC can therefore expose an inventory problem masquerading as a browser problem.
The Severity Disagreement Is a Governance Problem, Not a Math Error
Security teams love scores because scores turn ambiguity into queues. CVSS says 8.8, so it rises. Chromium says “Low,” so it falls. NVD had not yet provided its own full assessment when the entry was newly enriched, so the interim picture is a patchwork of vendor description, CISA-ADP scoring, CWE classification, and CPE configuration.That is not a failure of any one organization. It is what happens when vulnerability metadata tries to compress exploitability, impact, affected configurations, user interaction, mitigations, and real-world attacker interest into one number. CVE-2026-8016 is a useful example because the narrative fields and the numeric score seem to pull in different directions.
The sane interpretation is that enterprises should treat the bug as patch-now but not panic-now. It is remote, it is reachable through web content, it involves memory safety, and it lives in WebRTC. Those factors justify urgency. At the same time, the public advisory language does not indicate active exploitation, and the described code execution is inside the sandbox, not a standalone system takeover.
This is the uncomfortable middle where most real vulnerability management lives. The internet wants a red siren or a green checkmark. IT operations gets an amber light and a maintenance window.
Sandboxed Code Execution Is Still Code Execution
The sandbox clause deserves special attention because it is often misunderstood. Chrome’s sandbox is designed to restrict what compromised renderer processes can do to the host operating system. If an attacker gains execution only within that boundary, they still need an escape to read arbitrary files, install malware, or take over the device.But from a defender’s perspective, browser-sandbox code execution is not harmless. It can expose browser-origin data, interact with web-session state, become a foothold for further exploit stages, or provide a reliable primitive for exploit chains. Attackers who specialize in browsers do not think in single CVEs; they think in chains of conditions that move from content execution to sandbox escape to privilege escalation or token theft.
The modern browser is also a front door to business identity. Even without a full endpoint compromise, browser abuse can threaten session cookies, single sign-on workflows, password managers, OAuth flows, and sensitive web applications. That is why a bug “inside a sandbox” can still deserve high operational priority.
The most dangerous posture is to equate sandboxing with immunity. Sandboxing reduces blast radius. It does not turn memory corruption into a nuisance.
CPE Metadata Tells Us Who Gets Counted, Not Who Gets Fixed
The NVD configuration for CVE-2026-8016 lists Google Chrome versions up to but excluding 148.0.7778.96 across Windows, Linux, and macOS operating-system contexts. That is useful for scanners because CPEs need structured product names and version ranges. It is less useful for the messy reality of Chromium-derived software.A vulnerability scanner may correctly flag Chrome and miss an embedded Chromium runtime inside a line-of-business application. It may see Edge through Microsoft’s catalog but fail to represent the same upstream code in an Electron-based desktop app. It may mark a device clean because the primary browser updated while a secondary browser remains stale in a user profile no one inventories.
This is where “Are we missing a CPE?” stops being a form-field curiosity and becomes an enterprise problem. Chromium is not a product so much as an ecosystem. CPEs are good at naming products; they are weaker at capturing inherited code exposure across forks, bundles, runtimes, and repackaged applications.
For most organizations, the defensible response is not to wait for perfect metadata. It is to maintain software inventory that can answer a simpler question: Where do we run Chromium code, and how quickly can each copy be updated?
The Real Exploit Window Opens After the Release Notes
There is a familiar rhythm to browser CVEs. A vendor ships a fix, restricts detailed bug discussion until enough users update, and gives defenders a brief head start. Attackers then examine patches, crash test cases, or related commits to infer the vulnerable condition. The public CVE entry is only the beginning of that race.CVE-2026-8016 has an associated Chromium issue link, but access to Chromium bug details is often restricted during the early update window. That is normal. It prevents instant copycat exploitation while the patch rolls out. It also means defenders should not mistake lack of public technical detail for lack of attacker interest.
The risk curve is especially sharp for endpoints that delay browser restarts. Chrome and Edge may download updates automatically, but the fix does not fully matter until the browser process is running the patched version. In a corporate environment full of always-open tabs, hibernating laptops, virtual desktops, and conference-room PCs, “auto-update enabled” can still leave a meaningful population sitting on old code.
This is why browser patch compliance should measure relaunch completion, not just update availability. A machine that has downloaded Chrome 148 but is still running a pre-148.0.7778.96 process is not a patched machine in the way defenders need it to be.
The Enterprise Burden Is No Longer Just Patch Speed
The easy advice is to update Chrome and Edge. The harder advice is to build a browser update practice that assumes this will happen again next week. Chromium’s scale, code complexity, and security research attention guarantee a steady stream of memory safety fixes. Some will be critical. Some will be “low.” Some will have active exploitation. Many will be ambiguous until after defenders have already had to act.Enterprises should be particularly wary of extended stable channels. They exist for good reasons: change control, compatibility, testing, and reduced feature churn. But security teams need to understand exactly how those channels receive critical Chromium fixes and how long a given endpoint remains below the fixed version line. Slower feature cadence is not the same thing as slower security response, but the distinction must be validated rather than assumed.
The same logic applies to kiosks, VDI images, golden templates, lab machines, and offline endpoints. Browser updates are often treated as userland housekeeping until a web-facing RCE enters the room. Then suddenly the forgotten Chrome install on a jump box or the neglected Edge build in a base image becomes part of the attack surface.
A good vulnerability management program should not need a zero-day headline to know which browsers are stale. CVE-2026-8016 is not necessarily that kind of emergency. But it is a reminder that browser inventory is endpoint security inventory.
Home Users Get the Same Fix, but a Different Failure Mode
For individual users, the mitigation path is simpler. Open the browser’s About page, let the update check complete, and relaunch. In Chrome, the target is 148.0.7778.96 or later for this CVE. In Edge, users should check that the installed version includes the corresponding Chromium security update from Microsoft’s release channel.The home-user failure mode is not policy drift; it is deferral. People leave browsers open for weeks. They dismiss relaunch prompts because tabs feel like state, work, and memory. They assume that automatic updates are magic rather than a process that still needs the application to restart.
That behavior is understandable, but it is increasingly dangerous. The browser is the application most users expose to arbitrary hostile input every day. If there is one program on a Windows PC that should not be left unpatched because “I have too many tabs open,” it is the browser.
Password managers, session restore, tab groups, and browser sync have made relaunching less painful than it used to be. The security model assumes users will actually cross that last inch.
The Chromium Supply Chain Turns One Bug Into Many Vendor Timelines
The broader lesson is that Chromium has become infrastructure. A bug in Chromium is not merely a Google Chrome issue, even when Google is the CVE source. It is a dependency event that radiates through Microsoft Edge, downstream browsers, embedded runtimes, Linux packages, enterprise-managed app catalogs, and sometimes commercial products that do not loudly advertise their browser engine.This is not unique to Chromium; OpenSSL, libxml, zlib, and countless other libraries have taught the same lesson. But browsers are different because they are simultaneously libraries, runtimes, user interfaces, identity surfaces, and exploit targets. When WebRTC breaks, the vulnerability may sit in a browser tab, a desktop wrapper, a collaboration app, or a device UI.
The uncomfortable truth is that many organizations still patch browsers as if they were consumer apps rather than critical infrastructure. They tolerate drift because “Chrome updates itself.” They assume Edge is covered because “Windows is patched.” They overlook Chromium forks because “nobody uses that browser officially.” Attackers do not have to respect those administrative categories.
CVE-2026-8016 is therefore less interesting as a single memory bug than as a test of dependency awareness. If your tooling can only answer whether Microsoft Update ran successfully, it cannot answer whether your Chromium exposure is fixed.
The Practical Window for Action Is Measured in Relaunches
For Chrome administrators, the immediate job is to verify that desktop systems are on 148.0.7778.96 or later, with the Windows and macOS 148.0.7778.97 build also acceptable where deployed. For Edge administrators, the job is to confirm the Microsoft channel release that incorporates the Chromium fix and then prove rollout by installed version, not policy intent.That sounds mundane, but it is where many organizations lose days. The policy says updates are automatic. The dashboard says deployment is staged. The user says they will restart later. The help desk says the machine has not checked in. Meanwhile, the fixed build exists, the vulnerable build persists, and the exploitability window widens.
Browser security has become a race against user inertia as much as attacker speed. The best organizations now force or strongly encourage relaunches after security updates, communicate why they are doing it, and design exceptions around business need rather than convenience. The worst organizations celebrate update deployment while leaving old browser processes running indefinitely.
CVE-2026-8016 does not require drama to justify discipline. It only requires accepting that a crafted web page is an attack path and that browsers do not protect users with patches they have not actually loaded.
The Small WebRTC CVE That Should Change This Week’s Patch Meeting
This is not the kind of vulnerability that demands breathless all-hands emergency calls in every environment. It is, however, exactly the kind of vulnerability that should sharpen the browser patch muscle before a noisier exploit arrives. The concrete actions are narrow, but the lesson is broad.- Chrome installations should be verified at 148.0.7778.96 or later, with exact build reporting rather than major-version reporting.
- Microsoft Edge should be checked against Microsoft’s security release channel for the Chromium update that absorbs the CVE-2026-8016 fix.
- Browser update compliance should include relaunch status, because downloaded updates do not protect processes still running vulnerable code.
- Security teams should inventory Chromium-based browsers and embedded runtimes beyond Chrome and Edge, especially on developer workstations and unmanaged endpoints.
- The “Low” Chromium label should not override the operational significance of remote, user-triggered memory corruption in WebRTC.
- Extended stable and delayed rollout policies should be reviewed to ensure security fixes are not unintentionally slowed by feature-change controls.
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
