CVE-2026-11691 is a high-severity Chromium vulnerability disclosed in June 2026 in Google Chrome’s New Tab Page, fixed before version 149.0.7827.103, that could let an attacker who had already compromised the renderer leak cross-origin data through a crafted HTML page. The awkward phrasing matters because this is not a clean, one-click remote code execution story; it is a browser isolation story. It sits in the uncomfortable middle ground where a bug looks modest on a scoring sheet but meaningful in a real exploit chain. For Windows users and administrators, that distinction is the whole point.
The phrase “New Tab Page” sounds harmless enough to invite complacency. In Chrome and Chromium-based browsers, though, the New Tab Page is not merely a blank canvas with a search box and a few shortcuts. It is a privileged, heavily integrated surface that touches browser UI, personalization, account state, search provider behavior, extension-adjacent assumptions, and the boundary between web content and browser-controlled experience.
That is why a validation bug there deserves more attention than its short CVE description initially suggests. The reported flaw is categorized as insufficient validation of untrusted input, mapped to CWE-20, and described as allowing cross-origin data leakage after renderer compromise. In plain English: if an attacker had already gotten code execution or meaningful control inside a renderer process, this bug could help them reach data they were not supposed to read.
That precondition is important. It means CVE-2026-11691 is not, by itself, the easiest path into a machine. But modern browser exploitation rarely depends on a single bug anymore. Attackers increasingly assemble chains: one flaw gets a foothold in a renderer, another bypasses a security boundary, another leaks data or improves reliability, and still another escapes the sandbox or steals tokens.
The New Tab Page is exactly the kind of place where browser vendors least want ambiguity. Users think of it as browser chrome, not web content. Attackers think of it as a boundary worth testing.
That discrepancy is not necessarily a contradiction. CVSS measures a vulnerability in a standardized, somewhat abstract way. Browser vendors, by contrast, tend to evaluate bugs through the lens of exploit chains, process boundaries, and how much a primitive helps turn a theoretical attack into a working one. A cross-origin data leak from a compromised renderer may look narrow in isolation but become valuable when paired with another vulnerability.
This is where security teams can get fooled by dashboards. A vulnerability management system that sorts strictly by CVSS might push this below louder bugs with cleaner numbers. A browser engineer or exploit analyst may see something different: a leak across one of the web’s most important security boundaries, reachable from a crafted page under conditions that attackers routinely try to create.
The distinction is not academic. Cross-origin isolation is one of the core promises of the browser. Your bank tab, your email tab, your cloud admin console, and a hostile page are not supposed to casually peer into one another’s state. Any bug that weakens that rule deserves a second look, even when the initial score does not scream.
Not quite. Chrome’s security model assumes that renderers are exposed to hostile content every day. The browser’s sandbox and site isolation architecture exist because rendering untrusted HTML, JavaScript, images, fonts, and media is inherently risky. A compromised renderer is bad, but it is not supposed to mean the attacker can read arbitrary cross-origin data or freely break out into browser state.
That is why post-renderer vulnerabilities matter. They are the joints in the armor. A renderer compromise without follow-on capabilities may be noisy, fragile, or contained. A renderer compromise paired with a data leak can become credential theft, session reconnaissance, or a stepping stone toward a more reliable exploit chain.
Administrators should read the phrase “who had compromised the renderer process” less as reassurance and more as a description of where this bug sits in the kill chain. It is probably not the first move. It may be the move that makes the first move worth something.
That version detail matters because Chrome’s release numbering can be deceptively untidy across platforms. Reports around the same stable update referenced 149.0.7827.102 for Windows and Linux and 149.0.7827.103 for Mac in some contexts, while the CVE wording uses “prior to 149.0.7827.103” as the fix threshold. For everyday users, the practical answer is simple: let Chrome update itself and verify that it reports an up-to-date build in the browser’s About screen.
For enterprise teams, the answer is less casual. Managed Chrome deployments, golden images, VDI pools, kiosk systems, and application compatibility rings often lag behind consumer auto-update behavior. A few days of lag is common. A few weeks of lag is where browser flaws start to become permanent attack surface.
This is also where Chromium’s ecosystem effect kicks in. Chrome is the named product in the CVE, but the underlying Chromium codebase feeds Microsoft Edge, Brave, Vivaldi, Opera, and other browsers on varying timelines. A Chrome CVE does not automatically prove the same exploitability in every Chromium derivative, but it does justify checking each vendor’s update channel rather than assuming “not Chrome” means “not exposed.”
CPE matching is useful for scanners, but it can produce a false sense of precision. A vulnerability entry may know that Chrome before a certain version is affected. It may not fully capture Edge’s adoption of the fix, an Electron application’s embedded Chromium version, a Linux distribution’s packaging choice, or a managed browser pinned for compatibility. The database view is a map, not the territory.
For WindowsForum readers, the obvious question is Microsoft Edge. Edge’s Chromium base means many Chromium security fixes eventually matter to Edge users, but timing and applicability depend on Microsoft’s integration and release process. Enterprises that standardize on Edge should not wait for a Chrome-branded scanner hit before checking Microsoft’s own Edge release notes and update baselines.
The same logic applies to applications that ship Chromium under the hood. Electron apps, WebView2-based enterprise software, and embedded browser controls complicate the old mental model of “update the browser and move on.” CVE-2026-11691 is specifically a Chrome New Tab Page issue, so it may not map neatly to every embedded Chromium runtime. But the broader lesson is that Chromium vulnerabilities rarely stay confined to the icon users click.
CVE-2026-11691 is described as a cross-origin data leak, not arbitrary code execution. That distinction matters, but it does not make the bug trivial. Cross-origin leakage can expose fragments of sensitive pages, authentication state, private metadata, or tokens depending on the exact bug and surrounding conditions. Even small leaks can be enough to defeat anti-CSRF assumptions, infer user identity, or guide a larger attack.
The industry has seen this pattern before. Spectre-era browser mitigations, site isolation, opaque response blocking, CORB, COOP, COEP, and related mechanisms all exist because the browser is constantly mediating between mutually distrusting origins. The modern web’s security model is layered precisely because no single layer is perfect.
A New Tab Page bug is especially uncomfortable because the page sits adjacent to browser-controlled features. Users do not think of it as a random website. They may trust it more, interact with it more casually, and leave it open constantly. That gives attackers a psychological angle even when the technical exploit path remains complex.
For defenders, however, the result is a familiar frustration. Security teams must make prioritization decisions with incomplete information. They know the component, the general weakness class, the rough impact, and the fixed version. They do not know exploit reliability, exact data exposure, whether common mitigations reduce risk, or whether the issue was discovered through internal fuzzing, external research, or attack telemetry unless Google says so.
CVE-2026-11691 is not described as exploited in the wild. That separates it from other Chrome flaws in the same general update cycle that drew more urgent attention because of reported active exploitation. But “not known exploited” is not the same as “uninteresting.” Once a patch ships, attackers can diff code, study the fix, and determine whether the bug is useful against unpatched systems.
This is the patch gap that defenders live inside. The vendor knows enough to patch. Attackers may soon know enough to weaponize. Administrators are left trying to compress the time between those two states.
But Windows environments have a long tail of exceptions. Users postpone relaunches. Businesses freeze updates during change-control windows. Remote desktops run stale browser sessions for weeks. Kiosks and shared machines are treated like appliances until someone audits them. Security tooling may report the installed version, while the running process remains an older build until restart.
That last point is easy to overlook. Updating the files on disk does not always mean every browser process in memory has been replaced. Chrome is better than many applications at nagging users to relaunch, but enterprises that care about browser risk should monitor both version compliance and restart behavior.
There is also the Windows habit of browser plurality. A user may have Chrome, Edge, Firefox, and a vendor-installed Chromium runtime all on the same machine. The default browser is not necessarily the only browser. Attackers do not care which icon the help desk prefers.
A reasonable service-level target for managed browsers is measured in days, not weeks. Chrome and Edge are too exposed, too widely used, and too central to identity workflows to be treated like ordinary desktop software. The browser is now the front door to Microsoft 365, Google Workspace, Okta, Azure portals, SaaS dashboards, developer consoles, banking systems, and internal applications.
Security teams should also pay attention to who is most exposed. Developers, administrators, finance staff, executives, and help-desk personnel often carry sessions and privileges that make browser data leaks more consequential. A vulnerability that leaks only a little data from the wrong tab can still matter.
The browser has become the operating system for work. That sounds like a cliché until a New Tab Page validation bug reminds us that the browser’s internal surfaces are now part of the enterprise attack surface.
The industry has largely accepted Chromium monoculture as the cost of compatibility. Web developers get fewer rendering engines to test against. Users get consistent behavior. Enterprises get policy tooling and predictable updates. But the security trade-off is that a meaningful Chromium flaw can ripple through a huge share of the browser market.
That does not mean every Chromium CVE affects every Chromium-based browser in the same way. A New Tab Page issue may depend on Chrome-specific implementation details. Edge has its own new tab experience, services, and Microsoft integrations. But shared code, shared assumptions, and shared architectural patterns make “not Google-branded” a weak comfort.
The right stance is disciplined uncertainty. Check the Chrome fix because Chrome is the source advisory. Check Edge because Edge is likely present on every supported Windows machine. Check other Chromium-derived browsers because users install them whether IT approves or not.
That kind of flaw is easy to under-communicate. Users understand “hackers can run code.” Executives understand “actively exploited zero-day.” Fewer people understand why a renderer-to-cross-origin leak matters. Yet sophisticated browser attacks are often built from exactly these pieces.
The security industry’s language does not help. “Insufficient validation of untrusted input” is technically accurate but emotionally inert. It covers everything from mundane parsing mistakes to boundary violations with serious consequences. A better operational translation would be: Chrome accepted something it should not have trusted in a sensitive browser-controlled surface, and under the right conditions that mistake could expose data from another origin.
That is the part worth remembering. The bug is not scary because the New Tab Page is glamorous. It is scary because the browser’s boring surfaces are where trust boundaries often become invisible.
There is also a communications lesson. Telling users to “update Chrome” is not enough if the organization has trained them to ignore relaunch prompts. Browser patching should be treated as a normal part of endpoint hygiene, with clear expectations that updates may require restarting the browser even during the workday.
For administrators, the most useful controls are boring and measurable: enforced update policies, version reporting, browser restart deadlines, and visibility into unauthorized browsers. Those controls will not make headlines, but they close the window in which a patched Chromium bug remains exploitable in practice.
The New Tab Page Was Never Just a Pretty Launcher
The phrase “New Tab Page” sounds harmless enough to invite complacency. In Chrome and Chromium-based browsers, though, the New Tab Page is not merely a blank canvas with a search box and a few shortcuts. It is a privileged, heavily integrated surface that touches browser UI, personalization, account state, search provider behavior, extension-adjacent assumptions, and the boundary between web content and browser-controlled experience.That is why a validation bug there deserves more attention than its short CVE description initially suggests. The reported flaw is categorized as insufficient validation of untrusted input, mapped to CWE-20, and described as allowing cross-origin data leakage after renderer compromise. In plain English: if an attacker had already gotten code execution or meaningful control inside a renderer process, this bug could help them reach data they were not supposed to read.
That precondition is important. It means CVE-2026-11691 is not, by itself, the easiest path into a machine. But modern browser exploitation rarely depends on a single bug anymore. Attackers increasingly assemble chains: one flaw gets a foothold in a renderer, another bypasses a security boundary, another leaks data or improves reliability, and still another escapes the sandbox or steals tokens.
The New Tab Page is exactly the kind of place where browser vendors least want ambiguity. Users think of it as browser chrome, not web content. Attackers think of it as a boundary worth testing.
A Low CVSS Score Can Hide a High-Value Primitive
The most striking tension around CVE-2026-11691 is the gap between its Chromium severity and the early public scoring. Chromium labels it High. CISA’s ADP CVSS 3.1 vector, meanwhile, lands at 3.1, or Low, because exploitation requires user interaction and high attack complexity, and the described impact is limited to confidentiality.That discrepancy is not necessarily a contradiction. CVSS measures a vulnerability in a standardized, somewhat abstract way. Browser vendors, by contrast, tend to evaluate bugs through the lens of exploit chains, process boundaries, and how much a primitive helps turn a theoretical attack into a working one. A cross-origin data leak from a compromised renderer may look narrow in isolation but become valuable when paired with another vulnerability.
This is where security teams can get fooled by dashboards. A vulnerability management system that sorts strictly by CVSS might push this below louder bugs with cleaner numbers. A browser engineer or exploit analyst may see something different: a leak across one of the web’s most important security boundaries, reachable from a crafted page under conditions that attackers routinely try to create.
The distinction is not academic. Cross-origin isolation is one of the core promises of the browser. Your bank tab, your email tab, your cloud admin console, and a hostile page are not supposed to casually peer into one another’s state. Any bug that weakens that rule deserves a second look, even when the initial score does not scream.
Renderer Compromise Is a Precondition, Not a Comfort Blanket
The CVE description says the attacker must have compromised the renderer process. That line will tempt some readers to mentally downgrade the bug: if the attacker already has a renderer, isn’t the damage done?Not quite. Chrome’s security model assumes that renderers are exposed to hostile content every day. The browser’s sandbox and site isolation architecture exist because rendering untrusted HTML, JavaScript, images, fonts, and media is inherently risky. A compromised renderer is bad, but it is not supposed to mean the attacker can read arbitrary cross-origin data or freely break out into browser state.
That is why post-renderer vulnerabilities matter. They are the joints in the armor. A renderer compromise without follow-on capabilities may be noisy, fragile, or contained. A renderer compromise paired with a data leak can become credential theft, session reconnaissance, or a stepping stone toward a more reliable exploit chain.
Administrators should read the phrase “who had compromised the renderer process” less as reassurance and more as a description of where this bug sits in the kill chain. It is probably not the first move. It may be the move that makes the first move worth something.
The Patch Version Tells Its Own Small Story
CVE-2026-11691 was fixed in Chrome prior to 149.0.7827.103, with public advisories around the June 2026 stable-channel update. The NVD record initially showed no NIST CVSS assessment, while CISA-ADP supplied the low CVSS 3.1 score. NVD’s change history also shows the affected Chrome configuration being added during initial analysis, with operating systems listed as part of the vulnerable platform configuration.That version detail matters because Chrome’s release numbering can be deceptively untidy across platforms. Reports around the same stable update referenced 149.0.7827.102 for Windows and Linux and 149.0.7827.103 for Mac in some contexts, while the CVE wording uses “prior to 149.0.7827.103” as the fix threshold. For everyday users, the practical answer is simple: let Chrome update itself and verify that it reports an up-to-date build in the browser’s About screen.
For enterprise teams, the answer is less casual. Managed Chrome deployments, golden images, VDI pools, kiosk systems, and application compatibility rings often lag behind consumer auto-update behavior. A few days of lag is common. A few weeks of lag is where browser flaws start to become permanent attack surface.
This is also where Chromium’s ecosystem effect kicks in. Chrome is the named product in the CVE, but the underlying Chromium codebase feeds Microsoft Edge, Brave, Vivaldi, Opera, and other browsers on varying timelines. A Chrome CVE does not automatically prove the same exploitability in every Chromium derivative, but it does justify checking each vendor’s update channel rather than assuming “not Chrome” means “not exposed.”
NVD’s CPE Oddity Is a Symptom of a Bigger Browser Problem
The user-facing NVD entry includes a prompt asking whether a CPE is missing and shows a configuration that pairs Chrome versions with Windows, Linux, and macOS. That is normal enough for vulnerability databases, but it also exposes one of the clumsier realities of browser vulnerability tracking. Browsers are applications, operating-system components, update channels, embedded runtimes, and enterprise-managed dependencies all at once.CPE matching is useful for scanners, but it can produce a false sense of precision. A vulnerability entry may know that Chrome before a certain version is affected. It may not fully capture Edge’s adoption of the fix, an Electron application’s embedded Chromium version, a Linux distribution’s packaging choice, or a managed browser pinned for compatibility. The database view is a map, not the territory.
For WindowsForum readers, the obvious question is Microsoft Edge. Edge’s Chromium base means many Chromium security fixes eventually matter to Edge users, but timing and applicability depend on Microsoft’s integration and release process. Enterprises that standardize on Edge should not wait for a Chrome-branded scanner hit before checking Microsoft’s own Edge release notes and update baselines.
The same logic applies to applications that ship Chromium under the hood. Electron apps, WebView2-based enterprise software, and embedded browser controls complicate the old mental model of “update the browser and move on.” CVE-2026-11691 is specifically a Chrome New Tab Page issue, so it may not map neatly to every embedded Chromium runtime. But the broader lesson is that Chromium vulnerabilities rarely stay confined to the icon users click.
Cross-Origin Data Is the Prize Attackers Keep Chasing
The web’s same-origin policy is one of the quiet miracles of modern computing. It lets hostile, benign, personal, corporate, and financial websites coexist in the same browser session without automatically exposing one another’s data. When that boundary fails, the browser stops being a neutral window and becomes a confused deputy.CVE-2026-11691 is described as a cross-origin data leak, not arbitrary code execution. That distinction matters, but it does not make the bug trivial. Cross-origin leakage can expose fragments of sensitive pages, authentication state, private metadata, or tokens depending on the exact bug and surrounding conditions. Even small leaks can be enough to defeat anti-CSRF assumptions, infer user identity, or guide a larger attack.
The industry has seen this pattern before. Spectre-era browser mitigations, site isolation, opaque response blocking, CORB, COOP, COEP, and related mechanisms all exist because the browser is constantly mediating between mutually distrusting origins. The modern web’s security model is layered precisely because no single layer is perfect.
A New Tab Page bug is especially uncomfortable because the page sits adjacent to browser-controlled features. Users do not think of it as a random website. They may trust it more, interact with it more casually, and leave it open constantly. That gives attackers a psychological angle even when the technical exploit path remains complex.
Google’s Sparse Advisory Is a Security Feature and a Frustration
Google’s Chrome security notes often give the public only a short description, a severity rating, affected versions, and bug links that remain restricted until enough users have patched. That restraint is intentional. Publishing detailed exploit mechanics before the installed base updates would hand attackers a recipe.For defenders, however, the result is a familiar frustration. Security teams must make prioritization decisions with incomplete information. They know the component, the general weakness class, the rough impact, and the fixed version. They do not know exploit reliability, exact data exposure, whether common mitigations reduce risk, or whether the issue was discovered through internal fuzzing, external research, or attack telemetry unless Google says so.
CVE-2026-11691 is not described as exploited in the wild. That separates it from other Chrome flaws in the same general update cycle that drew more urgent attention because of reported active exploitation. But “not known exploited” is not the same as “uninteresting.” Once a patch ships, attackers can diff code, study the fix, and determine whether the bug is useful against unpatched systems.
This is the patch gap that defenders live inside. The vendor knows enough to patch. Attackers may soon know enough to weaponize. Administrators are left trying to compress the time between those two states.
Windows Users Are Protected by Auto-Update Until They Are Not
For most home users on Windows, Chrome’s auto-update machinery is the best defense. It works quietly, frequently, and usually faster than user-driven patching ever could. The normal advice still applies: open Chrome’s About page, let it check for updates, and relaunch when prompted.But Windows environments have a long tail of exceptions. Users postpone relaunches. Businesses freeze updates during change-control windows. Remote desktops run stale browser sessions for weeks. Kiosks and shared machines are treated like appliances until someone audits them. Security tooling may report the installed version, while the running process remains an older build until restart.
That last point is easy to overlook. Updating the files on disk does not always mean every browser process in memory has been replaced. Chrome is better than many applications at nagging users to relaunch, but enterprises that care about browser risk should monitor both version compliance and restart behavior.
There is also the Windows habit of browser plurality. A user may have Chrome, Edge, Firefox, and a vendor-installed Chromium runtime all on the same machine. The default browser is not necessarily the only browser. Attackers do not care which icon the help desk prefers.
Enterprise Patch Management Needs Browser Urgency Without Browser Panic
The practical priority for CVE-2026-11691 is not to declare an emergency equal to an actively exploited remote code execution flaw. It is to avoid letting a browser boundary bug get buried because a score says Low. In mature environments, the right response is fast routine patching, not theatrical crisis management.A reasonable service-level target for managed browsers is measured in days, not weeks. Chrome and Edge are too exposed, too widely used, and too central to identity workflows to be treated like ordinary desktop software. The browser is now the front door to Microsoft 365, Google Workspace, Okta, Azure portals, SaaS dashboards, developer consoles, banking systems, and internal applications.
Security teams should also pay attention to who is most exposed. Developers, administrators, finance staff, executives, and help-desk personnel often carry sessions and privileges that make browser data leaks more consequential. A vulnerability that leaks only a little data from the wrong tab can still matter.
The browser has become the operating system for work. That sounds like a cliché until a New Tab Page validation bug reminds us that the browser’s internal surfaces are now part of the enterprise attack surface.
The Edge Question Is Really a Chromium Governance Question
Microsoft Edge complicates the story in a way that Windows readers should care about. Edge is not Chrome, but it is Chromium-based, and Microsoft regularly ingests Chromium security fixes while maintaining its own browser features, policies, and enterprise controls. That gives Windows administrators two responsibilities: follow Google’s Chromium security signal and verify Microsoft’s Edge-specific response.The industry has largely accepted Chromium monoculture as the cost of compatibility. Web developers get fewer rendering engines to test against. Users get consistent behavior. Enterprises get policy tooling and predictable updates. But the security trade-off is that a meaningful Chromium flaw can ripple through a huge share of the browser market.
That does not mean every Chromium CVE affects every Chromium-based browser in the same way. A New Tab Page issue may depend on Chrome-specific implementation details. Edge has its own new tab experience, services, and Microsoft integrations. But shared code, shared assumptions, and shared architectural patterns make “not Google-branded” a weak comfort.
The right stance is disciplined uncertainty. Check the Chrome fix because Chrome is the source advisory. Check Edge because Edge is likely present on every supported Windows machine. Check other Chromium-derived browsers because users install them whether IT approves or not.
The Real Risk Is Not This One CVE, But the Chain It Could Join
CVE-2026-11691 is best understood as an exploit-chain enabler. It does not appear to be the headline-grabbing first-stage bug that instantly compromises a machine from a single page load. Its value is subtler: after a renderer is compromised, it may permit data leakage across origins through a browser surface that should be carefully constrained.That kind of flaw is easy to under-communicate. Users understand “hackers can run code.” Executives understand “actively exploited zero-day.” Fewer people understand why a renderer-to-cross-origin leak matters. Yet sophisticated browser attacks are often built from exactly these pieces.
The security industry’s language does not help. “Insufficient validation of untrusted input” is technically accurate but emotionally inert. It covers everything from mundane parsing mistakes to boundary violations with serious consequences. A better operational translation would be: Chrome accepted something it should not have trusted in a sensitive browser-controlled surface, and under the right conditions that mistake could expose data from another origin.
That is the part worth remembering. The bug is not scary because the New Tab Page is glamorous. It is scary because the browser’s boring surfaces are where trust boundaries often become invisible.
What Administrators Should Do Before This Becomes Just Another Scanner Finding
The patch decision is straightforward: update Chrome and any Chromium-based browser fleet promptly, confirm relaunch, and watch vendor advisories for derivative products. The prioritization decision is more nuanced: do not let the low public CVSS score push this below the operational baseline for browser security updates.There is also a communications lesson. Telling users to “update Chrome” is not enough if the organization has trained them to ignore relaunch prompts. Browser patching should be treated as a normal part of endpoint hygiene, with clear expectations that updates may require restarting the browser even during the workday.
For administrators, the most useful controls are boring and measurable: enforced update policies, version reporting, browser restart deadlines, and visibility into unauthorized browsers. Those controls will not make headlines, but they close the window in which a patched Chromium bug remains exploitable in practice.
The New Tab Page Bug Leaves a Short Checklist for a Long-Tail Problem
CVE-2026-11691 is not the biggest Chrome vulnerability of the year, but it is a useful test of whether an organization understands browser risk beyond headline severity. The concrete actions are simple, and the policy implications are larger than this one flaw.- Chrome installations should be updated to a fixed build at or beyond the 149.0.7827.103 threshold described for this vulnerability.
- Managed Windows environments should verify that Chrome processes have actually relaunched after update deployment.
- Microsoft Edge and other Chromium-based browsers should be checked against their own vendor release channels rather than assumed safe or vulnerable by brand association alone.
- Vulnerability teams should avoid treating the low CISA-ADP CVSS score as a reason to defer routine browser patching.
- High-privilege users, including administrators and developers, should be prioritized because browser data leaks are more valuable when sensitive sessions are already open.
- Asset inventories should include secondary browsers and embedded Chromium runtimes where practical, even when the CVE is Chrome-specific.
References
- Primary source: NVD / Chromium
Published: 2026-06-15T19:14:55-07:00
NVD - CVE-2026-11691
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-15T19:14:55-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: vulnerability.circl.lu
Vulnerability-Lookup
Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.vulnerability.circl.lu - Related coverage: stack.watch
