CVE-2026-14421: Update ChromeOS to 150.0.7871.46

Who must act: Anyone using Chrome on ChromeOS with a full version earlier than 150.0.7871.46.
Who is not established as in scope: Chrome on Windows, macOS, and desktop Linux. CVE-2026-14421’s published affected configuration is Chrome on ChromeOS; the record does not establish exposure on those other platforms.
Exact fix: On the Chromebook, open Settings > About ChromeOS > Check for updates. Allow the update to install, select Restart, return to Settings > About ChromeOS, and verify that the full version is 150.0.7871.46 or later.

Google disclosed CVE-2026-14421 as a medium-severity uninitialized-use flaw in Chrome’s Dawn graphics component on ChromeOS. A remote attacker may be able to expose potentially sensitive process-memory data by persuading a user to open a crafted HTML page in a Chrome version earlier than 150.0.7871.46.
The vulnerability is an information-disclosure bug, not a documented code-execution, persistence, or sandbox-escape flaw. Even so, its network reachability and potentially high confidentiality impact make it more consequential than the word Medium might suggest.
The remediation is direct: update affected ChromeOS devices, restart them, and verify the complete four-part version. The more complicated part is interpreting the platform boundary correctly because the product name, vendor advisory reference, and NVD configuration can initially appear broader than the affected scope.

The Product Name Says Chrome, but the Platform Boundary Says ChromeOS​

The most important scoping fact is not merely that Google Chrome is named. The published description limits CVE-2026-14421 to Google Chrome on ChromeOS before version 150.0.7871.46.
NIST’s initial analysis reinforces that boundary through an affected-software configuration that pairs the Chrome application CPE with the ChromeOS operating-system CPE. In practical terms, the configuration is not describing every installation of Chrome on every supported operating system. It describes the vulnerable Chrome version range when Chrome is running in the ChromeOS environment.
NVD also points to a Google Stable Channel Update for Desktop as vendor material. That reference does not, by itself, establish that this individual CVE affects every desktop platform discussed by the broader release advisory. A release post can cover many security fixes, while an individual CVE can have a narrower product, operating-system, feature, or configuration boundary.
For CVE-2026-14421, the published description and the combined Chrome-and-ChromeOS CPE configuration establish the documented scope. Windows, macOS, and desktop Linux are not identified as affected configurations in the supplied record.

Environment	Version condition	CVE-2026-14421 status	Published risk
Chrome on ChromeOS	Earlier than 150.0.7871.46	Affected	Crafted HTML may expose potentially sensitive process memory
Chrome on ChromeOS	150.0.7871.46 or later	Outside the published affected range	No exposure identified by this CVE record
Chrome on Windows	Any version	Not listed in the affected CPE configuration	This CVE does not establish Windows exposure
Chrome on macOS	Any version	Not listed in the affected CPE configuration	This CVE does not establish macOS exposure
Chrome on desktop Linux	Any version	Not listed in the affected CPE configuration	This CVE does not establish desktop Linux exposure

“Not listed” should not be stretched into a claim that related code could never have a defect on another platform. It means only that this CVE record identifies ChromeOS as the affected operating-system configuration.
That distinction should guide remediation reports. CVE-2026-14421 belongs in the ChromeOS update queue. It should not be applied indiscriminately to every Windows, macOS, or Linux system merely because Chrome is installed.

---

An Uninitialized Value Creates a Confidentiality Problem​

CVE-2026-14421 is categorized as CWE-457, Use of Uninitialized Variable. At a high level, this class of weakness occurs when software uses a variable or memory region before it has been assigned a valid and predictable value.
Instead of beginning with intentionally defined content, the affected operation may consume data that happens to remain in the relevant memory. If that data becomes observable through behavior or output controlled by a hostile page, information can cross a boundary that the browser was expected to preserve.
That is the confidentiality concern behind this CVE. The public description says a remote attacker may expose potentially sensitive information from process memory through a crafted HTML page.
The available record does not specify exactly what information can be recovered, how consistently it can be recovered, how much data may be exposed, or which process structures may occupy the relevant memory. The linked Chromium issue requires permissions, so the supplied public material does not provide a reproducer or a detailed explanation of the faulty operation.
It would therefore be irresponsible to turn “potentially sensitive information” into a claim that the vulnerability automatically yields passwords, authentication cookies, access tokens, encryption keys, browser history, or arbitrary files. Those outcomes are not established by the public description.
The defensible conclusion is narrower but still important: vulnerable Chrome-on-ChromeOS code may use uninitialized data in the Dawn graphics component when processing crafted HTML, creating a possibility that process-memory information becomes available to a remote attacker.
The practical sensitivity of any disclosure would depend on what occupied the affected memory at the time, what portion of it could be recovered, and whether the attacker could interpret the result. Those details are not resolved by the supplied record.

