Google patched CVE-2026-14055 in Chrome 150.0.7871.47 for Windows on June 30, 2026, after documenting an input-validation flaw in Chrome’s Device Trust component that could let an attacker who had already compromised the renderer attempt a sandbox escape through a crafted HTML page. The awkward part is not that Chrome had another bug; Chrome always has another bug. The awkward part is that Google’s “Low” Chromium severity now sits beside a CISA-ADP CVSS 3.1 score of 9.6 Critical in the National Vulnerability Database, creating exactly the kind of risk-label whiplash that turns patch management into argument management.
The answer for Windows users is simple: update Chrome. The answer for administrators is more interesting: treat this as a Windows-scoped Chrome sandbox boundary issue, not as a generic browser nuisance, and do not let the “Low” label lull you into waiting for the next maintenance window. As Google’s Chrome Releases blog noted in its June 30 Stable Channel update, Chrome 150 shipped with hundreds of security fixes, and CVE-2026-14055 is one small line item in a very large release. As NVD’s change history shows, however, small line items can become big operational questions once enrichment, CPE modeling, and third-party scoring collide.
CVE-2026-14055 lives in the narrow space security teams hate most: the bug is not described as an initial code-execution vulnerability, but as a possible way to escape Chrome’s sandbox after the renderer has already been compromised. That distinction matters technically, because an attacker needs another step first. It also matters politically, because it allows a vendor severity rating to sound reassuring while the practical exploit chain remains ugly.
Chrome’s renderer sandbox is supposed to make web compromise survivable. A browser renderer is exposed to hostile content all day; the sandbox is the wall that keeps a malicious page from immediately becoming a local-machine incident. A bug that helps cross that wall may not be the first domino, but it can be the domino that changes the incident from “tab contained” to “endpoint exposed.”
That is why the NVD page reads like two different risk systems talking past each other. Google’s description tags the Chromium security severity as Low, while CISA-ADP adds a CVSS 3.1 vector of network attack complexity low, no privileges required, user interaction required, changed scope, and high impact across confidentiality, integrity, and availability. Those values produce the 9.6 Critical score visible in NVD, even though NVD itself had not yet supplied its own assessment at the time of the record shown by the user.
This is not necessarily evidence that one party is “wrong.” Vendor severity and CVSS often answer different questions. Google is likely weighting exploit preconditions and Chrome-internal assumptions; CVSS is scoring the consequences once the stated attack conditions are met. For defenders, the safest reading is that CVE-2026-14055 is a low-friction patch with high downside if paired with a renderer exploit.
That makes input validation bugs in this area more interesting than their bland CWE label suggests. “Improper Input Validation” is one of those taxonomy phrases that can hide everything from tedious edge-case handling to an unexpectedly powerful trust-boundary mistake. In this case, the CVE says untrusted input in Device Trust could, after renderer compromise, contribute to a sandbox escape on Windows.
The Windows qualifier matters. NVD’s reanalysis changed the affected configuration from just Chrome versions before 150.0.7871.47 to a modeled combination of Chrome plus Microsoft Windows. That is a meaningful correction, not a clerical footnote. It tells scanners and inventory systems that this CVE should not be treated as equally applicable to every operating system where Chrome exists.
For mixed fleets, that difference affects prioritization. A Linux desktop running Chrome 150.0.7871.46 may be part of the same June 30 Chrome 150 release family, but CVE-2026-14055 as described by Chrome and NVD is a Windows issue. Conversely, a Windows endpoint still sitting below 150.0.7871.47 remains in scope even if other platforms have been remediated or never affected in the same way.
The reason this matters is not academic. Vulnerability scanners, SBOM systems, asset inventory products, and ticketing workflows often consume CPE configurations mechanically. A Chrome-only CPE can light up every desktop, server jump box, virtual app environment, and non-Windows system that happens to report a Chrome version. A Chrome-plus-Windows CPE narrows the blast radius to the systems that match the actual CVE description.
This is also why the NVD banner saying the record was “Modified After Enrichment” deserves attention. Enrichment is supposed to add structure around a CVE record, but it can lag behind late vendor edits or initially model a configuration too broadly. NVD’s own change history shows exactly that sequence: initial analysis added Chrome as affected, then reanalysis added the Windows operating-system condition and removed the simpler Chrome-only configuration.
For administrators, the practical takeaway is that a scanner result for CVE-2026-14055 should be checked for platform logic before it becomes a compliance fire drill. If your tool still flags macOS or Linux Chrome installations solely because they are below 150.0.7871.47, it may be using stale or overly broad enrichment data. If it ignores Windows context entirely, it may miss the reason this CVE is distinct from the rest of Chrome 150’s pile of fixes.
The measured response is to patch quickly because Chrome updates are cheap, browser exposure is constant, and sandbox escapes are valuable in exploit chains. But the measured response is also to avoid treating this as confirmed active exploitation. The CISA SSVC data shown in NVD lists exploitation as none, automatable as no, and technical impact as total. That combination says, in effect, “not known to be exploited, not easily automated, but severe if successfully chained.”
That is exactly the kind of nuance many dashboards flatten into a red square. A risk committee sees 9.6 Critical and asks why the patch is not complete. A workstation team sees Chromium Low and asks why anyone is interrupting their release cadence. The right answer is that browser sandbox escapes are rarely judged well by a single label.
Chrome’s own advisory language also keeps details restricted until most users have updated, which is standard practice for browser vulnerabilities. That restriction protects users, but it leaves defenders reasoning from sparse metadata: component name, platform, affected version, severity, CVSS vector, and whether exploitation is known. In that information vacuum, the most defensible policy is fast update verification rather than speculative exploit analysis.
The problem with mega-updates is that they dilute attention. A critical use-after-free in one component, a high-severity ANGLE issue, a permissions bug, a spoofing flaw, and a low-severity sandbox-adjacent issue all arrive in the same package. Administrators do not patch one CVE; they patch the browser build. But vulnerability-management systems often explode that one build into hundreds of tickets.
This is where desktop engineering maturity shows. Organizations that manage Chrome through policy, enterprise update controls, Intune, Configuration Manager, third-party patching, or browser management tooling should be validating build uptake rather than debating each CVE in isolation. The question is not whether CVE-2026-14055 alone justifies the release. The question is whether any Windows endpoint with Chrome below 150.0.7871.47 should remain exposed after Google has shipped the fix.
For home users, the advice is simpler. Open Chrome’s About page, let it check for updates, and relaunch when prompted. Chrome’s auto-update machinery usually handles this quietly, but browser updates often remain pending until the application restarts. A patched binary that has not been relaunched is not a patched browsing session.
Privileged access workstations deserve special attention. A renderer compromise chained with a sandbox escape is far more concerning on a machine used to administer cloud consoles, identity systems, hypervisors, or production environments. The browser has become the control plane for almost everything, and the Windows desktop running it is often the soft underbelly of otherwise hardened infrastructure.
There is also a compliance angle. If a scanner ingests the corrected CPE logic, Windows Chrome versions below 150.0.7871.47 should remain in scope while non-Windows instances should not be marked for this specific CVE. If a scanner has not updated its enrichment data, the vulnerability team may need to suppress false positives or annotate them until the feed catches up. That is not gaming the system; it is aligning remediation with the actual affected configuration.
Still, suppression should not become procrastination. Chrome 150 contains a large security payload beyond this single CVE, and Chromium-based browsers tend to share code paths even when version numbers and release timing differ. Microsoft Edge, Brave, Vivaldi, Opera, and other Chromium derivatives require their own vendor updates and advisories, not assumptions based on Google Chrome’s build number alone.
That is why sandbox escapes are prized by advanced attackers. A renderer bug by itself may be noisy, constrained, or difficult to monetize. Pair it with a sandbox escape and the exploit chain becomes more useful. Pair that with credential theft, token abuse, or a local privilege escalation and the browser becomes a beachhead.
Nothing in the public record says CVE-2026-14055 is being exploited in the wild. NVD’s displayed CISA SSVC entry says exploitation is none. But the absence of known exploitation is not the same as safety, particularly when bug details are restricted and the component touches device trust decisions. Attackers read release notes too, and patch diffs have a way of turning yesterday’s vague advisory into tomorrow’s proof of concept.
For defenders, this argues for reducing dwell time below the vulnerable build. The best browser vulnerability is the one that ages out before exploit developers can operationalize it. Chrome’s rapid update model only works if organizations allow the rapid part to happen.
That is the public vulnerability ecosystem doing what it is supposed to do, but not instantaneously. CVE records are living documents. Enrichment systems add structure, automated consumers ingest it, vendors refine details, and downstream tools sometimes freeze the first version they saw. The phrase “Modified After Enrichment” is a warning that the structured data may need another look.
This is especially important for CPEs because they are both precise and brittle. A single missing operating-system condition can make a vulnerability look universal. A mistaken version boundary can hide affected assets. A scanner UI may show “Chrome before 150.0.7871.47” without making the Windows dependency obvious to the person approving exceptions.
The lesson is not that NVD is unreliable. The lesson is that NVD is not a substitute for reading the vendor description and change history when a CVE looks odd. In this case, the corrected CPE appears to match the English description: Chrome on Windows before 150.0.7871.47. That is the version of the record defenders should use.
But browser exploit chains are built exactly this way. One vulnerability gets code running in a renderer. Another vulnerability escapes the sandbox. A third weakness elevates privileges or steals tokens. Security teams that dismiss each link because it is “only useful after another bug” are missing how modern exploitation works.
The crafted HTML page detail is also worth parsing carefully. It means the delivery mechanism is web content, with user interaction required under the CISA vector. It does not mean the user must download and run a file, disable a security setting, or authenticate to the attacker. In ordinary enterprise life, getting a user to load a page remains one of the lowest bars in offensive security.
That is why the remediation priority should be higher than the vendor severity label alone suggests. Not panic. Not all-hands emergency. But prompt, verified deployment across Windows Chrome installations, especially where users handle sensitive systems or high-value sessions.
Administrators should verify both installed version and active process version. It is common to see Chrome updated on disk while old browser processes continue running until the user restarts. In managed environments, that may require restart prompts, forced relaunch windows, or policy-driven update deadlines. Browser uptime is now a security variable.
Teams should also check whether Chrome is installed outside the expected management path. User-level installs, stale golden images, lab machines, developer workstations, and unmanaged subsidiaries are where browser patch compliance goes to die. If Chrome exists on Windows, it should either be managed or removed.
For organizations using Device Trust or related access controls, the event should prompt a narrower review. Confirm Chrome policy posture, enterprise connector configuration, browser enrollment, and endpoint compliance signals. A vulnerability in a trust-adjacent component does not automatically mean those systems were bypassed, but it is a useful reminder that the browser has become part of the identity perimeter.
The answer for Windows users is simple: update Chrome. The answer for administrators is more interesting: treat this as a Windows-scoped Chrome sandbox boundary issue, not as a generic browser nuisance, and do not let the “Low” label lull you into waiting for the next maintenance window. As Google’s Chrome Releases blog noted in its June 30 Stable Channel update, Chrome 150 shipped with hundreds of security fixes, and CVE-2026-14055 is one small line item in a very large release. As NVD’s change history shows, however, small line items can become big operational questions once enrichment, CPE modeling, and third-party scoring collide.
A Low-Severity Chrome Bug With High-Severity Consequences
CVE-2026-14055 lives in the narrow space security teams hate most: the bug is not described as an initial code-execution vulnerability, but as a possible way to escape Chrome’s sandbox after the renderer has already been compromised. That distinction matters technically, because an attacker needs another step first. It also matters politically, because it allows a vendor severity rating to sound reassuring while the practical exploit chain remains ugly.Chrome’s renderer sandbox is supposed to make web compromise survivable. A browser renderer is exposed to hostile content all day; the sandbox is the wall that keeps a malicious page from immediately becoming a local-machine incident. A bug that helps cross that wall may not be the first domino, but it can be the domino that changes the incident from “tab contained” to “endpoint exposed.”
That is why the NVD page reads like two different risk systems talking past each other. Google’s description tags the Chromium security severity as Low, while CISA-ADP adds a CVSS 3.1 vector of network attack complexity low, no privileges required, user interaction required, changed scope, and high impact across confidentiality, integrity, and availability. Those values produce the 9.6 Critical score visible in NVD, even though NVD itself had not yet supplied its own assessment at the time of the record shown by the user.
This is not necessarily evidence that one party is “wrong.” Vendor severity and CVSS often answer different questions. Google is likely weighting exploit preconditions and Chrome-internal assumptions; CVSS is scoring the consequences once the stated attack conditions are met. For defenders, the safest reading is that CVE-2026-14055 is a low-friction patch with high downside if paired with a renderer exploit.
Device Trust Turns Browser Security Into Enterprise Security
The vulnerable component named in the CVE is Device Trust, which is precisely why Windows administrators should pay attention. Device trust features exist to help organizations make access decisions based not only on who the user is, but on what device is making the request. In modern enterprise architecture, that browser-to-device posture bridge is no longer a side feature; it is part of how identity, endpoint state, and application access get stitched together.That makes input validation bugs in this area more interesting than their bland CWE label suggests. “Improper Input Validation” is one of those taxonomy phrases that can hide everything from tedious edge-case handling to an unexpectedly powerful trust-boundary mistake. In this case, the CVE says untrusted input in Device Trust could, after renderer compromise, contribute to a sandbox escape on Windows.
The Windows qualifier matters. NVD’s reanalysis changed the affected configuration from just Chrome versions before 150.0.7871.47 to a modeled combination of Chrome plus Microsoft Windows. That is a meaningful correction, not a clerical footnote. It tells scanners and inventory systems that this CVE should not be treated as equally applicable to every operating system where Chrome exists.
For mixed fleets, that difference affects prioritization. A Linux desktop running Chrome 150.0.7871.46 may be part of the same June 30 Chrome 150 release family, but CVE-2026-14055 as described by Chrome and NVD is a Windows issue. Conversely, a Windows endpoint still sitting below 150.0.7871.47 remains in scope even if other platforms have been remediated or never affected in the same way.
The CPE Change Is the Quiet Part That Breaks Dashboards
The user’s instinct about the CPE is right: the important change is that NVD moved from a broad Chrome-only configuration to a more precise Chrome-on-Windows configuration. In CPE terms, that means the vulnerability is represented as an AND relationship: vulnerable Google Chrome versions up to, but excluding, 150.0.7871.47, combined with Microsoft Windows. That is the correct shape for a platform-specific Chrome vulnerability.The reason this matters is not academic. Vulnerability scanners, SBOM systems, asset inventory products, and ticketing workflows often consume CPE configurations mechanically. A Chrome-only CPE can light up every desktop, server jump box, virtual app environment, and non-Windows system that happens to report a Chrome version. A Chrome-plus-Windows CPE narrows the blast radius to the systems that match the actual CVE description.
This is also why the NVD banner saying the record was “Modified After Enrichment” deserves attention. Enrichment is supposed to add structure around a CVE record, but it can lag behind late vendor edits or initially model a configuration too broadly. NVD’s own change history shows exactly that sequence: initial analysis added Chrome as affected, then reanalysis added the Windows operating-system condition and removed the simpler Chrome-only configuration.
For administrators, the practical takeaway is that a scanner result for CVE-2026-14055 should be checked for platform logic before it becomes a compliance fire drill. If your tool still flags macOS or Linux Chrome installations solely because they are below 150.0.7871.47, it may be using stale or overly broad enrichment data. If it ignores Windows context entirely, it may miss the reason this CVE is distinct from the rest of Chrome 150’s pile of fixes.
The Severity Split Is a Patch-Management Trap
Security teams have become fluent in vendor understatement and scanner overstatement, but this CVE is a clean example of why both can be dangerous. Google’s Low rating could encourage a desktop team to defer the update. CISA-ADP’s Critical score could encourage a governance team to demand emergency action without understanding exploit preconditions. Neither reaction is quite right.The measured response is to patch quickly because Chrome updates are cheap, browser exposure is constant, and sandbox escapes are valuable in exploit chains. But the measured response is also to avoid treating this as confirmed active exploitation. The CISA SSVC data shown in NVD lists exploitation as none, automatable as no, and technical impact as total. That combination says, in effect, “not known to be exploited, not easily automated, but severe if successfully chained.”
That is exactly the kind of nuance many dashboards flatten into a red square. A risk committee sees 9.6 Critical and asks why the patch is not complete. A workstation team sees Chromium Low and asks why anyone is interrupting their release cadence. The right answer is that browser sandbox escapes are rarely judged well by a single label.
Chrome’s own advisory language also keeps details restricted until most users have updated, which is standard practice for browser vulnerabilities. That restriction protects users, but it leaves defenders reasoning from sparse metadata: component name, platform, affected version, severity, CVSS vector, and whether exploitation is known. In that information vacuum, the most defensible policy is fast update verification rather than speculative exploit analysis.
Chrome 150’s Scale Makes Single-CVE Triage Harder
The June 30 Chrome 150 Stable Channel update was not a tidy one-bug emergency release. Google said the release included 433 security fixes, with Windows and Mac moving to 150.0.7871.46/.47 and Linux to 150.0.7871.46. That scale changes the operational story: CVE-2026-14055 is not the only reason to deploy the release, and it may not even be the scariest line item in the full advisory.The problem with mega-updates is that they dilute attention. A critical use-after-free in one component, a high-severity ANGLE issue, a permissions bug, a spoofing flaw, and a low-severity sandbox-adjacent issue all arrive in the same package. Administrators do not patch one CVE; they patch the browser build. But vulnerability-management systems often explode that one build into hundreds of tickets.
This is where desktop engineering maturity shows. Organizations that manage Chrome through policy, enterprise update controls, Intune, Configuration Manager, third-party patching, or browser management tooling should be validating build uptake rather than debating each CVE in isolation. The question is not whether CVE-2026-14055 alone justifies the release. The question is whether any Windows endpoint with Chrome below 150.0.7871.47 should remain exposed after Google has shipped the fix.
For home users, the advice is simpler. Open Chrome’s About page, let it check for updates, and relaunch when prompted. Chrome’s auto-update machinery usually handles this quietly, but browser updates often remain pending until the application restarts. A patched binary that has not been relaunched is not a patched browsing session.
The Windows Boundary Is the Story for Admins
Because CVE-2026-14055 is Windows-specific in the published description, enterprise administrators should think in terms of Windows endpoint exposure rather than Chrome brand exposure. That includes laptops, shared workstations, VDI pools, privileged admin workstations, kiosk devices, and any Windows server where Chrome is installed for convenience despite policy saying it probably should not be.Privileged access workstations deserve special attention. A renderer compromise chained with a sandbox escape is far more concerning on a machine used to administer cloud consoles, identity systems, hypervisors, or production environments. The browser has become the control plane for almost everything, and the Windows desktop running it is often the soft underbelly of otherwise hardened infrastructure.
There is also a compliance angle. If a scanner ingests the corrected CPE logic, Windows Chrome versions below 150.0.7871.47 should remain in scope while non-Windows instances should not be marked for this specific CVE. If a scanner has not updated its enrichment data, the vulnerability team may need to suppress false positives or annotate them until the feed catches up. That is not gaming the system; it is aligning remediation with the actual affected configuration.
Still, suppression should not become procrastination. Chrome 150 contains a large security payload beyond this single CVE, and Chromium-based browsers tend to share code paths even when version numbers and release timing differ. Microsoft Edge, Brave, Vivaldi, Opera, and other Chromium derivatives require their own vendor updates and advisories, not assumptions based on Google Chrome’s build number alone.
The Browser Sandbox Remains a High-Value Target
The web security model has always relied on layers. A malicious page should not get arbitrary renderer execution; if it does, the renderer should not escape; if it escapes, the operating system should still limit damage; if the endpoint is touched, EDR and identity controls should notice. CVE-2026-14055 sits in the second layer, where browser compromise tries to become system compromise.That is why sandbox escapes are prized by advanced attackers. A renderer bug by itself may be noisy, constrained, or difficult to monetize. Pair it with a sandbox escape and the exploit chain becomes more useful. Pair that with credential theft, token abuse, or a local privilege escalation and the browser becomes a beachhead.
Nothing in the public record says CVE-2026-14055 is being exploited in the wild. NVD’s displayed CISA SSVC entry says exploitation is none. But the absence of known exploitation is not the same as safety, particularly when bug details are restricted and the component touches device trust decisions. Attackers read release notes too, and patch diffs have a way of turning yesterday’s vague advisory into tomorrow’s proof of concept.
For defenders, this argues for reducing dwell time below the vulnerable build. The best browser vulnerability is the one that ages out before exploit developers can operationalize it. Chrome’s rapid update model only works if organizations allow the rapid part to happen.
The NVD Record Shows Why Enrichment Is Not Gospel
The CVE record’s change history is unusually useful because it exposes the machinery behind the vulnerability database. Chrome supplied the CVE on June 30. CISA-ADP added a CVSS score and SSVC data on July 1. NVD initially modeled the affected product as Chrome before reanalyzing the configuration to include Windows as an operating-system condition.That is the public vulnerability ecosystem doing what it is supposed to do, but not instantaneously. CVE records are living documents. Enrichment systems add structure, automated consumers ingest it, vendors refine details, and downstream tools sometimes freeze the first version they saw. The phrase “Modified After Enrichment” is a warning that the structured data may need another look.
This is especially important for CPEs because they are both precise and brittle. A single missing operating-system condition can make a vulnerability look universal. A mistaken version boundary can hide affected assets. A scanner UI may show “Chrome before 150.0.7871.47” without making the Windows dependency obvious to the person approving exceptions.
The lesson is not that NVD is unreliable. The lesson is that NVD is not a substitute for reading the vendor description and change history when a CVE looks odd. In this case, the corrected CPE appears to match the English description: Chrome on Windows before 150.0.7871.47. That is the version of the record defenders should use.
The Real Risk Is the Chain, Not the Standalone Bug
CVE-2026-14055 should not be sold as a one-click remote takeover of every Windows machine running Chrome. The public description says the attacker must have already compromised the renderer process. That condition is not trivial, and it is likely one reason Chromium rated the bug Low.But browser exploit chains are built exactly this way. One vulnerability gets code running in a renderer. Another vulnerability escapes the sandbox. A third weakness elevates privileges or steals tokens. Security teams that dismiss each link because it is “only useful after another bug” are missing how modern exploitation works.
The crafted HTML page detail is also worth parsing carefully. It means the delivery mechanism is web content, with user interaction required under the CISA vector. It does not mean the user must download and run a file, disable a security setting, or authenticate to the attacker. In ordinary enterprise life, getting a user to load a page remains one of the lowest bars in offensive security.
That is why the remediation priority should be higher than the vendor severity label alone suggests. Not panic. Not all-hands emergency. But prompt, verified deployment across Windows Chrome installations, especially where users handle sensitive systems or high-value sessions.
The Patch Is Boring, Which Is Exactly the Point
The fix is to run Chrome 150.0.7871.47 or later on Windows. That statement is almost disappointingly mundane, but mundane fixes are the backbone of endpoint security. The drama belongs in the scoring dispute; the operational task is to get the fixed build installed and relaunched.Administrators should verify both installed version and active process version. It is common to see Chrome updated on disk while old browser processes continue running until the user restarts. In managed environments, that may require restart prompts, forced relaunch windows, or policy-driven update deadlines. Browser uptime is now a security variable.
Teams should also check whether Chrome is installed outside the expected management path. User-level installs, stale golden images, lab machines, developer workstations, and unmanaged subsidiaries are where browser patch compliance goes to die. If Chrome exists on Windows, it should either be managed or removed.
For organizations using Device Trust or related access controls, the event should prompt a narrower review. Confirm Chrome policy posture, enterprise connector configuration, browser enrollment, and endpoint compliance signals. A vulnerability in a trust-adjacent component does not automatically mean those systems were bypassed, but it is a useful reminder that the browser has become part of the identity perimeter.
This One CVE Teaches More Than Its Severity Label
The concrete action is straightforward, but the larger lesson is about how to read modern browser advisories without being trapped by any single metadata field. CVE-2026-14055 looks small in Google’s release notes, loud in CISA-ADP scoring, and more precise after NVD’s CPE reanalysis. All three views are useful; none should be treated as the whole truth.- Windows systems running Google Chrome before 150.0.7871.47 should be updated and relaunched promptly.
- The corrected NVD configuration models the issue as Chrome on Microsoft Windows, not as a platform-neutral Chrome flaw.
- Google’s Low Chromium severity reflects exploit preconditions, while CISA-ADP’s Critical CVSS score reflects the potential impact of a successful sandbox escape.
- There is no public indication in the provided NVD record that CVE-2026-14055 is being exploited in the wild.
- Scanner results should be checked for stale CPE logic before teams create exceptions, suppressions, or emergency tickets.
- Chromium-based browsers other than Google Chrome need their own vendor-specific update checks rather than assumptions based on Chrome’s version number.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:39-07:00
NVD - CVE-2026-14055
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:39-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com