Google Chrome CVE-2026-14061 is a low-severity Chromium Dawn information-disclosure flaw fixed in Chrome 150.0.7871.47, published by NVD on June 30, 2026, and later enriched by CISA with a medium CVSS 3.1 score tied to crafted HTML and user interaction. The oddity is not the bug itself; it is the metadata around it. NVD’s change log appears to describe Chrome versions up to but excluding 150.0.7871.46, while the CVE description and Chrome-origin affected record point to 150.0.7871.47 as the fixed boundary. For defenders who automate patch compliance from CPEs, that one-build discrepancy is exactly where “low severity” can become operational noise.
CVE-2026-14061 sits in Dawn, the Chromium project’s WebGPU implementation layer. In plain terms, this is browser plumbing that helps web content talk to modern graphics APIs without handing arbitrary websites direct access to the machine underneath. That makes Dawn a sensitive place for even modest bugs, because it lives near the line between high-performance graphics and the browser sandbox.
Google’s own description, echoed by NVD, says the flaw allowed a remote attacker to obtain potentially sensitive information from process memory through a crafted HTML page. Chromium rated it Low, while CISA’s ADP enrichment assigned a CVSS 3.1 score of 6.5, or Medium, with high confidentiality impact and no integrity or availability impact.
That split is not necessarily a contradiction. Browser vendors often score issues in the context of exploitability, mitigations, sandboxing, and whether a bug is likely to produce a reliable compromise. CVSS, by contrast, can make a memory-disclosure issue look sharper because confidentiality loss is doing most of the scoring work.
The result is a familiar patch-management headache: Chrome calls it low, CISA’s vector makes it medium, and scanners will likely pick whichever interpretation best fits their feed. The browser is fixed either way, but the dashboard may not look fixed until the metadata catches up.
That looks suspicious. If the narrative description says “prior to 150.0.7871.47,” then a CPE cutoff at 150.0.7871.46 risks leaving exactly one build in a gray zone. In vulnerability-management terms, that means some scanners could consider 150.0.7871.46 remediated even though the CVE text says the fix is 150.0.7871.47.
There is a nuance here. Google’s Chrome stable releases often publish slightly different build numbers across Windows, macOS, Linux, and Android, and the same advisory may list paired desktop builds. But the CVE record as provided points specifically to 150.0.7871.47 as the fixed threshold for CVE-2026-14061.
So yes, if the question is whether the CPE data looks incomplete or inconsistent, the answer is: the CPE cutoff should be reviewed. The more likely issue is not that Windows, Linux, or macOS CPEs are missing; it is that the affected Chrome version range may have been encoded one build too low.
That distinction matters because CPE data is machine-readable, and machine-readable does not always mean human-intuitive. A scanner might display the OS CPE in a way that makes the platform look implicated, when the vulnerable product is still Chrome. Administrators should resist the temptation to read the platform CPEs as separate operating-system vulnerabilities.
The more defensible CPE interpretation is that Chrome is the affected application and those operating systems define the environments where the vulnerable application builds exist. If anything is “missing,” it would be additional affected Chromium-derived products only if those vendors independently ship vulnerable Dawn code and have not yet rebased to a fixed Chromium build.
That is where NVD usually stays conservative. Chrome’s CVE record is for Google Chrome, not automatically for Microsoft Edge, Brave, Vivaldi, Opera, Electron applications, or every downstream Chromium embedder. Those products may share code ancestry, but their exposure and fix status depend on their own release trains.
But it is also not nothing. Browser memory can contain fragments of sensitive state, and modern exploit chains often use information disclosure to weaken mitigations that would otherwise stop a stronger bug. Address-space layout randomization, sandbox boundaries, and renderer isolation all become more useful to attackers when they can learn what memory looks like.
The “crafted HTML page” phrase is also important. This is not a local-only bug requiring shell access or an already-compromised endpoint. It lives in the ordinary web threat model: a user visits or is directed to content that exercises a vulnerable path.
User interaction is part of CISA’s vector, which lowers urgency. But in browser security, “requires user interaction” can simply mean someone has to load a page. That is not much comfort in an enterprise where email, chat, search ads, and compromised websites are all delivery mechanisms.
The security bargain is that browsers mediate this access ruthlessly. Web content should get performance without raw hardware trust. When a component like Dawn has an inappropriate implementation issue, the concern is that the mediation layer has leaked something it should have contained.
That does not make WebGPU uniquely reckless. It makes it modern browser engineering. Chrome, Edge, Safari, and Firefox all live with the same strategic pressure: expose more platform power to the web while preserving the illusion that a hostile page is just another page.
CVE-2026-14061 is small in that larger story. It is one information-disclosure bug among hundreds of Chrome fixes in a large stable-channel update. But it is a reminder that browser attack surface is no longer just HTML parsing, JavaScript engines, and old plug-in ghosts; it is also GPU adapters, shader translation, command buffers, and compatibility layers.
That is what happened here. CISA’s ADP vector describes network attack vector, low attack complexity, no privileges required, required user interaction, unchanged scope, high confidentiality impact, and no integrity or availability impact. That combination lands at 6.5 under CVSS 3.1.
Security teams should not waste time arguing that Chrome’s “Low” label invalidates the scanner. They should document the vendor rating, the CISA enrichment, and the compensating fact that there is no known exploitation in the submitted SSVC record. Then they should patch Chrome normally and close the finding against the fixed version.
The bigger risk is exception handling. If an organization has a policy that allows low-severity browser findings to sit for weeks, this CVE may slip into the slow lane despite being web-triggerable. Conversely, if every medium browser finding triggers emergency change control, teams will burn cycles on a bug that Google did not treat as a crisis.
The sane middle ground is accelerated routine patching. Chrome’s update cadence is built for this kind of issue, and enterprise policy should be too.
This is the uncomfortable truth of vulnerability management in 2026: structured vulnerability data is not a legal transcript of reality. It is an evolving model assembled from vendor advisories, CNA records, CISA enrichment, NIST analysis, CPE dictionaries, and downstream interpretations. Most of the time it is good enough. At version boundaries, “good enough” can become misleading.
The practical fix is to set the remediation target to Chrome 150.0.7871.47 or later, regardless of whether a feed currently marks 150.0.7871.46 as outside the affected range. That aligns with the CVE description and avoids a needless debate over a single patch build.
If your tooling supports custom overrides, this is a candidate for one. If it does not, the fallback is procedural: note the discrepancy in the ticket, update beyond both disputed thresholds, and verify the browser reports a version at or above 150.0.7871.47.
Microsoft typically ships Edge security fixes on its own cadence and documents them separately. Administrators managing Edge should check Microsoft’s Edge release notes and security update guidance rather than assuming the Google Chrome CPE applies directly. The same logic holds for Brave, Vivaldi, Opera, and Chromium-based embedded browsers.
This is frustrating but necessary. Chromium is a shared upstream project, while browsers are shipped products. A vulnerability may exist upstream, be fixed upstream, land in Chrome first, and then appear in downstream advisories under different timing or packaging.
Electron deserves a special mention because many desktop apps quietly embed Chromium components. A Chrome browser update does not update every Electron application installed on a fleet. If Dawn-related exposure matters to your threat model, high-risk Electron apps need vendor-specific tracking, not just Chrome patch compliance.
In managed environments, Chrome for Enterprise gives administrators policy controls for update timing, relaunch notifications, and target channel behavior. Those controls are useful, but they also create responsibility. A delayed relaunch policy that makes sense for line-of-business continuity can leave browser processes running vulnerable code after the patch is staged.
The simplest verification is still version-based. Inventory should report Chrome 150.0.7871.47 or later for systems where this CVE is in scope. If a scanner says a device is compliant at 150.0.7871.46, security teams should compare that result against the CVE description before closing the ticket.
There is no evidence in the submitted record that this vulnerability is being exploited in the wild. That should keep the response measured. But measured does not mean passive; browser fixes are perishable, and attackers do not need much time to diff patches once they land.
A Small Dawn Bug Exposes a Bigger Metadata Problem
CVE-2026-14061 sits in Dawn, the Chromium project’s WebGPU implementation layer. In plain terms, this is browser plumbing that helps web content talk to modern graphics APIs without handing arbitrary websites direct access to the machine underneath. That makes Dawn a sensitive place for even modest bugs, because it lives near the line between high-performance graphics and the browser sandbox.Google’s own description, echoed by NVD, says the flaw allowed a remote attacker to obtain potentially sensitive information from process memory through a crafted HTML page. Chromium rated it Low, while CISA’s ADP enrichment assigned a CVSS 3.1 score of 6.5, or Medium, with high confidentiality impact and no integrity or availability impact.
That split is not necessarily a contradiction. Browser vendors often score issues in the context of exploitability, mitigations, sandboxing, and whether a bug is likely to produce a reliable compromise. CVSS, by contrast, can make a memory-disclosure issue look sharper because confidentiality loss is doing most of the scoring work.
The result is a familiar patch-management headache: Chrome calls it low, CISA’s vector makes it medium, and scanners will likely pick whichever interpretation best fits their feed. The browser is fixed either way, but the dashboard may not look fixed until the metadata catches up.
The Version Boundary Is the Story Administrators Should Watch
The key practical fact is simple: Chrome before 150.0.7871.47 is described as affected, and 150.0.7871.47 is the build administrators should treat as the minimum safe version for this CVE. The user-submitted NVD text, however, shows a CPE configuration added by NIST for Google Chrome versions up to but excluding 150.0.7871.46.That looks suspicious. If the narrative description says “prior to 150.0.7871.47,” then a CPE cutoff at 150.0.7871.46 risks leaving exactly one build in a gray zone. In vulnerability-management terms, that means some scanners could consider 150.0.7871.46 remediated even though the CVE text says the fix is 150.0.7871.47.
There is a nuance here. Google’s Chrome stable releases often publish slightly different build numbers across Windows, macOS, Linux, and Android, and the same advisory may list paired desktop builds. But the CVE record as provided points specifically to 150.0.7871.47 as the fixed threshold for CVE-2026-14061.
So yes, if the question is whether the CPE data looks incomplete or inconsistent, the answer is: the CPE cutoff should be reviewed. The more likely issue is not that Windows, Linux, or macOS CPEs are missing; it is that the affected Chrome version range may have been encoded one build too low.
The Operating-System CPEs Are Not the Missing Piece
The NVD configuration shown in the record uses an AND relationship: vulnerable Google Chrome plus one of several operating systems, including Windows, Linux, and macOS. That pattern is common for cross-platform desktop applications. It does not mean Windows itself, the Linux kernel itself, or macOS itself contains the vulnerability.That distinction matters because CPE data is machine-readable, and machine-readable does not always mean human-intuitive. A scanner might display the OS CPE in a way that makes the platform look implicated, when the vulnerable product is still Chrome. Administrators should resist the temptation to read the platform CPEs as separate operating-system vulnerabilities.
The more defensible CPE interpretation is that Chrome is the affected application and those operating systems define the environments where the vulnerable application builds exist. If anything is “missing,” it would be additional affected Chromium-derived products only if those vendors independently ship vulnerable Dawn code and have not yet rebased to a fixed Chromium build.
That is where NVD usually stays conservative. Chrome’s CVE record is for Google Chrome, not automatically for Microsoft Edge, Brave, Vivaldi, Opera, Electron applications, or every downstream Chromium embedder. Those products may share code ancestry, but their exposure and fix status depend on their own release trains.
“Low” Does Not Mean “Ignore,” Especially in a Browser
A memory disclosure bug in a browser rarely lands with the drama of a remote-code-execution flaw. It does not promise immediate system takeover, and CISA’s SSVC data in the submitted record says exploitation was “none,” automatable was “no,” and technical impact was “partial.” That is why this is not a panic patch.But it is also not nothing. Browser memory can contain fragments of sensitive state, and modern exploit chains often use information disclosure to weaken mitigations that would otherwise stop a stronger bug. Address-space layout randomization, sandbox boundaries, and renderer isolation all become more useful to attackers when they can learn what memory looks like.
The “crafted HTML page” phrase is also important. This is not a local-only bug requiring shell access or an already-compromised endpoint. It lives in the ordinary web threat model: a user visits or is directed to content that exercises a vulnerable path.
User interaction is part of CISA’s vector, which lowers urgency. But in browser security, “requires user interaction” can simply mean someone has to load a page. That is not much comfort in an enterprise where email, chat, search ads, and compromised websites are all delivery mechanisms.
Dawn Is Where Web Ambition Meets Hardware Reality
Dawn matters because WebGPU matters. Chromium’s graphics stack is increasingly responsible for giving web applications access to capabilities that once belonged mostly to native software: GPU acceleration, compute workloads, advanced rendering, and complex media paths. That expansion is good for web apps, but it enlarges the amount of privileged-ish machinery reachable from a tab.The security bargain is that browsers mediate this access ruthlessly. Web content should get performance without raw hardware trust. When a component like Dawn has an inappropriate implementation issue, the concern is that the mediation layer has leaked something it should have contained.
That does not make WebGPU uniquely reckless. It makes it modern browser engineering. Chrome, Edge, Safari, and Firefox all live with the same strategic pressure: expose more platform power to the web while preserving the illusion that a hostile page is just another page.
CVE-2026-14061 is small in that larger story. It is one information-disclosure bug among hundreds of Chrome fixes in a large stable-channel update. But it is a reminder that browser attack surface is no longer just HTML parsing, JavaScript engines, and old plug-in ghosts; it is also GPU adapters, shader translation, command buffers, and compatibility layers.
CISA’s Medium Score Will Drive More Tickets Than Google’s Low Label
For WindowsForum’s audience, the scoring dispute is not academic. Many enterprise vulnerability systems ingest NVD and CISA-derived CVSS data, not Chromium’s internal severity label. A Chrome bug that Google calls Low can still become a Medium finding in a compliance report if the imported vector says confidentiality impact is high.That is what happened here. CISA’s ADP vector describes network attack vector, low attack complexity, no privileges required, required user interaction, unchanged scope, high confidentiality impact, and no integrity or availability impact. That combination lands at 6.5 under CVSS 3.1.
Security teams should not waste time arguing that Chrome’s “Low” label invalidates the scanner. They should document the vendor rating, the CISA enrichment, and the compensating fact that there is no known exploitation in the submitted SSVC record. Then they should patch Chrome normally and close the finding against the fixed version.
The bigger risk is exception handling. If an organization has a policy that allows low-severity browser findings to sit for weeks, this CVE may slip into the slow lane despite being web-triggerable. Conversely, if every medium browser finding triggers emergency change control, teams will burn cycles on a bug that Google did not treat as a crisis.
The sane middle ground is accelerated routine patching. Chrome’s update cadence is built for this kind of issue, and enterprise policy should be too.
The Scanner May Be Wrong Before the Browser Is
The CPE discrepancy is where administrators should spend their scrutiny. If a scanner says Chrome 150.0.7871.46 is safe for CVE-2026-14061, but the CVE description says versions prior to 150.0.7871.47 are vulnerable, the scanner result deserves challenge. That does not mean the scanner vendor is negligent; it may simply be reflecting NVD’s current structured data.This is the uncomfortable truth of vulnerability management in 2026: structured vulnerability data is not a legal transcript of reality. It is an evolving model assembled from vendor advisories, CNA records, CISA enrichment, NIST analysis, CPE dictionaries, and downstream interpretations. Most of the time it is good enough. At version boundaries, “good enough” can become misleading.
The practical fix is to set the remediation target to Chrome 150.0.7871.47 or later, regardless of whether a feed currently marks 150.0.7871.46 as outside the affected range. That aligns with the CVE description and avoids a needless debate over a single patch build.
If your tooling supports custom overrides, this is a candidate for one. If it does not, the fallback is procedural: note the discrepancy in the ticket, update beyond both disputed thresholds, and verify the browser reports a version at or above 150.0.7871.47.
Chromium Derivatives Need Their Own Receipts
The obvious Windows question is Microsoft Edge. Edge uses Chromium, and Dawn is a Chromium component, so it is reasonable to ask whether Edge is affected. But a Chrome CVE entry does not automatically prove an Edge exposure in a way auditors can act on.Microsoft typically ships Edge security fixes on its own cadence and documents them separately. Administrators managing Edge should check Microsoft’s Edge release notes and security update guidance rather than assuming the Google Chrome CPE applies directly. The same logic holds for Brave, Vivaldi, Opera, and Chromium-based embedded browsers.
This is frustrating but necessary. Chromium is a shared upstream project, while browsers are shipped products. A vulnerability may exist upstream, be fixed upstream, land in Chrome first, and then appear in downstream advisories under different timing or packaging.
Electron deserves a special mention because many desktop apps quietly embed Chromium components. A Chrome browser update does not update every Electron application installed on a fleet. If Dawn-related exposure matters to your threat model, high-risk Electron apps need vendor-specific tracking, not just Chrome patch compliance.
For Windows Admins, the Fix Is Boring by Design
On unmanaged Windows PCs, Chrome should update itself. Users can force the check through Chrome’s About page, but the intended path is automatic update followed by a browser restart. The vulnerable state often persists not because the update failed to download, but because the browser has not been relaunched.In managed environments, Chrome for Enterprise gives administrators policy controls for update timing, relaunch notifications, and target channel behavior. Those controls are useful, but they also create responsibility. A delayed relaunch policy that makes sense for line-of-business continuity can leave browser processes running vulnerable code after the patch is staged.
The simplest verification is still version-based. Inventory should report Chrome 150.0.7871.47 or later for systems where this CVE is in scope. If a scanner says a device is compliant at 150.0.7871.46, security teams should compare that result against the CVE description before closing the ticket.
There is no evidence in the submitted record that this vulnerability is being exploited in the wild. That should keep the response measured. But measured does not mean passive; browser fixes are perishable, and attackers do not need much time to diff patches once they land.
The One-Build Gap Is the Part Worth Remembering
CVE-2026-14061 is not the scariest Chrome bug of the year, but it is a useful test of whether an organization blindly trusts vulnerability metadata or understands it. One version boundary, one severity mismatch, and one low-rated browser component can expose weak seams in patch governance.- Chrome 150.0.7871.47 or later should be treated as the remediation target for CVE-2026-14061.
- The NVD CPE range shown in the submitted change log appears inconsistent with the CVE description because it excludes versions only up to 150.0.7871.46.
- The operating-system CPEs describe affected platforms for Chrome rather than separate Windows, Linux, or macOS vulnerabilities.
- CISA’s Medium CVSS enrichment may cause this issue to appear more urgent in scanners than Chromium’s Low severity label suggests.
- Chromium-based browsers and Electron applications need vendor-specific confirmation rather than assumptions based solely on Google Chrome’s advisory.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:46-07:00
NVD - CVE-2026-14061
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:46-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-14061 - Chrome Dawn Information Disclosure
Inappropriate implementation in Dawn in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low)cvefeed.io