The Attack Is Remote, but It Is Not No-Click​

CISA-ADP assigned CVE-2026-14421 a CVSS 3.1 base score of 6.5 and the vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N.
That vector describes:

• A network attack vector.
• Low attack complexity.
• No privileges required.
• Required user interaction.
• Unchanged scope.
• High confidentiality impact.
• No identified integrity impact.
• No identified availability impact.

The network designation means the attacker does not need local physical access to the Chromebook. The CVE description identifies a crafted HTML page as the attack mechanism.
No privileges required means the attacker does not first need a valid user account or elevated access on the target device. The attacker still must get the crafted content in front of the user.
The record does not identify a particular delivery campaign or distribution technique. Links, advertisements, compromised sites, and similar mechanisms may be conceivable delivery examples for malicious web content in general, but they are hypothetical in this context and are not identified in the CVE record.
Required user interaction is the central limiting condition. The user must be induced to open or otherwise interact with the crafted page. The CVE is not described as a passive attack against an idle, disconnected, or untouched Chromebook.
Low attack complexity does not mean that the short public description is itself a ready-to-use exploit recipe. It means the CVSS assessment does not depend on specialized conditions outside the attacker’s control. The restricted Chromium issue also prevents the supplied public material from showing how reliable exploitation would be in practice.
The impact metrics are equally important. Confidentiality is rated high, but integrity and availability are rated none. The vulnerability is therefore not publicly characterized as a way to install software, alter system data, seize control of ChromeOS, or deliberately make the device unavailable.
An unchanged scope means the CVSS assessment does not score the flaw as crossing into a separate security authority. That does not make a process-memory disclosure harmless; it explains why the assessment stops short of treating the defect as a broader system takeover.
The combination produces a 6.5 medium base score: remotely reachable and requiring no prior privileges, but dependent on user interaction and publicly associated with confidentiality loss rather than modification, destruction, or full control.

“Medium” Describes the CVSS Result, Not the Value of the Data​

Severity labels encourage shorthand. Critical vulnerabilities become emergencies, high-severity flaws receive accelerated attention, and medium-severity bugs can drift toward the ordinary maintenance queue.
CVE-2026-14421 shows why a label should not replace analysis. Its medium score reflects the complete combination of exploitability and impact metrics. It does not mean that information held in process memory is inherently unimportant.
Confidentiality is rated high, the strongest impact value assigned in this vector. Integrity and availability remain at none, keeping the overall score below the high and critical ranges.
At the same time, the public evidence does not justify describing the CVE as an active mass-compromise event. CISA-ADP’s Stakeholder-Specific Vulnerability Categorization data lists exploitation as “none,” automatable as “no,” and technical impact as “partial.”
“Exploitation: none” means that the assessment did not identify evidence of active exploitation at the time represented by that record. It is not a guarantee that exploitation will never occur, and it does not prove that no one has investigated the vulnerability.
“Automatable: no” indicates that the assessed attack does not cleanly fit a reliably scalable, automated process under the SSVC model. Required interaction and the uncertain mechanics of recovering useful process data are consistent with that judgment.
“Technical impact: partial” aligns with the information-disclosure framing. The flaw may expose information, but the published assessment does not describe total control of the vulnerable component or the ChromeOS device.
The appropriate response is disciplined urgency rather than panic. Affected Chromebooks should be updated promptly, particularly when they are used to access sensitive organizational systems. The supplied evidence does not support claims of automatic takeover, active widespread exploitation, or a universal emergency affecting Chrome on every operating system.

The NVD Score Distinction Is About Data Provenance​

NVD displays the CISA-ADP CVSS 3.1 score of 6.5, while the supplied record indicates that NIST had not provided its own CVSS assessment.
That does not mean CVE-2026-14421 is unscored. It means the visible score was contributed through CISA-ADP rather than independently calculated and published as a NIST score.
Vulnerability databases commonly aggregate information from several authorities. The CVE source can provide the description, affected range, weakness classification, and references. An Authorized Data Publisher can add metrics and prioritization data. NIST can add configuration analysis and may separately publish its own assessment.
In this case, Chrome supplied the essential vulnerability description. CISA-ADP supplied the CVSS 3.1 vector and SSVC data. NIST added a Chrome-plus-ChromeOS affected configuration and represented 150.0.7871.46 as the exclusive upper boundary of the vulnerable range.
These contributions answer different questions:

