CVE-2026-7337 is a high-severity type confusion flaw in Chrome’s V8 JavaScript engine, disclosed April 28, 2026, affecting Google Chrome before 147.0.7727.138 and patched in the April 28 Stable Channel desktop update for Windows, macOS, and Linux. The bug is not a garden-variety browser footnote; it is another reminder that the modern browser is now a full application platform with an attack surface to match. For WindowsForum readers, the practical story is simple: Chrome, Edge, and every Chromium-dependent workflow deserve the same urgency once reserved for operating-system patch days.
The phrase type confusion in V8 sounds narrow, almost academic, until you remember what V8 does all day. It takes JavaScript from the open web, aggressively optimizes it, and runs it at speeds that make modern web applications feel like native software. That speed comes from complexity, and complexity is where attackers live.
CVE-2026-7337 allowed a remote attacker to execute arbitrary code inside Chrome’s sandbox by convincing a user to open a crafted HTML page. That last clause matters. This is not a flaw that requires stolen credentials, local access, or a complicated chain of enterprise misconfiguration. The starting point is the oldest browser threat model in the book: the user loads hostile web content.
The sandbox qualification is also important. “Inside a sandbox” is not the same thing as “harmless.” Chrome’s sandbox is a major barrier, but attackers often chain renderer bugs with separate sandbox escapes, privilege-escalation flaws, or credential-theft techniques. A browser exploit that lands code execution in the renderer is a foothold, not a finish line.
That is why the severity lands high even without public evidence, as of the disclosed advisories, that this specific vulnerability is being exploited in the wild. The shape of the bug is attractive: network-reachable, low attack complexity, no privileges required, user interaction required, and high impact on confidentiality, integrity, and availability under the CVSS 3.1 assessment supplied through CISA’s ADP process. In plainer English: a victim clicks or visits, and the browser does the dangerous part.
That crowded patch train is the story. Chromium’s security posture is no longer defined by the occasional dramatic zero-day but by the rhythm of constant repair. The browser is absorbing untrusted code, media, graphics, fonts, protocols, device APIs, GPU paths, accessibility plumbing, and remote-collaboration features every minute it runs. Any one of those layers can become the first domino.
CVE-2026-7337 was reported by an external researcher on April 9 and shipped in Stable on April 28. That is a short and healthy disclosure-to-fix window for a high-impact browser bug, but it also means defenders had only the usual narrow window between release and adversary diffing. Once a patch is public, exploit developers can compare old and new code to infer what changed, even if detailed bug reports remain restricted.
Google’s practice of keeping bug details restricted until most users are updated is sensible, but it is not magic. The release note says enough to focus attention: V8, type confusion, arbitrary code execution, crafted HTML. The rest of the race happens in update telemetry, fleet management dashboards, and the uncomfortable lag between “patch available” and “patch installed everywhere.”
Modern JavaScript engines are built on layers of assumptions. They infer types, generate optimized machine code, deoptimize when assumptions fail, and juggle garbage collection while web pages mutate objects in creative ways. The attacker’s goal is to find a sequence that makes the engine believe one thing while memory contains another.
That is why V8 flaws often punch above their apparent weight. JavaScript is ubiquitous, web-delivered, and deeply optimized. The same machinery that makes Gmail, Teams, Figma, Outlook Web, and modern admin consoles usable is also machinery that must safely process hostile input from any site a user visits.
There is no need to sensationalize this. The public description does not provide exploit details, and defenders should avoid pretending they have a proof-of-concept when they do not. But the class of bug is well understood, and the defensive lesson is consistent: memory-safety faults in browser engines must be patched quickly because they are among the most reusable primitives in offensive browser exploitation.
The browser monoculture argument often gets framed as a consumer-choice debate, but enterprise administrators experience it as a patch-management problem. Chrome, Edge, Brave, Vivaldi, Opera, embedded Chromium runtimes, Electron applications, and Android WebView-style dependencies all move downstream from the same river. When the river carries a V8 fix, the endpoints are not all patched at once.
Microsoft’s Security Response Center listing for CVE-2026-7337 is therefore not just a courtesy mirror of Chrome information. It is the place many Windows administrators will first see the vulnerability mapped into Microsoft’s update process and vulnerability-management tooling. The CPE data also makes the cross-platform reality explicit: the affected Chrome application spans Windows, Linux, and macOS.
The practical trap is assuming that Windows Update alone settles the matter. Edge has its own update mechanism, Chrome has its own update mechanism, enterprise-managed browsers may be pinned or staged, and VDI images may be frozen behind change windows. The attack does not care which team owns the update ring.
Which devices are still on 147.0.7727.137 on Windows or macOS, and does the vendor consider that build equivalent for a given platform? Which Linux hosts are on the patched 147.0.7727.137 build? Which devices have downloaded the update but not restarted? Which users keep 80 tabs alive for days and unknowingly defer the browser relaunch that actually activates the fix?
Browser patching has an irritating two-step nature. The update can download automatically, but the running process remains old until restarted. That creates a gap that is invisible to users who see no conventional installer and no reboot prompt. In a browser exploit scenario, “pending relaunch” should be treated as “not remediated.”
For managed Windows environments, this argues for policy rather than hope. Browser relaunch notifications, forced relaunch deadlines, update override policies, and inventory checks are not niceties when high-severity V8 bugs are in play. They are the difference between a published patch and an actually reduced attack surface.
Attackers do not need every Chrome bug to be exploited before defenders respond. Browser vulnerabilities become more dangerous after disclosure because the patch itself becomes a roadmap. Sophisticated actors can examine Chromium commits, test old builds, and build reliable triggers while enterprise fleets are still moving through staged deployment rings.
The April 2026 context makes this especially uncomfortable. Microsoft’s Edge security notes earlier in the year repeatedly called out Chromium vulnerabilities with reported exploitation in the wild, including V8-related issues. That does not make CVE-2026-7337 exploited by association, but it does show that browser engine bugs remain a live target class rather than a theoretical concern.
The right response is proportional urgency. This is not a reason to unplug the office from the web. It is a reason to compress browser patch timelines, verify restart completion, and treat unmanaged Chromium-based browsers as unmanaged risk.
A renderer foothold can still expose sensitive page content, browser-mediated secrets, session context, and application data available to that process. Depending on the browser architecture, site isolation, extensions, and exploit chain, the impact can vary widely. The CVSS vector’s high confidentiality, integrity, and availability impacts reflect the seriousness of arbitrary code execution even before a full sandbox escape is proven.
This is where browser hardening matters. Site isolation, extension control, exploit mitigations, and reduced attack surface do not replace patching, but they can narrow the blast radius. Edge’s enhanced security mode, Chrome’s enterprise controls, and disciplined extension governance all belong in the same conversation as version numbers.
Extensions deserve special mention. A hardened browser with a swamp of over-permissioned extensions is not hardened in any meaningful operational sense. If attackers cannot get the first exploit they want, they often look for the adjacent weakness: a stale extension, a permissive policy, an unmanaged profile, or a user who has been trained to click through warnings.
That timeline is fast, but it exposes a dependency many organizations underestimate. Scanner output depends on CPE mappings, vendor feeds, product detection logic, local inventory quality, and the scanner’s own update cadence. If any part lags, a vulnerable endpoint can look clean or an updated endpoint can look stale.
This is why administrators should not outsource reality to a single dashboard after a browser advisory. For high-severity browser flaws, version verification should come from multiple angles: browser policy reports, endpoint management inventory, vulnerability scanner data, and spot checks on representative systems. When those disagree, the answer is not to pick the prettiest dashboard; it is to find the detection gap.
The “are we missing a CPE?” prompt on NVD pages is almost charming in its humility. Vulnerability databases are not omniscient. They are living records built from vendor statements, analyst enrichment, and the imperfect taxonomy of software that now ships inside other software.
Linux deserves particular nuance. Google listed Linux Stable at 147.0.7727.137, while the CVE description refers to Chrome prior to 147.0.7727.138. That sort of platform-specific build numbering can confuse compliance workflows that expect a single global fixed version. The correct operational move is to use vendor channel information for the platform, not blindly fail every Linux host because its terminal build number differs from Windows.
Ubuntu’s treatment of the issue is also a reminder that distribution packaging can change the meaning of “affected.” On Ubuntu, the historical Chromium package path has long involved snap packaging rather than a conventional distro-maintained Chromium binary in many releases. That does not make Chromium risk vanish; it means administrators must understand which package, snap, or vendor browser is actually installed.
The same principle applies on macOS. A managed Mac running Chrome outside the reach of the Windows endpoint-management stack is still part of the organization’s browser risk. If your identity provider, SaaS apps, and admin consoles are browser-accessible, then browser patch compliance is an enterprise control, not an operating-system preference.
A user who opens a malicious page in an unmanaged Chrome install is not protected because Edge is current. A developer who tests in an old Chromium build is not protected because Chrome Stable is current. A help desk tool that embeds an outdated Chromium runtime is not protected because the desktop browser patched itself overnight.
This is where asset management becomes security engineering. The browser should be treated as a tier-one application with explicit ownership, approved variants, and update accountability. If an organization allows multiple Chromium-based browsers, it must track multiple update channels. If it does not allow them, it must enforce that decision technically rather than culturally.
There is a temptation to respond to every browser CVE by telling users to update and move on. That advice is necessary but shallow. The deeper question is whether the organization can prove which browser engines are present, which versions are running, and which processes remain alive from before the patch.
Browser updates also intersect with business anxiety. Some organizations stage Chrome and Edge updates to avoid breaking internal web applications. That is understandable. It is also dangerous if the staging process turns into a multi-week holding pattern for high-severity engine bugs.
The browser has become the runtime for business operations. That means compatibility testing still matters, but security updates need a fast lane. Organizations that cannot move browser patches quickly should be investing in test automation for their critical web apps, not using uncertainty as a permanent reason to defer.
There is also a cultural piece. Users have been trained that browser relaunch prompts are annoying interruptions. Security teams need to change that framing. A relaunch prompt after a high-severity browser update is closer to a seatbelt warning than a cosmetic nag.
The answer, too often, is “eventually.” Eventually the automatic update lands. Eventually the user relaunches. Eventually the scanner updates. Eventually the ticket closes. Attackers live in the space between those eventualities.
That is the hard lesson of modern Chromium security. The project’s update machinery is impressive, and the disclosure ecosystem works better than critics sometimes admit. But downstream defense is still human, procedural, and messy. The vendor can ship a fix in days; an enterprise can take weeks to make it real.
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
A V8 Bug Is Never Just a Browser Bug
The phrase type confusion in V8 sounds narrow, almost academic, until you remember what V8 does all day. It takes JavaScript from the open web, aggressively optimizes it, and runs it at speeds that make modern web applications feel like native software. That speed comes from complexity, and complexity is where attackers live.CVE-2026-7337 allowed a remote attacker to execute arbitrary code inside Chrome’s sandbox by convincing a user to open a crafted HTML page. That last clause matters. This is not a flaw that requires stolen credentials, local access, or a complicated chain of enterprise misconfiguration. The starting point is the oldest browser threat model in the book: the user loads hostile web content.
The sandbox qualification is also important. “Inside a sandbox” is not the same thing as “harmless.” Chrome’s sandbox is a major barrier, but attackers often chain renderer bugs with separate sandbox escapes, privilege-escalation flaws, or credential-theft techniques. A browser exploit that lands code execution in the renderer is a foothold, not a finish line.
That is why the severity lands high even without public evidence, as of the disclosed advisories, that this specific vulnerability is being exploited in the wild. The shape of the bug is attractive: network-reachable, low attack complexity, no privileges required, user interaction required, and high impact on confidentiality, integrity, and availability under the CVSS 3.1 assessment supplied through CISA’s ADP process. In plainer English: a victim clicks or visits, and the browser does the dangerous part.
The Patch Arrived in a Crowded Train
Google’s April 28 Stable Channel update was not a single-CVE emergency bulletin. It brought Chrome to 147.0.7727.137 or 147.0.7727.138 on Windows and macOS, and 147.0.7727.137 on Linux, with 30 security fixes in the release. CVE-2026-7337 was one entry in a long list that also included several critical use-after-free issues and a parade of high-severity memory-safety bugs across GPU, WebRTC, Media, Cast, Views, WebView, Skia, ANGLE, Accessibility, and other components.That crowded patch train is the story. Chromium’s security posture is no longer defined by the occasional dramatic zero-day but by the rhythm of constant repair. The browser is absorbing untrusted code, media, graphics, fonts, protocols, device APIs, GPU paths, accessibility plumbing, and remote-collaboration features every minute it runs. Any one of those layers can become the first domino.
CVE-2026-7337 was reported by an external researcher on April 9 and shipped in Stable on April 28. That is a short and healthy disclosure-to-fix window for a high-impact browser bug, but it also means defenders had only the usual narrow window between release and adversary diffing. Once a patch is public, exploit developers can compare old and new code to infer what changed, even if detailed bug reports remain restricted.
Google’s practice of keeping bug details restricted until most users are updated is sensible, but it is not magic. The release note says enough to focus attention: V8, type confusion, arbitrary code execution, crafted HTML. The rest of the race happens in update telemetry, fleet management dashboards, and the uncomfortable lag between “patch available” and “patch installed everywhere.”
Type Confusion Is the Compiler’s Betrayal
A type confusion bug is, at root, a broken promise about what a piece of memory represents. Software believes it is handling one kind of object, but reality has shifted under its feet. In a language runtime like V8, where the engine constantly speculates about object shapes and optimizes hot code paths, those promises are both powerful and perilous.Modern JavaScript engines are built on layers of assumptions. They infer types, generate optimized machine code, deoptimize when assumptions fail, and juggle garbage collection while web pages mutate objects in creative ways. The attacker’s goal is to find a sequence that makes the engine believe one thing while memory contains another.
That is why V8 flaws often punch above their apparent weight. JavaScript is ubiquitous, web-delivered, and deeply optimized. The same machinery that makes Gmail, Teams, Figma, Outlook Web, and modern admin consoles usable is also machinery that must safely process hostile input from any site a user visits.
There is no need to sensationalize this. The public description does not provide exploit details, and defenders should avoid pretending they have a proof-of-concept when they do not. But the class of bug is well understood, and the defensive lesson is consistent: memory-safety faults in browser engines must be patched quickly because they are among the most reusable primitives in offensive browser exploitation.
Microsoft’s Edge Inherits the Chromium Clock
For Windows shops, Chrome is only half the operational picture. Microsoft Edge is Chromium-based, and Microsoft’s own security release notes show Edge Stable 147.0.3912.98 arriving on April 30, incorporating the latest security updates from the Chromium project. That two-day offset is normal in the Chromium ecosystem, but it is exactly the sort of offset administrators need to track.The browser monoculture argument often gets framed as a consumer-choice debate, but enterprise administrators experience it as a patch-management problem. Chrome, Edge, Brave, Vivaldi, Opera, embedded Chromium runtimes, Electron applications, and Android WebView-style dependencies all move downstream from the same river. When the river carries a V8 fix, the endpoints are not all patched at once.
Microsoft’s Security Response Center listing for CVE-2026-7337 is therefore not just a courtesy mirror of Chrome information. It is the place many Windows administrators will first see the vulnerability mapped into Microsoft’s update process and vulnerability-management tooling. The CPE data also makes the cross-platform reality explicit: the affected Chrome application spans Windows, Linux, and macOS.
The practical trap is assuming that Windows Update alone settles the matter. Edge has its own update mechanism, Chrome has its own update mechanism, enterprise-managed browsers may be pinned or staged, and VDI images may be frozen behind change windows. The attack does not care which team owns the update ring.
“Prior to 147.0.7727.138” Is a Policy Statement
The vulnerable range is easy to write and harder to operationalize: Chrome before 147.0.7727.138. In consumer land, that means checking the About Chrome page and restarting the browser. In enterprise land, it means answering several less comfortable questions.Which devices are still on 147.0.7727.137 on Windows or macOS, and does the vendor consider that build equivalent for a given platform? Which Linux hosts are on the patched 147.0.7727.137 build? Which devices have downloaded the update but not restarted? Which users keep 80 tabs alive for days and unknowingly defer the browser relaunch that actually activates the fix?
Browser patching has an irritating two-step nature. The update can download automatically, but the running process remains old until restarted. That creates a gap that is invisible to users who see no conventional installer and no reboot prompt. In a browser exploit scenario, “pending relaunch” should be treated as “not remediated.”
For managed Windows environments, this argues for policy rather than hope. Browser relaunch notifications, forced relaunch deadlines, update override policies, and inventory checks are not niceties when high-severity V8 bugs are in play. They are the difference between a published patch and an actually reduced attack surface.
The Missing Exploit Note Should Not Become Permission to Wait
There is an important distinction between “high severity” and “known exploited.” Public advisories for CVE-2026-7337 do not mark it as a confirmed in-the-wild zero-day. That should temper panic. It should not create complacency.Attackers do not need every Chrome bug to be exploited before defenders respond. Browser vulnerabilities become more dangerous after disclosure because the patch itself becomes a roadmap. Sophisticated actors can examine Chromium commits, test old builds, and build reliable triggers while enterprise fleets are still moving through staged deployment rings.
The April 2026 context makes this especially uncomfortable. Microsoft’s Edge security notes earlier in the year repeatedly called out Chromium vulnerabilities with reported exploitation in the wild, including V8-related issues. That does not make CVE-2026-7337 exploited by association, but it does show that browser engine bugs remain a live target class rather than a theoretical concern.
The right response is proportional urgency. This is not a reason to unplug the office from the web. It is a reason to compress browser patch timelines, verify restart completion, and treat unmanaged Chromium-based browsers as unmanaged risk.
The Sandbox Is a Seatbelt, Not a Force Field
Chrome’s sandbox is one of the great quiet successes of modern client security. It limits what a compromised renderer process can do, containing damage that would once have meant immediate full-user compromise. But the language of CVE-2026-7337 makes clear that the sandbox is where the exploit lands, not where risk ends.A renderer foothold can still expose sensitive page content, browser-mediated secrets, session context, and application data available to that process. Depending on the browser architecture, site isolation, extensions, and exploit chain, the impact can vary widely. The CVSS vector’s high confidentiality, integrity, and availability impacts reflect the seriousness of arbitrary code execution even before a full sandbox escape is proven.
This is where browser hardening matters. Site isolation, extension control, exploit mitigations, and reduced attack surface do not replace patching, but they can narrow the blast radius. Edge’s enhanced security mode, Chrome’s enterprise controls, and disciplined extension governance all belong in the same conversation as version numbers.
Extensions deserve special mention. A hardened browser with a swamp of over-permissioned extensions is not hardened in any meaningful operational sense. If attackers cannot get the first exploit they want, they often look for the adjacent weakness: a stale extension, a permissive policy, an unmanaged profile, or a user who has been trained to click through warnings.
NVD’s CPE Lag Shows the Limits of Machine-Readable Truth
The NVD page for CVE-2026-7337 is a useful artifact because it shows how vulnerability intelligence gets assembled in public. The CVE arrived from Chrome on April 28. CISA-ADP added a CVSS 3.1 score on April 29. NIST added initial CPE configuration data on April 30, including Chrome versions up to but excluding 147.0.7727.138 and operating-system context for Windows, Linux, and macOS.That timeline is fast, but it exposes a dependency many organizations underestimate. Scanner output depends on CPE mappings, vendor feeds, product detection logic, local inventory quality, and the scanner’s own update cadence. If any part lags, a vulnerable endpoint can look clean or an updated endpoint can look stale.
This is why administrators should not outsource reality to a single dashboard after a browser advisory. For high-severity browser flaws, version verification should come from multiple angles: browser policy reports, endpoint management inventory, vulnerability scanner data, and spot checks on representative systems. When those disagree, the answer is not to pick the prettiest dashboard; it is to find the detection gap.
The “are we missing a CPE?” prompt on NVD pages is almost charming in its humility. Vulnerability databases are not omniscient. They are living records built from vendor statements, analyst enrichment, and the imperfect taxonomy of software that now ships inside other software.
Linux and macOS Are Not Side Quests
The CPE configuration and Google’s release note both make this a cross-platform Chrome issue. WindowsForum naturally thinks first about Windows and Edge, but Chrome fleets often sprawl across developer workstations, Linux jump boxes with GUI browsers, macOS executive laptops, and contractor devices. The web attack surface follows the user, not the domain boundary.Linux deserves particular nuance. Google listed Linux Stable at 147.0.7727.137, while the CVE description refers to Chrome prior to 147.0.7727.138. That sort of platform-specific build numbering can confuse compliance workflows that expect a single global fixed version. The correct operational move is to use vendor channel information for the platform, not blindly fail every Linux host because its terminal build number differs from Windows.
Ubuntu’s treatment of the issue is also a reminder that distribution packaging can change the meaning of “affected.” On Ubuntu, the historical Chromium package path has long involved snap packaging rather than a conventional distro-maintained Chromium binary in many releases. That does not make Chromium risk vanish; it means administrators must understand which package, snap, or vendor browser is actually installed.
The same principle applies on macOS. A managed Mac running Chrome outside the reach of the Windows endpoint-management stack is still part of the organization’s browser risk. If your identity provider, SaaS apps, and admin consoles are browser-accessible, then browser patch compliance is an enterprise control, not an operating-system preference.
The Real Exposure Is the Unmanaged Browser
Large organizations often know exactly how patched their standard browser is and almost nothing about the secondary browsers users installed years ago. That is a problem CVE-2026-7337 illustrates well. The vulnerable component is not a brand logo; it is Chromium’s web engine.A user who opens a malicious page in an unmanaged Chrome install is not protected because Edge is current. A developer who tests in an old Chromium build is not protected because Chrome Stable is current. A help desk tool that embeds an outdated Chromium runtime is not protected because the desktop browser patched itself overnight.
This is where asset management becomes security engineering. The browser should be treated as a tier-one application with explicit ownership, approved variants, and update accountability. If an organization allows multiple Chromium-based browsers, it must track multiple update channels. If it does not allow them, it must enforce that decision technically rather than culturally.
There is a temptation to respond to every browser CVE by telling users to update and move on. That advice is necessary but shallow. The deeper question is whether the organization can prove which browser engines are present, which versions are running, and which processes remain alive from before the patch.
Consumer Advice Is Too Gentle for Enterprise Reality
For home users, the fix path is refreshingly direct: update Chrome, relaunch it, and verify the version. For enterprise administrators, the same sentence expands into a change-management workflow. Policy settings may delay updates, network controls may block update endpoints, and virtual desktops may revert to vulnerable golden images after every session.Browser updates also intersect with business anxiety. Some organizations stage Chrome and Edge updates to avoid breaking internal web applications. That is understandable. It is also dangerous if the staging process turns into a multi-week holding pattern for high-severity engine bugs.
The browser has become the runtime for business operations. That means compatibility testing still matters, but security updates need a fast lane. Organizations that cannot move browser patches quickly should be investing in test automation for their critical web apps, not using uncertainty as a permanent reason to defer.
There is also a cultural piece. Users have been trained that browser relaunch prompts are annoying interruptions. Security teams need to change that framing. A relaunch prompt after a high-severity browser update is closer to a seatbelt warning than a cosmetic nag.
The April 28 Release Was a Systems Test
A single CVE rarely tests a mature security program. A release with 30 security fixes does. CVE-2026-7337 happened to be the V8 entry that stands out for code-execution potential, but the broader April 28 Chrome update contained enough memory-safety hazards to ask whether organizations can move at browser speed.The answer, too often, is “eventually.” Eventually the automatic update lands. Eventually the user relaunches. Eventually the scanner updates. Eventually the ticket closes. Attackers live in the space between those eventualities.
That is the hard lesson of modern Chromium security. The project’s update machinery is impressive, and the disclosure ecosystem works better than critics sometimes admit. But downstream defense is still human, procedural, and messy. The vendor can ship a fix in days; an enterprise can take weeks to make it real.
The Version Number Is the New Perimeter
CVE-2026-7337 is not a reason to panic, but it is a useful forcing function for browser hygiene. The following items are the concrete checks Windows and cross-platform administrators should make now.- Chrome desktop systems should be verified against the fixed Stable Channel builds for their platform, with special attention to whether the browser has actually relaunched after updating.
- Microsoft Edge fleets should be brought to the April 30 Stable release or later, because that release incorporates the latest Chromium security updates available through Microsoft’s channel.
- Vulnerability scanner results should be cross-checked against browser management inventory, since NVD enrichment, CPE mappings, and local detection plugins may not update at the same moment.
- Unmanaged Chromium-based browsers and embedded Chromium runtimes should be treated as part of the same exposure class rather than ignored because the standard corporate browser is patched.
- Browser update policies should include forced relaunch deadlines for high-severity engine fixes, because a downloaded update without a restart is not a completed mitigation.
- Security teams should avoid overstating exploitation claims for CVE-2026-7337 while still treating the bug class and disclosure timing as urgent enough for accelerated remediation.
Source: NVD / Chromium Security Update Guide - Microsoft Security Response Center
