Google Chrome before 149.0.7827.103 contains CVE-2026-11684, a high-severity Chromium Network flaw disclosed on June 8, 2026, that could let an attacker leak cross-origin data after compromising Chrome’s utility process through a crafted HTML page. The short version for Windows users is simple: update Chrome and any Chromium-based browser that ships the affected code. The longer version is more interesting, because this is a vulnerability whose public scoring looks oddly calm while its architectural implications are anything but. CVE-2026-11684 is a reminder that modern browser security is no longer just about blocking code execution; it is about enforcing boundaries after something has already gone wrong.
The key phrase in CVE-2026-11684 is not “crafted HTML page,” familiar though that is in browser advisories. It is “had compromised the utility process.” That wording tells us this bug was not described as a one-click, from-scratch browser takeover. Instead, it sits in the uncomfortable middle ground of modern exploit chains: after an attacker has already gained a foothold in a less-privileged Chrome process, the browser’s policy enforcement failed to fully contain what came next.
That distinction matters. Chrome’s multi-process architecture is designed around the assumption that individual processes may be attacked. Renderers parse hostile web content, utility processes handle delegated tasks, and the browser process is supposed to broker access to sensitive resources. The model is not “nothing will ever be compromised.” The model is “compromise should be boxed in.”
CVE-2026-11684 is therefore a boundary failure. The public description says insufficient policy enforcement in Chrome’s Network component allowed cross-origin data leakage. In web security terms, cross-origin is one of the foundational walls: a page from one site should not be able to freely read data from another site. When that wall weakens, the issue becomes less about theoretical purity and more about session-bearing, identity-rich browsing in the real world.
The severity mismatch is also worth reading carefully. Chromium labeled the issue High, while the CISA-ADP CVSS 3.1 score shown in the NVD entry is 3.1 Low, largely because the vector assumes high attack complexity and user interaction, with limited confidentiality impact. Both can be true in their own frames. CVSS is scoring a known description; Chrome’s security team is weighing the component, the browser’s threat model, and the possibility of exploit-chain usefulness.
Google’s linked Chromium issue requires permission, which is standard for recently fixed browser security bugs. That frustrates defenders who want root-cause detail, but it is also part of the browser security bargain. Vendors routinely restrict bug details until a large share of users have received the update, because the patch itself can become a roadmap for exploit developers.
The timing is straightforward. Chrome received the CVE on June 8, 2026, CISA-ADP modified the record later that day, and NIST added initial analysis on June 9. The affected range listed by NVD covers Google Chrome versions before 149.0.7827.103, with platform CPEs for Windows, Linux, and macOS included in the configuration logic.
That CPE structure can look odd at first glance, especially to administrators expecting one clean application CPE. NVD’s configuration shows Chrome as the vulnerable application and then ties it to operating-system platforms. In practical terms, the missing operational question is not whether Windows itself is vulnerable. It is whether the Chrome build deployed on Windows, macOS, or Linux is older than the fixed version.
Cross-origin data leakage is exactly the class of result browser isolation is meant to prevent. A hostile page should not be able to read another origin’s response merely because the browser has credentials, cookies, cached state, or network reachability that the attacker lacks. The user’s browser is often the most privileged network client in the room.
That is particularly true inside enterprises. A managed Windows workstation may have single sign-on tokens, intranet reachability, cloud admin portals, internal dashboards, and line-of-business apps all available from the same browser profile. If a compromised process can induce the browser to disclose cross-origin data that should have remained isolated, the browser becomes a confused deputy.
The CVE description does not claim full account takeover, arbitrary file access, or remote code execution. But information disclosure in the browser can still be powerful. Session context, internal API responses, CSRF-adjacent data, and user-specific content are often more valuable than defenders like to admit.
But browser vulnerabilities do not always fit neatly into single-CVE scoring. A bug that requires a compromised utility process may be unremarkable alone and highly valuable when paired with another flaw. Attackers do not experience CVSS as a moral law. They chain primitives.
That is why Chrome’s High severity matters. Google’s label reflects the bug in the context of Chromium’s architecture. If a utility process compromise is supposed to be contained, and a Network policy failure allows cross-origin leakage, the practical risk is the erosion of defense-in-depth.
For Windows admins, this is where vulnerability management dashboards can mislead. A Low CVSS score may sink below SLA thresholds even when the vendor severity says High. If an organization patches browsers only according to NVD base score, it will eventually underpatch exactly the sort of post-compromise containment bug that modern browser exploit chains depend on.
This is where defenders need to separate database completeness from exposure management. Chrome’s CPE tells scanners what to match for Google Chrome. It does not automatically guarantee accurate coverage for Microsoft Edge, Brave, Vivaldi, Opera, Electron-based apps, or embedded Chromium runtimes. Those products may consume Chromium code on different timelines, ship different version numbers, or patch the affected component under their own advisories.
For WindowsForum readers, Microsoft Edge is the obvious adjacent concern. Edge is Chromium-based, but it is not Google Chrome, and its update channel, versioning, enterprise controls, and advisory path are separate. A Chrome CVE is not automatically an Edge CVE in the administrative sense, even if the underlying code lineage makes the question reasonable.
That is why the best answer to “are we missing a CPE?” is cautious: for Google Chrome, the NVD configuration appears to describe the affected application and supported desktop platforms. For the wider Chromium ecosystem, asset owners should not wait for a single NVD entry to enumerate every downstream consumer before checking vendor-specific browser versions.
That makes browser patch latency a measurable business risk. A vulnerability like CVE-2026-11684 may sound narrow, but the data it threatens is exactly the data users reach through the browser all day. The browser is where SaaS identity, personal browsing, internal tools, and privileged admin workflows collide.
Chrome’s rapid update model helps, but only when it is allowed to work. Consumer systems often update quietly. Enterprise systems are more complicated: change freezes, app compatibility testing, third-party patch tools, VDI images, kiosk modes, and browser relaunch deferrals can all stretch exposure windows.
On Windows, the operational detail that matters is not simply whether the update was released. It is whether the running browser process has restarted into the fixed build. Chrome can download an update while still leaving the user on an older vulnerable executable until relaunch. That is a mundane detail, but browser security is full of mundane details that decide whether a patch exists in theory or in memory.
The relationship between the two should not be overstated. CVE-2026-11684 is a Network policy enforcement flaw; CVE-2026-11645 is a V8 memory-safety issue. They are different bugs. But they landed in the same update cycle, and together they illustrate the two-layer browser security problem: first prevent compromise, then contain compromise when prevention fails.
That is why defenders should avoid cherry-picking one CVE from the advisory and ignoring the rest. Browser updates are cumulative security events. Even when one vulnerability has the exploit-in-the-wild label and another does not, both may matter to the same real-world attacker workflow.
For administrators, the patch target is therefore the fixed Chrome release, not a single CVE mitigation. If Chrome is below the fixed build, the machine is carrying multiple known browser issues from that advisory set. CVE-2026-11684 is one reason to move; the broader update is the stronger reason not to wait.
A protection mechanism failure is often less dramatic than a buffer overflow, but it can be just as important. It says the system had a rule, and the rule did not hold under some condition. In Chrome’s case, those rules decide whether one origin can learn from another, whether a compromised process can ask for things it should not receive, and whether the browser’s internal services remain faithful to the user’s security context.
This is why browser hardening has moved beyond exploit mitigations alone. Site isolation, origin checks, network partitioning, cookie controls, CORB, CORS, fenced frames, storage partitioning, and process separation all try to reduce the blast radius of web content. Each feature adds protection, but each also adds policy complexity.
CVE-2026-11684 appears to live in that complexity. The public description does not give us the exact bypass path, but it gives enough to understand the genre. A compromised utility process should not be a passport to cross-origin data. If it became one under specific crafted-page conditions, the browser’s internal contract needed repair.
Users interact with web pages constantly. They click links in email, open tabs from chat apps, follow search results, preview documents, and authenticate into services. The browser is designed to accept untrusted input from the network and render it as something a human wants to engage with.
That does not mean CVE-2026-11684 is trivially exploitable. The high attack complexity and utility-process precondition are real constraints. But “crafted HTML page” plus “user interaction” should not lull anyone into dismissing the issue. The social engineering layer for browser exploits is already solved at Internet scale.
For security teams, the useful distinction is between opportunistic drive-by risk and targeted chaining risk. CVE-2026-11684 looks more like the latter based on the public description. That still matters for executives, developers, journalists, administrators, finance staff, and anyone else whose browser session contains data worth targeting.
Users can check Chrome’s update status through the About Chrome page. If an update is pending, apply it and restart the browser. If the browser says it is current, confirm the version is at or above the fixed stable release for the platform.
The same principle applies to Chromium-based alternatives. Do not assume a non-Google browser is safe because it does not display the exact Chrome version number. Check that vendor’s update page or built-in updater and make sure the browser has received a June 2026 security update incorporating the relevant Chromium fixes.
This is also a good moment to reduce browser session sprawl. Updating is the main fix, but users who keep dozens of authenticated tabs open for weeks are increasing the value of any future cross-origin leak. Browser hygiene is not a substitute for patching, yet it can reduce the prize available to the next exploit chain.
Enterprises should also watch for version fragmentation. It is common to find Chrome auto-updated on laptops, lagging in gold images, frozen in VDI pools, blocked on shared workstations, and duplicated inside application packages. The apparent simplicity of “update Chrome” hides a messy estate.
Managed Chrome deployments should enforce update policies that minimize relaunch delay. A browser that downloads an update but waits indefinitely for a restart is only halfway patched. IT teams need telemetry that distinguishes installed version, running version, and pending relaunch state.
Security teams should also map browser exposure to role risk. A kiosk in a lobby and a workstation used for cloud tenant administration do not carry the same consequence profile. CVE-2026-11684 is a confidentiality issue, and confidentiality impact depends heavily on whose browser session is exposed.
The old browser security story was dominated by remote code execution. The new story is layered. Attackers seek renderer bugs, sandbox escapes, process confusion, policy bypasses, credential access, and data leakage. Defenders need to patch across the entire chain, not only the most cinematic link.
For Windows environments, this means Chrome and Edge should be treated as continuously serviced components of the security perimeter. They are not just user applications. They are where authentication, cloud control planes, internal network access, and untrusted content converge.
The practical response is not panic. It is disciplined speed. Confirm the fixed build, force relaunch where appropriate, check managed browser telemetry, and do not let a low auxiliary CVSS score override the vendor’s high-severity signal.
Chrome’s Sandbox Is Only as Strong as Its Second Line of Defense
The key phrase in CVE-2026-11684 is not “crafted HTML page,” familiar though that is in browser advisories. It is “had compromised the utility process.” That wording tells us this bug was not described as a one-click, from-scratch browser takeover. Instead, it sits in the uncomfortable middle ground of modern exploit chains: after an attacker has already gained a foothold in a less-privileged Chrome process, the browser’s policy enforcement failed to fully contain what came next.That distinction matters. Chrome’s multi-process architecture is designed around the assumption that individual processes may be attacked. Renderers parse hostile web content, utility processes handle delegated tasks, and the browser process is supposed to broker access to sensitive resources. The model is not “nothing will ever be compromised.” The model is “compromise should be boxed in.”
CVE-2026-11684 is therefore a boundary failure. The public description says insufficient policy enforcement in Chrome’s Network component allowed cross-origin data leakage. In web security terms, cross-origin is one of the foundational walls: a page from one site should not be able to freely read data from another site. When that wall weakens, the issue becomes less about theoretical purity and more about session-bearing, identity-rich browsing in the real world.
The severity mismatch is also worth reading carefully. Chromium labeled the issue High, while the CISA-ADP CVSS 3.1 score shown in the NVD entry is 3.1 Low, largely because the vector assumes high attack complexity and user interaction, with limited confidentiality impact. Both can be true in their own frames. CVSS is scoring a known description; Chrome’s security team is weighing the component, the browser’s threat model, and the possibility of exploit-chain usefulness.
The Public Record Looks Sparse Because Browser Bugs Are Patched Under Embargo
The NVD entry for CVE-2026-11684 is still thin in the way many fresh browser CVEs are thin. NVD had not yet supplied its own CVSS 4.0 or 3.x assessment at the time of the entry, while CISA-ADP contributed CWE-693, Protection Mechanism Failure. That CWE is unusually descriptive here. This is not presented as a memory corruption primitive; it is framed as a failure of a protection mechanism to enforce a rule.Google’s linked Chromium issue requires permission, which is standard for recently fixed browser security bugs. That frustrates defenders who want root-cause detail, but it is also part of the browser security bargain. Vendors routinely restrict bug details until a large share of users have received the update, because the patch itself can become a roadmap for exploit developers.
The timing is straightforward. Chrome received the CVE on June 8, 2026, CISA-ADP modified the record later that day, and NIST added initial analysis on June 9. The affected range listed by NVD covers Google Chrome versions before 149.0.7827.103, with platform CPEs for Windows, Linux, and macOS included in the configuration logic.
That CPE structure can look odd at first glance, especially to administrators expecting one clean application CPE. NVD’s configuration shows Chrome as the vulnerable application and then ties it to operating-system platforms. In practical terms, the missing operational question is not whether Windows itself is vulnerable. It is whether the Chrome build deployed on Windows, macOS, or Linux is older than the fixed version.
The “Network” Component Is Where Browser Theory Meets Enterprise Reality
The Network service is not glamorous. It does not have the instant name recognition of V8, WebAssembly, WebGPU, or the renderer sandbox. But it is one of the places where browser architecture becomes operationally consequential, because it handles the movement of web data across trust boundaries.Cross-origin data leakage is exactly the class of result browser isolation is meant to prevent. A hostile page should not be able to read another origin’s response merely because the browser has credentials, cookies, cached state, or network reachability that the attacker lacks. The user’s browser is often the most privileged network client in the room.
That is particularly true inside enterprises. A managed Windows workstation may have single sign-on tokens, intranet reachability, cloud admin portals, internal dashboards, and line-of-business apps all available from the same browser profile. If a compromised process can induce the browser to disclose cross-origin data that should have remained isolated, the browser becomes a confused deputy.
The CVE description does not claim full account takeover, arbitrary file access, or remote code execution. But information disclosure in the browser can still be powerful. Session context, internal API responses, CSRF-adjacent data, and user-specific content are often more valuable than defenders like to admit.
The Low CVSS Score Should Not Become a Patch Deferral Excuse
The CVSS 3.1 vector published by CISA-ADP is AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N. That translates to a network-reachable issue requiring user interaction and high attack complexity, with low confidentiality impact and no direct integrity or availability impact. On paper, that is not the stuff of emergency change boards.But browser vulnerabilities do not always fit neatly into single-CVE scoring. A bug that requires a compromised utility process may be unremarkable alone and highly valuable when paired with another flaw. Attackers do not experience CVSS as a moral law. They chain primitives.
That is why Chrome’s High severity matters. Google’s label reflects the bug in the context of Chromium’s architecture. If a utility process compromise is supposed to be contained, and a Network policy failure allows cross-origin leakage, the practical risk is the erosion of defense-in-depth.
For Windows admins, this is where vulnerability management dashboards can mislead. A Low CVSS score may sink below SLA thresholds even when the vendor severity says High. If an organization patches browsers only according to NVD base score, it will eventually underpatch exactly the sort of post-compromise containment bug that modern browser exploit chains depend on.
The CPE Question Is Really an Asset Inventory Question
The user-facing NVD prompt asking whether a CPE is missing is easy to misread. The listed configuration already includes the Google Chrome application CPE up to, but excluding, 149.0.7827.103, and it includes platform CPEs for Windows, Linux, and macOS. That does not necessarily mean every Chromium derivative has been fully enumerated in the NVD record.This is where defenders need to separate database completeness from exposure management. Chrome’s CPE tells scanners what to match for Google Chrome. It does not automatically guarantee accurate coverage for Microsoft Edge, Brave, Vivaldi, Opera, Electron-based apps, or embedded Chromium runtimes. Those products may consume Chromium code on different timelines, ship different version numbers, or patch the affected component under their own advisories.
For WindowsForum readers, Microsoft Edge is the obvious adjacent concern. Edge is Chromium-based, but it is not Google Chrome, and its update channel, versioning, enterprise controls, and advisory path are separate. A Chrome CVE is not automatically an Edge CVE in the administrative sense, even if the underlying code lineage makes the question reasonable.
That is why the best answer to “are we missing a CPE?” is cautious: for Google Chrome, the NVD configuration appears to describe the affected application and supported desktop platforms. For the wider Chromium ecosystem, asset owners should not wait for a single NVD entry to enumerate every downstream consumer before checking vendor-specific browser versions.
Windows Shops Should Treat Browsers Like Tier-One Infrastructure
There was a time when browser patching could be treated as desktop hygiene. That time is over. Chrome, Edge, and their Chromium cousins are authentication clients, document viewers, password managers, application runtimes, device posture brokers, and increasingly the front end for enterprise administration.That makes browser patch latency a measurable business risk. A vulnerability like CVE-2026-11684 may sound narrow, but the data it threatens is exactly the data users reach through the browser all day. The browser is where SaaS identity, personal browsing, internal tools, and privileged admin workflows collide.
Chrome’s rapid update model helps, but only when it is allowed to work. Consumer systems often update quietly. Enterprise systems are more complicated: change freezes, app compatibility testing, third-party patch tools, VDI images, kiosk modes, and browser relaunch deferrals can all stretch exposure windows.
On Windows, the operational detail that matters is not simply whether the update was released. It is whether the running browser process has restarted into the fixed build. Chrome can download an update while still leaving the user on an older vulnerable executable until relaunch. That is a mundane detail, but browser security is full of mundane details that decide whether a patch exists in theory or in memory.
The Companion Zero-Day Makes the June Chrome Update Harder to Ignore
CVE-2026-11684 was not the only notable issue in the same Chrome security moment. Google’s June 2026 desktop stable update also drew attention because of CVE-2026-11645, a V8 out-of-bounds read and write issue that Google said had an exploit in the wild. That separate vulnerability is the headline-grabber because active exploitation changes the patching conversation immediately.The relationship between the two should not be overstated. CVE-2026-11684 is a Network policy enforcement flaw; CVE-2026-11645 is a V8 memory-safety issue. They are different bugs. But they landed in the same update cycle, and together they illustrate the two-layer browser security problem: first prevent compromise, then contain compromise when prevention fails.
That is why defenders should avoid cherry-picking one CVE from the advisory and ignoring the rest. Browser updates are cumulative security events. Even when one vulnerability has the exploit-in-the-wild label and another does not, both may matter to the same real-world attacker workflow.
For administrators, the patch target is therefore the fixed Chrome release, not a single CVE mitigation. If Chrome is below the fixed build, the machine is carrying multiple known browser issues from that advisory set. CVE-2026-11684 is one reason to move; the broader update is the stronger reason not to wait.
Policy Enforcement Bugs Are the Price of a More Compartmentalized Browser
Modern browsers are not monoliths anymore. They are distributed systems running on a single endpoint, with separate processes, sandboxes, brokers, services, and policy checks. That design is a security success story, but it also creates new classes of implementation failure.A protection mechanism failure is often less dramatic than a buffer overflow, but it can be just as important. It says the system had a rule, and the rule did not hold under some condition. In Chrome’s case, those rules decide whether one origin can learn from another, whether a compromised process can ask for things it should not receive, and whether the browser’s internal services remain faithful to the user’s security context.
This is why browser hardening has moved beyond exploit mitigations alone. Site isolation, origin checks, network partitioning, cookie controls, CORB, CORS, fenced frames, storage partitioning, and process separation all try to reduce the blast radius of web content. Each feature adds protection, but each also adds policy complexity.
CVE-2026-11684 appears to live in that complexity. The public description does not give us the exact bypass path, but it gives enough to understand the genre. A compromised utility process should not be a passport to cross-origin data. If it became one under specific crafted-page conditions, the browser’s internal contract needed repair.
The User Interaction Requirement Is Not Comforting in a Browser Bug
The CISA-ADP vector includes UI:R, meaning user interaction is required. In many software categories, that is a meaningful brake on exploitation. In browsers, it is closer to the default operating condition.Users interact with web pages constantly. They click links in email, open tabs from chat apps, follow search results, preview documents, and authenticate into services. The browser is designed to accept untrusted input from the network and render it as something a human wants to engage with.
That does not mean CVE-2026-11684 is trivially exploitable. The high attack complexity and utility-process precondition are real constraints. But “crafted HTML page” plus “user interaction” should not lull anyone into dismissing the issue. The social engineering layer for browser exploits is already solved at Internet scale.
For security teams, the useful distinction is between opportunistic drive-by risk and targeted chaining risk. CVE-2026-11684 looks more like the latter based on the public description. That still matters for executives, developers, journalists, administrators, finance staff, and anyone else whose browser session contains data worth targeting.
What Home Users Need to Do Is Boring, Which Is Good
For individual Windows users, the advice is refreshingly mundane: update Chrome, then relaunch it. The fixed version threshold in the NVD entry is 149.0.7827.103, though some platform-specific reporting around the same update cycle lists closely related 149.0.7827.102 and .103 builds depending on operating system. The safe posture is to let Chrome update to the latest available stable build rather than trying to reason from a single dotted version string.Users can check Chrome’s update status through the About Chrome page. If an update is pending, apply it and restart the browser. If the browser says it is current, confirm the version is at or above the fixed stable release for the platform.
The same principle applies to Chromium-based alternatives. Do not assume a non-Google browser is safe because it does not display the exact Chrome version number. Check that vendor’s update page or built-in updater and make sure the browser has received a June 2026 security update incorporating the relevant Chromium fixes.
This is also a good moment to reduce browser session sprawl. Updating is the main fix, but users who keep dozens of authenticated tabs open for weeks are increasing the value of any future cross-origin leak. Browser hygiene is not a substitute for patching, yet it can reduce the prize available to the next exploit chain.
Enterprise Patch Policy Needs to Follow Vendor Severity, Not Just CVSS
The most important operational lesson from CVE-2026-11684 is that vulnerability management systems need browser-specific logic. A Low CVSS score from one enrichment source should not automatically downgrade a Chromium High severity issue into the backlog. Browser flaws deserve a separate SLA because the browser is both Internet-facing and identity-rich.Enterprises should also watch for version fragmentation. It is common to find Chrome auto-updated on laptops, lagging in gold images, frozen in VDI pools, blocked on shared workstations, and duplicated inside application packages. The apparent simplicity of “update Chrome” hides a messy estate.
Managed Chrome deployments should enforce update policies that minimize relaunch delay. A browser that downloads an update but waits indefinitely for a restart is only halfway patched. IT teams need telemetry that distinguishes installed version, running version, and pending relaunch state.
Security teams should also map browser exposure to role risk. A kiosk in a lobby and a workstation used for cloud tenant administration do not carry the same consequence profile. CVE-2026-11684 is a confidentiality issue, and confidentiality impact depends heavily on whose browser session is exposed.
The June Chrome Patch Is a Small Test of Bigger Browser Discipline
CVE-2026-11684 will probably not become the most famous Chrome vulnerability of 2026. It lacks the public drama of a confirmed zero-day exploit and the technical magnetism of a V8 memory corruption bug. But it is exactly the sort of flaw that shows whether an organization understands how browsers fail now.The old browser security story was dominated by remote code execution. The new story is layered. Attackers seek renderer bugs, sandbox escapes, process confusion, policy bypasses, credential access, and data leakage. Defenders need to patch across the entire chain, not only the most cinematic link.
For Windows environments, this means Chrome and Edge should be treated as continuously serviced components of the security perimeter. They are not just user applications. They are where authentication, cloud control planes, internal network access, and untrusted content converge.
The practical response is not panic. It is disciplined speed. Confirm the fixed build, force relaunch where appropriate, check managed browser telemetry, and do not let a low auxiliary CVSS score override the vendor’s high-severity signal.
The Patch Window Is Where This CVE Will Be Won or Lost
CVE-2026-11684 does not require a grand strategic response, but it does reward teams that already have their browser patching house in order. The organizations that struggle will not be the ones that lack the advisory; they will be the ones that cannot tell which machines are still running the old process three days after the update landed.- Chrome installations older than 149.0.7827.103 should be treated as exposed to CVE-2026-11684 until updated and relaunched.
- The vulnerability is best understood as a post-compromise containment failure, not as a standalone browser takeover.
- The low CISA-ADP CVSS score should not outweigh Chromium’s High severity for browser patch prioritization.
- The NVD CPE entry appears to cover Google Chrome on desktop platforms, but Chromium-based downstream products still require vendor-specific verification.
- Enterprise administrators should track running browser versions and pending restarts, not merely whether an update package has arrived.
- The same June 2026 Chrome update cycle included a separately exploited V8 zero-day, making rapid deployment of the full stable update especially important.
References
- Primary source: NVD / Chromium
Published: 2026-06-15T19:14:46-07:00
NVD - CVE-2026-11684
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-15T19:14:46-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvepremium.circl.lu
Vulnerability-Lookup
Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.cvepremium.circl.lu - Official source: nvlpubs.nist.gov
Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4
The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. This publication, along with its annex (NIST Special Publication...nvlpubs.nist.gov