• The Chrome record describes what the flaw is and which versions are affected.
• The CISA-ADP data evaluates severity and prioritization.
• The NIST configuration maps the issue into an affected-software model.

Administrators can record 6.5 as the CVSS 3.1 assessment from CISA-ADP while noting the absence of a separate NIST score in the supplied material. They do not need to postpone remediation until every scoring field has been independently populated.
The decisive patch-management question is whether a ChromeOS device is running a version earlier than 150.0.7871.46.

---

The Version Record Looks Awkward, but the Boundary Is Clear​

The raw affected-version data reportedly names version 150.0.7871.46 while also using a “less than 150.0.7871.46” condition. Without context, that structure can look self-contradictory because the same number appears in the record and as the exclusive upper boundary.
The prose description and NIST configuration resolve the ambiguity. Chrome on ChromeOS is affected before 150.0.7871.46. The threshold version itself is excluded from the affected range.
The actionable interpretation is therefore straightforward:

• 150.0.7871.45 or an earlier version: inside the affected range.
• 150.0.7871.46: at the fixed threshold.
• A later full version: outside the published affected range.

Administrators must compare the complete four-part version. Seeing only “Chrome 150” is not enough because an earlier Chrome 150 build could still fall below 150.0.7871.46.
The version check should not be based on whether the string “150.0.7871.46” merely appears in raw CVE data. It must be treated as a mathematical boundary: installed versions less than 150.0.7871.46 are affected.
Reports that omit the final build component should be treated as inconclusive. A device described only as running “version 150” has not been shown to meet the fixed-version threshold.

The Restricted Chromium Issue Limits Defensive Detail​

NVD links to Chromium issue 517033235, but the reference requires permissions. Defenders therefore have the public description, CWE category, CVSS vector, affected range, platform configuration, and vendor reference, but not the underlying engineering discussion or reproduction steps.
The record establishes that access is restricted. It does not, in the supplied material, establish Google’s reason for restricting this particular issue.
The absence of public technical detail means outside defenders cannot determine from this record whether the disclosure is deterministic, whether it depends on a particular graphics path, how much memory could be exposed, or how readily any recovered data could be converted into useful information.
That uncertainty requires restraint in both directions. The flaw should not be inflated into proven credential theft or device takeover. It also should not be dismissed merely because the public record omits an exploit demonstration.
Google has supplied enough information for remediation: crafted HTML, remote delivery, required user interaction, potential exposure of process-memory information, ChromeOS scope, and a fixed-version boundary.
For most administrators, a deeper exploit explanation would not change the immediate response. Systems below 150.0.7871.46 should be updated, restarted, and checked again.
The restricted issue is more consequential for detection and incident response. The sparse public description does not provide a distinctive request pattern, page signature, memory artifact, or other reliable indicator that would prove successful exploitation.
A browser history entry showing that a user visited an unfamiliar page would not establish that this flaw was triggered. Conversely, the absence of an obvious crash or alert would not prove that no information was exposed.
Patch verification is therefore more definitive than retrospective exploit detection for this CVE. Administrators can verify the installed full version. They cannot reconstruct every possible interaction between crafted HTML and transient process memory from the supplied public information.

Record-development timeline​

Because the supplied facts do not support the previously stated calendar dates and exact event times, the useful timeline is the sequence in which the record was enriched:

1. Chrome supplied the vulnerability record, including the ChromeOS-specific description, affected-version boundary, weakness classification, vendor reference, and restricted Chromium issue.
2. CISA-ADP added prioritization data, including the CVSS 3.1 vector and SSVC options.
3. NIST added configuration analysis, pairing the Chrome application CPE with ChromeOS and representing 150.0.7871.46 as the exclusive upper boundary.

This sequence explains why a vulnerability entry can become more precise as different authorities contribute product, scoring, and configuration data. It does not alter the operational conclusion: Chrome on ChromeOS below 150.0.7871.46 is the published affected configuration.

Update the Chromebook, Restart It, and Verify the Result​

End users should use the following procedure on every potentially affected Chromebook:

1. Open Settings.
2. Select About ChromeOS.
3. Select Check for updates.
4. Allow any available update to download and install.
5. Select Restart when prompted.
6. After the device restarts, return to Settings > About ChromeOS.
7. Verify that the displayed full version is 150.0.7871.46 or later.

