Google fixed CVE-2026-13806 in Chrome 150.0.7871.47 for Windows and Mac after disclosing that earlier builds allowed a remote attacker, already inside Chrome’s renderer process, to bypass site isolation through a crafted HTML page using insufficient input validation in Accessibility. The vulnerability is not a drive-by “visit and get owned” bug by itself, but it is exactly the kind of second-stage flaw that makes browser compromise more dangerous. As documented by Google’s Chrome Releases blog and now reflected in the National Vulnerability Database, the patch sits inside a very large Chrome 150 security update rather than a neat, isolated emergency advisory. That makes it easy to underread—and that would be a mistake.
The important phrase in CVE-2026-13806 is not merely “insufficient validation of untrusted input.” Chrome has hundreds of bugs that fit some version of that description. The phrase that should make administrators look twice is “bypass site isolation.”
Site isolation is one of Chrome’s foundational post-Spectre defenses. Its job is to keep content from different sites separated across process boundaries so that a compromised renderer cannot casually peer into data belonging to another origin. In plain English, it is the browser’s internal apartment wall between tabs, frames, and sites that should not trust each other.
CVE-2026-13806 describes a weakness in Chrome’s Accessibility component, a part of the browser that exists to expose structured information about web content to assistive technologies. That component has to interpret, transform, and broker a great deal of page state. When validation fails there, the risk is not just a crash or a malformed tree; the risk is that attacker-controlled page content can influence a privileged cross-boundary mechanism.
Google classified the Chromium issue as high severity. CISA’s Automated Data Processing enrichment assigned a CVSS 3.1 score of 8.1, with network attack vector, low attack complexity, no privileges required, user interaction required, and high confidentiality and integrity impact. NIST had not yet provided its own CVSS assessment when the entry was last modified on July 2, but the operational signal is already clear enough: update Chrome, then verify the update actually landed.
Modern Chrome exploitation is usually modular. An initial bug gets code execution or meaningful influence inside a renderer sandbox. A second bug breaks out of that sandbox, crosses a privilege boundary, or weakens a browser security invariant. CVE-2026-13806 is in that second category: it is about what an attacker can do after obtaining a foothold in the renderer.
That is why the “user interaction required” metric does not make the flaw benign. Browser attacks almost always begin with user interaction in the broadest sense: a clicked link, a loaded page, a malicious ad, a compromised site, a phishing landing page, or a document that opens web content. Once that first step happens, the practical question becomes whether Chrome’s defensive layers contain the damage.
Site isolation is supposed to be one of those layers. A bypass does not necessarily mean full operating-system compromise, and Google’s public wording does not claim that. But it can mean a compromised renderer gains access to information or behavior that Chrome’s origin boundaries were supposed to deny.
That is why the confidentiality and integrity impacts are both rated high by CISA’s enrichment. Availability is not the story here. This is not primarily about knocking Chrome over; it is about weakening the browser’s compartmentalization after an attacker has already found a way into one compartment.
That number is not a typo, and it changes the way this advisory should be read. CVE-2026-13806 is one entry in a vast cleanup release full of critical and high-severity issues across Extensions, GPU, ANGLE, Dawn, Skia, WebUSB, Views, Bluetooth, V8, Updater, Chromecast, and other subsystems. A reader looking only for a single headline-grabbing zero-day could easily miss the broader message: Chrome’s attack surface remains enormous because the browser is now a runtime, graphics stack, document viewer, app platform, identity surface, and operating environment all at once.
Google’s Chrome Releases post also repeated its standard caveat that access to bug details may remain restricted until most users are updated. That is reasonable vendor behavior, but it leaves defenders working from sparse public descriptions. For CVE-2026-13806, the restricted Chromium issue means administrators get the contours of the risk, not a proof of concept or a full technical root cause.
The absence of public exploit details is not the same as absence of risk. CISA’s SSVC entry lists exploitation as “none,” automatable as “no,” and technical impact as “total.” That combination suggests there was no known active exploitation at the time of enrichment, but also that a successful exploitation path could have serious consequences inside the browser security model.
That creates an uncomfortable security truth: anything that interprets the web page’s structure can become part of the browser’s trust boundary. The accessibility tree is not just a passive mirror of the DOM. It is a curated representation of roles, states, labels, focus, relationships, and events. If hostile input can distort that representation in the wrong place, it may influence code paths that were not written with attacker control front of mind.
Chrome is hardly alone here. Every major browser has had to harden accessibility, rendering, graphics, media, font, and extension subsystems because the modern web forces browsers to parse almost everything. The lesson from CVE-2026-13806 is narrower but sharper: defensive features like site isolation depend on mundane validation work in subsystems that users rarely think about.
This is also why “Accessibility” should not make enterprise teams assume the issue affects only users with assistive technologies enabled. The public description does not say that exploitation requires a screen reader or a particular accessibility tool. The component name identifies where the bug lived, not necessarily the only user population exposed to the vulnerable code path.
The version threshold is straightforward: Chrome before 150.0.7871.47 is affected according to the NVD entry for the Windows and Mac build line. Google’s release language also lists 150.0.7871.46/.47 for Windows and Mac, which means administrators should avoid relying on a vague “Chrome 150” label and verify the exact build deployed in their environment. Version precision matters when the vulnerable range is expressed as “prior to 150.0.7871.47.”
For managed Windows estates, the practical work is familiar but still easy to get wrong. Chrome’s own updater usually does the job quickly, but long-lived browser sessions, locked-down VDI pools, application control policies, offline machines, and broken update services can leave pockets of exposure. A patch that is “rolling out” is not the same as a patch that has completed across a fleet.
The consumer advice is simpler: open Chrome’s About page and let the browser check for updates, then restart it. The restart is not ceremonial. Chrome can download an update and still keep old vulnerable code running until the browser process exits and relaunches.
The underlying change history is the more useful record. NIST’s initial analysis on July 2 added the Chrome CPE configuration and tagged Google’s Chrome Releases post as both release notes and vendor advisory. The CVE was received from Chrome on June 30, modified by CISA-ADP on July 1, and then enriched by NIST on July 2.
This sequencing matters because vulnerability databases are not static truth tablets. They are workflows. A CVE can arrive with a vendor description, get provisional weakness and scoring data from one source, have that enrichment adjusted, and later receive NVD analysis and CPE mappings.
For vulnerability management teams, the answer to “are we missing a CPE?” is: probably not in the underlying record, but scanners and dashboards may lag or display it inconsistently. If a tool has not yet associated CVE-2026-13806 with Chrome prior to 150.0.7871.47, the correct response is to check the tool’s feed freshness and matching logic, not to wait for risk to become more convenient.
Google says the bug is high severity and identifies Accessibility as the affected component. NVD records CWE-20, improper input validation, as the weakness associated with Chrome’s source data. CISA’s CVSS vector emphasizes that the attack is network-reachable, low complexity, requires user interaction, and can have high confidentiality and integrity impact.
The most interesting CISA detail is the SSVC technical impact entry of “total.” SSVC is not the same thing as CVSS; it is meant to help prioritize action. In this case, CISA’s enrichment also says exploitation was not known and automation was not expected. That combination pushes against panic while still arguing for prompt patching.
This is the right middle ground. CVE-2026-13806 is not publicly described as an actively exploited zero-day. It is also not a minor hardening bug. It is a high-severity browser boundary issue fixed in a release that administrators should already be accelerating because of the sheer volume of security repairs.
A renderer compromise can come from a separate vulnerability, a just-patched bug in another subsystem, a not-yet-public issue, or a chain involving malicious content and browser features. Once that foothold exists, a site isolation bypass can widen access or defeat assumptions that security teams depend on indirectly. For users signed into corporate SaaS, cloud consoles, internal dashboards, and privileged administration portals, browser containment is not an academic boundary.
The better way to interpret the prerequisite is operational. This CVE is less likely to be the first alert in an incident and more likely to be the quiet enabler that makes an incident worse. That places it squarely in the category of flaws that patching programs should eliminate before exploit developers get comfortable chaining them.
It also means exploit detection will be difficult. A successful attack path would likely look like ordinary web browsing until it does not. Endpoint telemetry may catch later-stage behavior, but the browser-internal boundary crossing itself is not something most organizations can reliably observe from outside Chrome.
This is where Windows environments get messy. A machine may have Chrome, Edge, a vendor-embedded Chromium runtime, Electron apps, WebView2 components, and multiple auto-update mechanisms. A Chrome patch does not update all of those things. It only updates Chrome.
Microsoft typically ships Edge fixes after integrating relevant Chromium updates into its own Stable channel, while WebView2 runtime updates follow Microsoft’s distribution mechanisms. That cadence is usually fast, but “usually” is not an inventory control. If your organization standardizes on Edge, Chrome’s advisory is still a signal to verify Edge’s corresponding security baseline rather than assume the issue is irrelevant.
For consumer Windows users, the practical answer is to update every Chromium-based browser installed, not just the one pinned to the taskbar. For administrators, the better answer is to inventory browsers and browser runtimes as first-class software assets. The web engine is now too important to be treated as invisible middleware.
The Chrome team’s vulnerability reward program, internal fuzzing, and rapid release engineering are doing exactly what mature security programs are supposed to do. They find bugs before attackers do, restrict details while users patch, and ship broadly. But the same machinery also produces a firehose of CVEs that ordinary users cannot meaningfully evaluate.
That gap is where enterprise process must step in. Users should not be expected to understand whether an Accessibility site isolation bypass is more urgent than a GPU use-after-free or an ANGLE input validation flaw. The organization should have policy, telemetry, and enforcement that turn Chrome’s rapid patch cadence into completed updates.
The alternative is security theater: advisories are read, tickets are opened, dashboards turn yellow, and vulnerable browser processes keep running for days because nobody forced the restart. Browser patching is not done when the package is deployed. It is done when the old process is gone.
CVE-2026-13806 is a useful reminder that disruption has to be weighed against what the browser contains. For many workers, Chrome is where SSO tokens, cloud storage sessions, CRM data, internal documentation, messaging, admin consoles, and financial systems all converge. Leaving a vulnerable browser process alive to preserve a few tabs is a poor trade when a high-severity boundary bug has been patched.
Managed Chrome policies can help. Enterprises can set relaunch notification periods, force relaunches after updates, and surface update status through management tooling. Those policies are sometimes seen as user-hostile, but a measured relaunch window is far less hostile than silent exposure to a known browser security flaw.
The right posture is not to slam every browser shut the moment a release drops. It is to define a short, predictable restart window for high-severity browser updates and enforce it consistently. Users adapt quickly when the rule is clear and rare exceptions are handled deliberately.
Chrome’s Accessibility Bug Is Really a Site Isolation Story
The important phrase in CVE-2026-13806 is not merely “insufficient validation of untrusted input.” Chrome has hundreds of bugs that fit some version of that description. The phrase that should make administrators look twice is “bypass site isolation.”Site isolation is one of Chrome’s foundational post-Spectre defenses. Its job is to keep content from different sites separated across process boundaries so that a compromised renderer cannot casually peer into data belonging to another origin. In plain English, it is the browser’s internal apartment wall between tabs, frames, and sites that should not trust each other.
CVE-2026-13806 describes a weakness in Chrome’s Accessibility component, a part of the browser that exists to expose structured information about web content to assistive technologies. That component has to interpret, transform, and broker a great deal of page state. When validation fails there, the risk is not just a crash or a malformed tree; the risk is that attacker-controlled page content can influence a privileged cross-boundary mechanism.
Google classified the Chromium issue as high severity. CISA’s Automated Data Processing enrichment assigned a CVSS 3.1 score of 8.1, with network attack vector, low attack complexity, no privileges required, user interaction required, and high confidentiality and integrity impact. NIST had not yet provided its own CVSS assessment when the entry was last modified on July 2, but the operational signal is already clear enough: update Chrome, then verify the update actually landed.
The Exploit Chain Starts Before This CVE Does
The description contains a constraint that matters: the attacker must already have compromised the renderer process. That wording is easy to misread as reassuring. In practice, it tells defenders where the bug fits in the chain.Modern Chrome exploitation is usually modular. An initial bug gets code execution or meaningful influence inside a renderer sandbox. A second bug breaks out of that sandbox, crosses a privilege boundary, or weakens a browser security invariant. CVE-2026-13806 is in that second category: it is about what an attacker can do after obtaining a foothold in the renderer.
That is why the “user interaction required” metric does not make the flaw benign. Browser attacks almost always begin with user interaction in the broadest sense: a clicked link, a loaded page, a malicious ad, a compromised site, a phishing landing page, or a document that opens web content. Once that first step happens, the practical question becomes whether Chrome’s defensive layers contain the damage.
Site isolation is supposed to be one of those layers. A bypass does not necessarily mean full operating-system compromise, and Google’s public wording does not claim that. But it can mean a compromised renderer gains access to information or behavior that Chrome’s origin boundaries were supposed to deny.
That is why the confidentiality and integrity impacts are both rated high by CISA’s enrichment. Availability is not the story here. This is not primarily about knocking Chrome over; it is about weakening the browser’s compartmentalization after an attacker has already found a way into one compartment.
The June 30 Chrome 150 Release Was Too Big for Any One Bug to Stand Out
Google’s June 30 Stable Channel update promoted Chrome 150 to stable for Windows, Mac, and Linux. The company said the update would roll out over the coming days and weeks, with Windows and Mac receiving 150.0.7871.46/.47 and Linux receiving 150.0.7871.46. Google also said the release included 433 security fixes.That number is not a typo, and it changes the way this advisory should be read. CVE-2026-13806 is one entry in a vast cleanup release full of critical and high-severity issues across Extensions, GPU, ANGLE, Dawn, Skia, WebUSB, Views, Bluetooth, V8, Updater, Chromecast, and other subsystems. A reader looking only for a single headline-grabbing zero-day could easily miss the broader message: Chrome’s attack surface remains enormous because the browser is now a runtime, graphics stack, document viewer, app platform, identity surface, and operating environment all at once.
Google’s Chrome Releases post also repeated its standard caveat that access to bug details may remain restricted until most users are updated. That is reasonable vendor behavior, but it leaves defenders working from sparse public descriptions. For CVE-2026-13806, the restricted Chromium issue means administrators get the contours of the risk, not a proof of concept or a full technical root cause.
The absence of public exploit details is not the same as absence of risk. CISA’s SSVC entry lists exploitation as “none,” automatable as “no,” and technical impact as “total.” That combination suggests there was no known active exploitation at the time of enrichment, but also that a successful exploitation path could have serious consequences inside the browser security model.
Accessibility Is a Security Boundary Even When It Wasn’t Designed as One
Accessibility APIs are often treated as usability infrastructure, and rightly so. They make software usable for people who rely on screen readers, magnification, voice control, switch devices, and other assistive technologies. But in a browser, Accessibility also becomes a translation layer between hostile web content and privileged platform-facing interfaces.That creates an uncomfortable security truth: anything that interprets the web page’s structure can become part of the browser’s trust boundary. The accessibility tree is not just a passive mirror of the DOM. It is a curated representation of roles, states, labels, focus, relationships, and events. If hostile input can distort that representation in the wrong place, it may influence code paths that were not written with attacker control front of mind.
Chrome is hardly alone here. Every major browser has had to harden accessibility, rendering, graphics, media, font, and extension subsystems because the modern web forces browsers to parse almost everything. The lesson from CVE-2026-13806 is narrower but sharper: defensive features like site isolation depend on mundane validation work in subsystems that users rarely think about.
This is also why “Accessibility” should not make enterprise teams assume the issue affects only users with assistive technologies enabled. The public description does not say that exploitation requires a screen reader or a particular accessibility tool. The component name identifies where the bug lived, not necessarily the only user population exposed to the vulnerable code path.
Windows Admins Should Treat Chrome Like Shared Infrastructure, Not User Preference
On Windows networks, Chrome often occupies an awkward administrative category. It is not part of the base operating system in the way Edge is, but it is installed everywhere, used constantly, and deeply entangled with identity providers, SaaS dashboards, password managers, endpoint agents, and line-of-business applications. That makes Chrome patch state a fleet security issue, not a matter of user choice.The version threshold is straightforward: Chrome before 150.0.7871.47 is affected according to the NVD entry for the Windows and Mac build line. Google’s release language also lists 150.0.7871.46/.47 for Windows and Mac, which means administrators should avoid relying on a vague “Chrome 150” label and verify the exact build deployed in their environment. Version precision matters when the vulnerable range is expressed as “prior to 150.0.7871.47.”
For managed Windows estates, the practical work is familiar but still easy to get wrong. Chrome’s own updater usually does the job quickly, but long-lived browser sessions, locked-down VDI pools, application control policies, offline machines, and broken update services can leave pockets of exposure. A patch that is “rolling out” is not the same as a patch that has completed across a fleet.
The consumer advice is simpler: open Chrome’s About page and let the browser check for updates, then restart it. The restart is not ceremonial. Chrome can download an update and still keep old vulnerable code running until the browser process exits and relaunches.
The CPE Confusion Is Mostly a Timing Artifact
The user-facing NVD page briefly shows the kind of oddity security teams see all the time: “CPEs loading, please wait,” paired with change history showing that NIST added a CPE configuration for Google Chrome versions up to, but excluding, 150.0.7871.47. That is not evidence that the CVE lacks an affected product mapping. It is more likely a presentation or loading artifact on the NVD page.The underlying change history is the more useful record. NIST’s initial analysis on July 2 added the Chrome CPE configuration and tagged Google’s Chrome Releases post as both release notes and vendor advisory. The CVE was received from Chrome on June 30, modified by CISA-ADP on July 1, and then enriched by NIST on July 2.
This sequencing matters because vulnerability databases are not static truth tablets. They are workflows. A CVE can arrive with a vendor description, get provisional weakness and scoring data from one source, have that enrichment adjusted, and later receive NVD analysis and CPE mappings.
For vulnerability management teams, the answer to “are we missing a CPE?” is: probably not in the underlying record, but scanners and dashboards may lag or display it inconsistently. If a tool has not yet associated CVE-2026-13806 with Chrome prior to 150.0.7871.47, the correct response is to check the tool’s feed freshness and matching logic, not to wait for risk to become more convenient.
NVD, CISA, and Google Are Telling Slightly Different Parts of the Same Story
Google’s advisory tells administrators what shipped and gives a brief severity classification. NVD records the description, references, affected configuration, weakness category, and enrichment state. CISA-ADP adds a severity vector and SSVC-style operational judgment. None of these views is complete on its own.Google says the bug is high severity and identifies Accessibility as the affected component. NVD records CWE-20, improper input validation, as the weakness associated with Chrome’s source data. CISA’s CVSS vector emphasizes that the attack is network-reachable, low complexity, requires user interaction, and can have high confidentiality and integrity impact.
The most interesting CISA detail is the SSVC technical impact entry of “total.” SSVC is not the same thing as CVSS; it is meant to help prioritize action. In this case, CISA’s enrichment also says exploitation was not known and automation was not expected. That combination pushes against panic while still arguing for prompt patching.
This is the right middle ground. CVE-2026-13806 is not publicly described as an actively exploited zero-day. It is also not a minor hardening bug. It is a high-severity browser boundary issue fixed in a release that administrators should already be accelerating because of the sheer volume of security repairs.
The Renderer Compromise Requirement Should Shape, Not Delay, Response
There is a temptation in some enterprise risk meetings to downgrade any browser vulnerability that requires a prior renderer compromise. That logic sounds disciplined, but it misunderstands how browser exploit chains are assembled. Attackers do not need every link in the chain to be independently catastrophic; they need links that compose.A renderer compromise can come from a separate vulnerability, a just-patched bug in another subsystem, a not-yet-public issue, or a chain involving malicious content and browser features. Once that foothold exists, a site isolation bypass can widen access or defeat assumptions that security teams depend on indirectly. For users signed into corporate SaaS, cloud consoles, internal dashboards, and privileged administration portals, browser containment is not an academic boundary.
The better way to interpret the prerequisite is operational. This CVE is less likely to be the first alert in an incident and more likely to be the quiet enabler that makes an incident worse. That places it squarely in the category of flaws that patching programs should eliminate before exploit developers get comfortable chaining them.
It also means exploit detection will be difficult. A successful attack path would likely look like ordinary web browsing until it does not. Endpoint telemetry may catch later-stage behavior, but the browser-internal boundary crossing itself is not something most organizations can reliably observe from outside Chrome.
Edge, Chromium Derivatives, and the Patch Lag Problem
CVE-2026-13806 is a Chrome CVE, but Chromium vulnerabilities rarely stay conceptually confined to Chrome. Microsoft Edge, Brave, Vivaldi, Opera, and other Chromium-derived browsers depend on upstream Chromium code to varying degrees and on different schedules. The public CVE entry names Google Chrome, so defenders should not automatically assert exposure for every derivative without vendor confirmation, but they should absolutely check each browser’s update channel.This is where Windows environments get messy. A machine may have Chrome, Edge, a vendor-embedded Chromium runtime, Electron apps, WebView2 components, and multiple auto-update mechanisms. A Chrome patch does not update all of those things. It only updates Chrome.
Microsoft typically ships Edge fixes after integrating relevant Chromium updates into its own Stable channel, while WebView2 runtime updates follow Microsoft’s distribution mechanisms. That cadence is usually fast, but “usually” is not an inventory control. If your organization standardizes on Edge, Chrome’s advisory is still a signal to verify Edge’s corresponding security baseline rather than assume the issue is irrelevant.
For consumer Windows users, the practical answer is to update every Chromium-based browser installed, not just the one pinned to the taskbar. For administrators, the better answer is to inventory browsers and browser runtimes as first-class software assets. The web engine is now too important to be treated as invisible middleware.
The Massive Chrome 150 Patch Raises a Trust Problem of Its Own
A 433-fix browser release is good news because bugs are being fixed. It is also unsettling because it reminds everyone how much security debt lives in the layers beneath ordinary browsing. Chrome’s success rests on a paradox: it is one of the most aggressively hardened pieces of consumer software in the world, and it remains one of the richest targets in the world.The Chrome team’s vulnerability reward program, internal fuzzing, and rapid release engineering are doing exactly what mature security programs are supposed to do. They find bugs before attackers do, restrict details while users patch, and ship broadly. But the same machinery also produces a firehose of CVEs that ordinary users cannot meaningfully evaluate.
That gap is where enterprise process must step in. Users should not be expected to understand whether an Accessibility site isolation bypass is more urgent than a GPU use-after-free or an ANGLE input validation flaw. The organization should have policy, telemetry, and enforcement that turn Chrome’s rapid patch cadence into completed updates.
The alternative is security theater: advisories are read, tickets are opened, dashboards turn yellow, and vulnerable browser processes keep running for days because nobody forced the restart. Browser patching is not done when the package is deployed. It is done when the old process is gone.
The Real Test Is Whether Your Browser Actually Restarted
Chrome’s update model is one of the better ones in mainstream software, but it has a human bottleneck: restart. Users keep tabs open for days, sometimes weeks. Administrators know this and often tolerate it because forced browser restarts are disruptive.CVE-2026-13806 is a useful reminder that disruption has to be weighed against what the browser contains. For many workers, Chrome is where SSO tokens, cloud storage sessions, CRM data, internal documentation, messaging, admin consoles, and financial systems all converge. Leaving a vulnerable browser process alive to preserve a few tabs is a poor trade when a high-severity boundary bug has been patched.
Managed Chrome policies can help. Enterprises can set relaunch notification periods, force relaunches after updates, and surface update status through management tooling. Those policies are sometimes seen as user-hostile, but a measured relaunch window is far less hostile than silent exposure to a known browser security flaw.
The right posture is not to slam every browser shut the moment a release drops. It is to define a short, predictable restart window for high-severity browser updates and enforce it consistently. Users adapt quickly when the rule is clear and rare exceptions are handled deliberately.
The Chrome 150 Lesson Fits in One Narrow Window
The operational takeaway from CVE-2026-13806 is not that Accessibility is uniquely dangerous or that Chrome has suddenly become unsafe. It is that browser security now depends on layers whose failures may only matter after another failure has already occurred. That is exactly why patching needs to be boring, fast, and verified.- Chrome installations older than 150.0.7871.47 should be treated as exposed to CVE-2026-13806 on the affected Windows and Mac build line.
- The flaw is high severity because it can bypass site isolation after a renderer compromise, not because it is publicly described as a one-click full system takeover.
- CISA’s enrichment reported no known exploitation at the time, but assigned an 8.1 high CVSS score and high confidentiality and integrity impact.
- The NVD change history shows a Chrome CPE configuration was added for versions prior to 150.0.7871.47, even if the public page presentation appears temporarily awkward.
- Administrators should verify running browser versions and completed restarts, not merely package deployment or update availability.
- Chromium-derived browsers and embedded Chromium runtimes should be checked through their own vendor update channels rather than assumed safe because Chrome was patched.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:07-07:00
NVD - CVE-2026-13806
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:07-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
