Google fixed CVE-2026-13958 in the June 30, 2026 Chrome 150 stable update for Windows, where versions before 150.0.7871.47 could leak potentially sensitive process memory through a crafted HTML page that exercised Chrome’s codecs component. The bug is rated Medium by Chromium and 6.5 Medium by CISA’s ADP scoring, but its real significance is not the label; it is the way a browser media pipeline flaw becomes an enterprise inventory problem the moment it lands in NVD. The short answer to the CPE question is yes: the NVD entry appears to contain a version-boundary mismatch that defenders should not blindly import into scanners.
That mismatch is easy to miss because the public story looks ordinary at first glance. Google shipped Chrome 150.0.7871.46 for Linux and 150.0.7871.46/.47 for Windows and Mac, while NVD’s description says the Windows vulnerability affects Chrome “prior to 150.0.7871.47.” But NVD’s initial CPE configuration, as shown in the change history, lists Chrome versions up to but excluding 150.0.7871.46, combined with Microsoft Windows. That is the kind of one-build discrepancy that can turn a patched fleet into a false positive factory — or, worse, mark a still-vulnerable Windows browser as clean.
CVE-2026-13958 is not a glamorous zero-day headline. It is a memory disclosure bug in Chrome’s codecs component, categorized as CWE-457, “Use of Uninitialized Variable.” In plain English, some code path in Chrome’s media handling could expose memory that should have been initialized or scrubbed before being read back, and an attacker could trigger the issue with a crafted HTML page.
That matters because browsers are not merely document viewers anymore. Chrome’s media stack is a thicket of decoders, graphics paths, sandbox boundaries, hardware acceleration, third-party libraries, and platform-specific behavior. The attack surface is not a sidebar; it is the modern web.
NVD says the bug is specific to Google Chrome on Windows prior to 150.0.7871.47. CISA’s ADP entry gives it a CVSS 3.1 score of 6.5, with network attack vector, low attack complexity, no privileges required, user interaction required, high confidentiality impact, and no integrity or availability impact. CISA’s SSVC fields, at the time of the entry, say there is no known exploitation, the issue is not automatable, and the technical impact is partial.
That combination gives administrators two simultaneous truths. This is not a “drop everything, assume compromise” bug on the evidence currently public. It is also not a bug to waive away just because the Chromium severity says Medium.
The CVE text says Chrome on Windows before 150.0.7871.47 is affected. Google’s Chrome Releases post says the stable channel was updated to Chrome 150.0.7871.46 on Linux and 150.0.7871.46/.47 on Windows and Mac. Yet NVD’s initial CPE configuration, according to its own change history, added a vulnerable configuration for Google Chrome versions up to but excluding 150.0.7871.46, paired with Microsoft Windows.
That is probably not the intended boundary for a Windows-only issue whose fixed Windows version is described as 150.0.7871.47. If the vulnerability affects Windows prior to 150.0.7871.47, then a Windows machine running 150.0.7871.46 should be treated as potentially vulnerable unless Google or NVD clarifies otherwise. The CPE line excluding 150.0.7871.46 would instead imply that 150.0.7871.46 is fixed, which conflicts with the prose description.
This is not pedantry. Vulnerability scanners do not read prose the way humans do. They consume CPEs, version ranges, package identifiers, platform logic, and vendor advisories. A single “less than” boundary can decide whether a Chrome install is flagged, ignored, escalated, or silently buried in a dashboard.
The safest interpretation for Windows administrators is to follow the vendor-fixed build named in the description: Chrome 150.0.7871.47 or later. If an endpoint is on Windows and still reports Chrome 150.0.7871.46, it should not be considered confidently remediated for CVE-2026-13958 based solely on the current NVD CPE range.
Google’s restriction policy is rational. Publishing exploit-ready detail before the installed base updates would be reckless, particularly for memory safety bugs in a browser used by billions of people. But the same policy forces enterprise defenders to work from sparse text: component name, impact category, severity, affected version, and whatever NVD or CISA can infer.
CVE-2026-13958 lands in the most frustrating part of that spectrum. It is specific enough to be actionable — Windows, Chrome, codecs, memory disclosure, crafted HTML page, fixed in 150.0.7871.47 — but not detailed enough to let defenders independently model exploit reliability, data exposure, or sandbox interaction. The result is a patch-management decision made under deliberate ambiguity.
That is not unusual for Chrome. It is the operating model. Chrome’s update velocity is a security feature, but it also shifts burden onto enterprises that need to test, stage, document, and prove remediation across browsers that are designed to update faster than traditional desktop software governance likes.
But browsers make confidentiality bugs unusually interesting. Process memory can contain tokens, fragments of visited content, cross-origin data, authentication material, document snippets, identifiers, or other state that was never meant to cross a boundary. The CVSS vector’s high confidentiality impact is doing real work here.
A crafted HTML page requirement also should not lull anyone into complacency. The web’s entire business model is getting users to load pages. A malicious ad, compromised site, phishing lure, embedded media flow, or targeted watering-hole page can satisfy that condition without asking the user to download an executable.
There is no public indication in the NVD and CISA data that CVE-2026-13958 is being exploited in the wild. That distinction matters. But “not known exploited” is not the same as “not exploitable,” and Chrome’s own decision to ship the fix as part of a large security release tells administrators what operational response is expected: update.
For Chrome itself, the instruction is clean. Check the installed version and ensure Windows systems are at 150.0.7871.47 or later. For other Chromium-based browsers, the answer is messier and depends on whether the affected code exists, whether it is built the same way, whether platform-specific code paths are involved, and whether the vendor has integrated the upstream fix.
That is where Windows administrators should avoid both extremes. It is wrong to automatically declare every Chromium-based browser vulnerable to every Chrome CVE. It is also wrong to assume that because the advisory says “Google Chrome,” the underlying flaw is irrelevant to Edge, Brave, Vivaldi, Opera, Electron shells, or embedded Chromium runtimes.
The responsible workflow is to track each vendor’s security release notes and Chromium base version. In a Windows fleet, that means Chrome is only the first row in the spreadsheet. Edge Stable and Extended Stable, packaged Chromium runtimes, kiosk browsers, line-of-business applications with embedded webviews, and unmanaged user-installed browsers all deserve scrutiny when the vulnerable component is a common media or rendering subsystem.
The most dangerous scanner output is the one that looks precise. A dashboard that says “not vulnerable” because a CPE expression says “less than 150.0.7871.46” can feel authoritative, even when the advisory prose says the Windows fix is 150.0.7871.47. That is how metadata becomes policy by accident.
For CVE-2026-13958, the observed inconsistency should be treated as a candidate NVD enrichment defect or at least an unresolved ambiguity. The CVE’s own description, the affected-version statement, and Google’s release build split point toward 150.0.7871.47 as the Windows remediation threshold.
This is also why security teams should preserve vendor advisory context in ticketing systems. If all that survives the ingestion pipeline is a CVE number, a CVSS score, and a scanner verdict, the organization loses the ability to catch exactly this kind of mismatch.
For enterprises, the work is less about clicking update and more about proof. Chrome auto-update can be delayed by policy, held back by maintenance windows, interrupted by users who do not restart, or complicated by virtual desktops and nonpersistent images. A browser can download an update and still keep the vulnerable code running until the process restarts.
That distinction matters for incident and vulnerability SLAs. An endpoint inventory tool may report the installed Chrome version after update files land, while the user’s active browser process continues from an older build. The clean remediation signal is not just package version; it is package version plus process restart plus policy confirmation that the browser is no longer pinned below the fixed build.
Administrators should also be alert to the Chrome 150 release’s broader security load. CVE-2026-13958 may be the bug under discussion, but it was shipped among hundreds of fixes. Treating the update as a single Medium vulnerability understates the cumulative security value of moving to the current stable build.
A vulnerability manager sees Medium severity and lets it ride. A scanner follows the NVD CPE boundary and clears Windows systems at 150.0.7871.46. A change board sees “user interaction required” and pushes Chrome updates into a monthly cadence. A browser restart is deferred because no one wants to interrupt a call center shift. Each decision is individually defensible; together, they leave a known browser memory disclosure bug sitting on endpoints after a fix exists.
The better model is to view browser vulnerabilities as a separate patch class. Chrome, Edge, and Firefox are internet-facing runtimes with extremely fast attacker feedback loops. They deserve update expectations closer to endpoint security agents than to ordinary desktop productivity applications.
That does not mean panic-patching every Medium CVE with no testing. It means defaulting to rapid deployment unless there is a demonstrated business-breaking regression. For most Windows fleets, the risk of running an outdated browser build on the open internet exceeds the risk of moving promptly to a vendor-stable browser update.
That precision is especially important because Google’s release line includes different platform build numbers. Linux received 150.0.7871.46, while Windows and Mac received 150.0.7871.46/.47. A cross-platform version shorthand can easily obscure a Windows-only bug whose fixed version is the higher of the two Windows builds.
Windows administrators should therefore make their detection logic explicit. If the platform is Windows and the product is Google Chrome, versions lower than 150.0.7871.47 should remain in scope for remediation until NVD or Google publishes a correction that says otherwise.
This is also a good case for separating detection from reporting severity. A CVSS 6.5 score may influence escalation, but it should not rewrite affected-version logic. The version check is a binary control; the severity score is a prioritization aid.
The useful response is not to distrust NVD. It is to build a habit of triangulation. Vendor advisory first, CVE record second, CISA scoring third, scanner output fourth. When those disagree, the disagreement is the finding.
For this CVE, the disagreement is visible enough to act on. NVD’s prose and Google’s release notes point to Chrome 150.0.7871.47 as the Windows fix, while the CPE range shown in the change history appears to stop one build too early. That should be reported to NVD if it has not already been corrected, and local scanner logic should be adjusted in the meantime.
There is a broader cultural point here as well. Security operations teams often treat vulnerability data as if it were a settled database problem. In reality, it is journalism with schemas: partial facts, late edits, source hierarchy, conflicting descriptions, and a need to preserve chronology.
That mismatch is easy to miss because the public story looks ordinary at first glance. Google shipped Chrome 150.0.7871.46 for Linux and 150.0.7871.46/.47 for Windows and Mac, while NVD’s description says the Windows vulnerability affects Chrome “prior to 150.0.7871.47.” But NVD’s initial CPE configuration, as shown in the change history, lists Chrome versions up to but excluding 150.0.7871.46, combined with Microsoft Windows. That is the kind of one-build discrepancy that can turn a patched fleet into a false positive factory — or, worse, mark a still-vulnerable Windows browser as clean.
A Medium Chrome Bug Becomes a Windows Asset-Management Test
CVE-2026-13958 is not a glamorous zero-day headline. It is a memory disclosure bug in Chrome’s codecs component, categorized as CWE-457, “Use of Uninitialized Variable.” In plain English, some code path in Chrome’s media handling could expose memory that should have been initialized or scrubbed before being read back, and an attacker could trigger the issue with a crafted HTML page.That matters because browsers are not merely document viewers anymore. Chrome’s media stack is a thicket of decoders, graphics paths, sandbox boundaries, hardware acceleration, third-party libraries, and platform-specific behavior. The attack surface is not a sidebar; it is the modern web.
NVD says the bug is specific to Google Chrome on Windows prior to 150.0.7871.47. CISA’s ADP entry gives it a CVSS 3.1 score of 6.5, with network attack vector, low attack complexity, no privileges required, user interaction required, high confidentiality impact, and no integrity or availability impact. CISA’s SSVC fields, at the time of the entry, say there is no known exploitation, the issue is not automatable, and the technical impact is partial.
That combination gives administrators two simultaneous truths. This is not a “drop everything, assume compromise” bug on the evidence currently public. It is also not a bug to waive away just because the Chromium severity says Medium.
The CPE Boundary Is the Story Hiding in the Metadata
The awkward part is not the vulnerability description. It is the affected-product metadata.The CVE text says Chrome on Windows before 150.0.7871.47 is affected. Google’s Chrome Releases post says the stable channel was updated to Chrome 150.0.7871.46 on Linux and 150.0.7871.46/.47 on Windows and Mac. Yet NVD’s initial CPE configuration, according to its own change history, added a vulnerable configuration for Google Chrome versions up to but excluding 150.0.7871.46, paired with Microsoft Windows.
That is probably not the intended boundary for a Windows-only issue whose fixed Windows version is described as 150.0.7871.47. If the vulnerability affects Windows prior to 150.0.7871.47, then a Windows machine running 150.0.7871.46 should be treated as potentially vulnerable unless Google or NVD clarifies otherwise. The CPE line excluding 150.0.7871.46 would instead imply that 150.0.7871.46 is fixed, which conflicts with the prose description.
This is not pedantry. Vulnerability scanners do not read prose the way humans do. They consume CPEs, version ranges, package identifiers, platform logic, and vendor advisories. A single “less than” boundary can decide whether a Chrome install is flagged, ignored, escalated, or silently buried in a dashboard.
The safest interpretation for Windows administrators is to follow the vendor-fixed build named in the description: Chrome 150.0.7871.47 or later. If an endpoint is on Windows and still reports Chrome 150.0.7871.46, it should not be considered confidently remediated for CVE-2026-13958 based solely on the current NVD CPE range.
Google’s 433-Fix Release Makes One Bug Harder to Read
The Chrome 150 stable update was not a neat one-CVE patch. Google’s release notes say the desktop update included 433 security fixes, with a long list of Critical, High, Medium, and lower-severity issues. That scale makes individual bugs harder for defenders to reason about, especially when many Chromium issue tracker links remain restricted until most users have received fixes.Google’s restriction policy is rational. Publishing exploit-ready detail before the installed base updates would be reckless, particularly for memory safety bugs in a browser used by billions of people. But the same policy forces enterprise defenders to work from sparse text: component name, impact category, severity, affected version, and whatever NVD or CISA can infer.
CVE-2026-13958 lands in the most frustrating part of that spectrum. It is specific enough to be actionable — Windows, Chrome, codecs, memory disclosure, crafted HTML page, fixed in 150.0.7871.47 — but not detailed enough to let defenders independently model exploit reliability, data exposure, or sandbox interaction. The result is a patch-management decision made under deliberate ambiguity.
That is not unusual for Chrome. It is the operating model. Chrome’s update velocity is a security feature, but it also shifts burden onto enterprises that need to test, stage, document, and prove remediation across browsers that are designed to update faster than traditional desktop software governance likes.
Memory Disclosure Is Not Remote Code Execution, But It Is Not Harmless
Security teams often triage memory disclosure below code execution, privilege escalation, and sandbox escape. That instinct is understandable. A confidentiality-only bug with user interaction required does not have the same immediate blast radius as a reliable remote code execution flaw.But browsers make confidentiality bugs unusually interesting. Process memory can contain tokens, fragments of visited content, cross-origin data, authentication material, document snippets, identifiers, or other state that was never meant to cross a boundary. The CVSS vector’s high confidentiality impact is doing real work here.
A crafted HTML page requirement also should not lull anyone into complacency. The web’s entire business model is getting users to load pages. A malicious ad, compromised site, phishing lure, embedded media flow, or targeted watering-hole page can satisfy that condition without asking the user to download an executable.
There is no public indication in the NVD and CISA data that CVE-2026-13958 is being exploited in the wild. That distinction matters. But “not known exploited” is not the same as “not exploitable,” and Chrome’s own decision to ship the fix as part of a large security release tells administrators what operational response is expected: update.
Windows Specificity Raises the Stakes for Edge-Watching Shops
The user-visible CVE names Google Chrome, not Microsoft Edge. Still, WindowsForum readers know the practical complication: Chromium vulnerabilities often ripple through the broader Chromium ecosystem, even when the product advisories and version numbers do not map one-to-one.For Chrome itself, the instruction is clean. Check the installed version and ensure Windows systems are at 150.0.7871.47 or later. For other Chromium-based browsers, the answer is messier and depends on whether the affected code exists, whether it is built the same way, whether platform-specific code paths are involved, and whether the vendor has integrated the upstream fix.
That is where Windows administrators should avoid both extremes. It is wrong to automatically declare every Chromium-based browser vulnerable to every Chrome CVE. It is also wrong to assume that because the advisory says “Google Chrome,” the underlying flaw is irrelevant to Edge, Brave, Vivaldi, Opera, Electron shells, or embedded Chromium runtimes.
The responsible workflow is to track each vendor’s security release notes and Chromium base version. In a Windows fleet, that means Chrome is only the first row in the spreadsheet. Edge Stable and Extended Stable, packaged Chromium runtimes, kiosk browsers, line-of-business applications with embedded webviews, and unmanaged user-installed browsers all deserve scrutiny when the vulnerable component is a common media or rendering subsystem.
NVD Is a Feed, Not an Oracle
The CPE issue in CVE-2026-13958 is a reminder that NVD is indispensable but not infallible. NVD enrichment is a human and automated interpretation layer over vendor disclosures, CNA submissions, CISA ADP scoring, and public references. It is extremely useful because it normalizes chaos. It is also capable of lag, ambiguity, and occasional off-by-one version logic.The most dangerous scanner output is the one that looks precise. A dashboard that says “not vulnerable” because a CPE expression says “less than 150.0.7871.46” can feel authoritative, even when the advisory prose says the Windows fix is 150.0.7871.47. That is how metadata becomes policy by accident.
For CVE-2026-13958, the observed inconsistency should be treated as a candidate NVD enrichment defect or at least an unresolved ambiguity. The CVE’s own description, the affected-version statement, and Google’s release build split point toward 150.0.7871.47 as the Windows remediation threshold.
This is also why security teams should preserve vendor advisory context in ticketing systems. If all that survives the ingestion pipeline is a CVE number, a CVSS score, and a scanner verdict, the organization loses the ability to catch exactly this kind of mismatch.
The Patch Is Simple; Proving the Patch Is the Work
For a home user, the fix is boring in the best possible way. Open Chrome’s About page, let it update, and restart the browser. If the version is 150.0.7871.47 or later on Windows, CVE-2026-13958 should be addressed for Chrome.For enterprises, the work is less about clicking update and more about proof. Chrome auto-update can be delayed by policy, held back by maintenance windows, interrupted by users who do not restart, or complicated by virtual desktops and nonpersistent images. A browser can download an update and still keep the vulnerable code running until the process restarts.
That distinction matters for incident and vulnerability SLAs. An endpoint inventory tool may report the installed Chrome version after update files land, while the user’s active browser process continues from an older build. The clean remediation signal is not just package version; it is package version plus process restart plus policy confirmation that the browser is no longer pinned below the fixed build.
Administrators should also be alert to the Chrome 150 release’s broader security load. CVE-2026-13958 may be the bug under discussion, but it was shipped among hundreds of fixes. Treating the update as a single Medium vulnerability understates the cumulative security value of moving to the current stable build.
The Real Risk Is Misclassification
The most likely failure mode here is not a mass exploitation wave against this one CVE. It is misclassification.A vulnerability manager sees Medium severity and lets it ride. A scanner follows the NVD CPE boundary and clears Windows systems at 150.0.7871.46. A change board sees “user interaction required” and pushes Chrome updates into a monthly cadence. A browser restart is deferred because no one wants to interrupt a call center shift. Each decision is individually defensible; together, they leave a known browser memory disclosure bug sitting on endpoints after a fix exists.
The better model is to view browser vulnerabilities as a separate patch class. Chrome, Edge, and Firefox are internet-facing runtimes with extremely fast attacker feedback loops. They deserve update expectations closer to endpoint security agents than to ordinary desktop productivity applications.
That does not mean panic-patching every Medium CVE with no testing. It means defaulting to rapid deployment unless there is a demonstrated business-breaking regression. For most Windows fleets, the risk of running an outdated browser build on the open internet exceeds the risk of moving promptly to a vendor-stable browser update.
The Version Number Is the Control
The practical takeaway from CVE-2026-13958 is not complicated, but it has to be stated with version precision. The remediation target for Google Chrome on Windows should be 150.0.7871.47 or later, not merely “Chrome 150” and not a scanner-derived threshold that stops at 150.0.7871.46.That precision is especially important because Google’s release line includes different platform build numbers. Linux received 150.0.7871.46, while Windows and Mac received 150.0.7871.46/.47. A cross-platform version shorthand can easily obscure a Windows-only bug whose fixed version is the higher of the two Windows builds.
Windows administrators should therefore make their detection logic explicit. If the platform is Windows and the product is Google Chrome, versions lower than 150.0.7871.47 should remain in scope for remediation until NVD or Google publishes a correction that says otherwise.
This is also a good case for separating detection from reporting severity. A CVSS 6.5 score may influence escalation, but it should not rewrite affected-version logic. The version check is a binary control; the severity score is a prioritization aid.
The Lesson Windows Shops Should Take From One Bad Boundary
CVE-2026-13958 is a small bug with a large administrative lesson: the browser patch pipeline is now too fast, too platform-specific, and too metadata-dependent for organizations to run on autopilot. One version-boundary mismatch can propagate through scanners, tickets, compliance reports, and exception workflows before anyone reads the original advisory.The useful response is not to distrust NVD. It is to build a habit of triangulation. Vendor advisory first, CVE record second, CISA scoring third, scanner output fourth. When those disagree, the disagreement is the finding.
For this CVE, the disagreement is visible enough to act on. NVD’s prose and Google’s release notes point to Chrome 150.0.7871.47 as the Windows fix, while the CPE range shown in the change history appears to stop one build too early. That should be reported to NVD if it has not already been corrected, and local scanner logic should be adjusted in the meantime.
There is a broader cultural point here as well. Security operations teams often treat vulnerability data as if it were a settled database problem. In reality, it is journalism with schemas: partial facts, late edits, source hierarchy, conflicting descriptions, and a need to preserve chronology.
Chrome 150 Turns a Medium CVE Into a Fleet Hygiene Check
The concrete response is short, but the discipline behind it is what separates a patched fleet from a merely well-scanned one.- Windows systems running Google Chrome should be updated to 150.0.7871.47 or later for CVE-2026-13958.
- Chrome 150.0.7871.46 on Windows should not be assumed fixed for this CVE while the public description says the vulnerable range is prior to 150.0.7871.47.
- NVD’s CPE configuration appears inconsistent with the CVE description and Google’s platform-specific release numbering.
- The bug is a Medium-severity confidentiality issue, not a known exploited zero-day based on the public CISA and NVD data currently available.
- Browser restart status matters because downloaded updates do not always mean the vulnerable browser process has exited.
- Chromium-based browsers beyond Chrome should be checked against their own vendor advisories rather than cleared by assumption.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:04-07:00
NVD - CVE-2026-13958
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:04-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-13958 - Google Chrome Heap Buffer Overflow
Uninitialized Use in Codecs in Google Chrome on Windows 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: Medium)cvefeed.io