The restart is part of the remediation procedure. Checking for updates without restarting and confirming the resulting version does not establish that the device has crossed the security boundary.
The final verification must use the full four-part number. “ChromeOS 150” or “Chrome 150” alone is insufficient.
Organizations using centralized device management should apply their documented ChromeOS servicing procedures and then confirm the installed full version through their approved inventory or device-verification method. The supplied CVE facts do not establish a specific managed-console navigation path, rollout behavior, or policy configuration, so those details should be taken from the organization’s current management platform documentation rather than inferred from this vulnerability record.
Operationally, administrators should distinguish between three states:

• Confirmed affected: A verified full version earlier than 150.0.7871.46.
• Confirmed remediated: A verified full version of 150.0.7871.46 or later.
• Unknown: No current full-version result is available.

The third category is a general operational consideration, not an additional claim about the vulnerability itself. An unknown version cannot be counted as remediated until the installed build has been confirmed.

Action checklist for admins​

• Identify ChromeOS devices that may be running Chrome versions earlier than 150.0.7871.46.
• Obtain the complete four-part installed version.
• Direct affected users to Settings > About ChromeOS > Check for updates.
• Require the device to be restarted after the update is installed.
• Verify that the post-restart full version is 150.0.7871.46 or later.
• Keep devices with missing or incomplete version data in an “unknown” category until they are checked.
• Use the full less-than comparison rather than relying on the Chrome 150 major version.
• Do not classify Chrome on Windows, macOS, or desktop Linux as affected solely because a broader Chrome release advisory is referenced.
• Document the CVSS score as the CISA-ADP assessment if score provenance matters to internal reporting.
• Avoid describing the issue as code execution, sandbox escape, credential theft, or active exploitation without additional evidence.

---

This Is Primarily a Patch-Verification Story​

The supplied record does not identify active exploitation, a public exploit chain, a specific campaign, or a named threat actor. That makes CVE-2026-14421 a poor basis for sensational claims but a useful test of endpoint visibility and patch verification.
Organizations should be able to answer a narrow question quickly: which ChromeOS systems are running a full version below 150.0.7871.46?
The record also tests whether vulnerability-management processes preserve platform qualifiers. A concrete inference follows from the NIST configuration: tools or reports that ignore the ChromeOS CPE qualifier may mis-scope this CVE.
That does not establish that any particular scanner or dashboard behaves incorrectly. It means that an implementation which extracts only “Google Chrome before 150.0.7871.46” while dropping the paired ChromeOS condition could incorrectly apply the record to Windows, macOS, or desktop Linux installations.
The safeguard is straightforward. Analysts should review the application and operating-system conditions together rather than matching only the Chrome product name and version range.
For Windows-focused IT departments that also administer Chromebooks, the division of responsibility should remain clear. CVE-2026-14421 should not be added indiscriminately to every Chrome-on-Windows emergency report. It should be routed to the team responsible for ChromeOS devices and tracked until those systems have a verified version of 150.0.7871.46 or later.

The Useful Facts Fit on One Screen​

CVE-2026-14421 is an uninitialized-use vulnerability in Chrome’s Dawn graphics component. A remote attacker may expose potentially sensitive process-memory information by persuading a user to open crafted HTML. The attack requires user interaction, needs no prior privileges, and is scored at 6.5 under CVSS 3.1 by CISA-ADP, with high confidentiality impact and no identified integrity or availability impact.
The published affected configuration is Chrome on ChromeOS before 150.0.7871.46. The record does not establish that Chrome on Windows, macOS, or desktop Linux is affected by this CVE.
The exact remediation is:
Settings > About ChromeOS > Check for updates > Restart
After restarting, return to Settings > About ChromeOS and verify that the complete version is 150.0.7871.46 or later.
That final version check is the decisive step. A crafted HTML page is the documented attack condition, versions below the threshold are the documented affected range, and a verified post-restart version at or above 150.0.7871.46 removes the Chromebook from that published range.

---

References​

1. Primary source: NVD / Chromium
   Published: 2026-07-11T15:39:25-07:00
   
   

   NVD - CVE-2026-14421

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-11T15:39:25-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: dawn.googlesource.com
   
   docs/dawn/overview.md - dawn - Git at Google
4. Related coverage: issues.chromium.org
   
   

   Chromium

   issues.chromium.org
5. Related coverage: chromium.org
   
   Quarterly Updates