CISA added CVE-2026-7473 in Arista EOS, CVE-2026-11645 in Google Chromium V8, and CVE-2026-20245 in Cisco Catalyst SD-WAN Manager to its Known Exploited Vulnerabilities Catalog on June 9, 2026, after determining that all three are being actively exploited in the wild. The agency’s move is not just another patching reminder; it is a map of where attackers are spending time now. One bug sits in the browser, one in the switching fabric, and one in the SD-WAN management plane. Together, they show how modern compromise increasingly runs through the connective tissue of enterprise computing rather than through the old caricature of a single infected desktop.
The Known Exploited Vulnerabilities Catalog is often treated as a government spreadsheet, but that undersells its practical importance. Once a flaw lands there, it stops being an abstract CVE and becomes a federally recognized exploitation problem. For Federal Civilian Executive Branch agencies, that distinction triggers Binding Operational Directive 22-01 and the requirement to remediate by CISA’s due date.
For everyone else, the KEV catalog has become a rough-and-ready triage layer. Security teams already drowning in scanner output use it to separate vulnerabilities that merely exist from vulnerabilities that adversaries have actually used. That is a blunt instrument, but blunt instruments have value when the patch queue is longer than the maintenance window.
This June 9 update is notable because the three additions do not share a single product category. They cut across network switching, web browsing, and centralized WAN orchestration. That spread matters because it mirrors the way attackers increasingly assemble campaigns: initial access through one layer, privilege or reach through another, and persistence through whatever management plane gives them the broadest control.
The phrase “known exploited” should also be read carefully. CISA is not saying that every exposed Arista switch, Chrome browser, or Cisco SD-WAN Manager is compromised. It is saying the threshold has been crossed where real-world exploitation evidence exists, and defenders should stop waiting for perfect telemetry before acting.
The public description is terse: an out-of-bounds read and write vulnerability that could allow a remote attacker to potentially exploit heap corruption through a crafted HTML page. That phrasing hides the practical reality. The browser is still the application most users leave open all day, the one that crosses corporate, personal, SaaS, and authentication boundaries with almost no ceremony.
For Windows administrators, the Chrome angle is deceptively simple: update the browser. In managed environments, however, that means verifying update rings, third-party patch catalogs, browser restart behavior, and the long tail of machines that are technically “managed” but rarely rebooted. A browser zero-day is rarely defeated by an update being merely available.
The Chromium dependency chain also complicates the story. Google Chrome may be the named product in many advisories, but Chromium code flows through Microsoft Edge, Brave, Vivaldi, Electron-based applications, and embedded browser controls. Not every downstream product is affected in the same way or on the same schedule, but the lesson for IT is broader than “check Chrome.” The lesson is to inventory where browser engines actually live.
There is a Windows-specific sting here. Microsoft has spent years making Edge a system-adjacent browser rather than a removable accessory, while enterprises have standardized on web apps for everything from identity to payroll to device management. The browser is no longer merely a user application. It is a privileged work surface where credentials, session tokens, and business workflows converge.
The issue concerns affected Arista EOS platforms using tunnel decapsulation configurations such as VXLAN, decap-groups, or GRE tunnel interfaces. Under vulnerable conditions, a switch may incorrectly decapsulate and forward unexpected tunneled traffic when the destination IP matches a configured decapsulation IP. In plain English, the switch can be fooled about which tunneled packets deserve to be unpacked and forwarded.
That is not a desktop exploit. It is a fabric-level trust problem. VXLAN and GRE are used to stretch networks, encapsulate traffic, and build overlay designs that make modern data centers and service provider environments flexible. When decapsulation logic is too permissive, the attack surface is not a login screen; it is the packet path itself.
The risk calculus depends heavily on topology. A small shop with no affected tunnel configuration may have little exposure. A large enterprise, cloud-adjacent environment, carrier, or multi-tenant data center using overlays has a more serious question to answer: could unexpected tunneled traffic be introduced from a network position that attackers can reach?
This is where KEV status changes the conversation. A vulnerability that might otherwise be deferred because it lacks a dramatic CVSS number now has evidence of exploitation attached to it. That does not automatically make it the highest-risk flaw in every environment, but it does make “we will get to it next quarter” harder to defend.
The authentication requirement is important, but it is not comforting. Many serious enterprise compromises are built from chained weaknesses, stolen credentials, exposed management interfaces, or previously obtained footholds. Once an attacker has the right level of access to an SD-WAN manager, the goal is no longer to compromise one server; it is to influence the system that tells branches, edges, and policies how to behave.
That is why SD-WAN vulnerabilities have a different blast radius than ordinary application bugs. A compromised management plane can become a route into configuration manipulation, persistence, traffic visibility, and lateral movement. The most dangerous part is not always the exploited appliance itself, but the authority the appliance holds over the network.
Cisco’s SD-WAN security story has already been under scrutiny this year because earlier Catalyst SD-WAN issues involved high-impact authentication and control-plane concerns. CVE-2026-20245 fits into that broader pattern even if the mechanics differ. Attackers are not merely probing edge devices for opportunistic wins; they are looking for infrastructure that grants administrative leverage.
For administrators, the uncomfortable part is that “patch now” may not be a complete answer when a vendor fix is pending or when the exploitable path depends on chained conditions. In those cases, the work shifts to containment: restricting access to management interfaces, auditing privileged accounts, reviewing logs, checking for suspicious file activity, and validating that managed device configurations have not been tampered with.
The KEV catalog cuts through some of that noise by asking a narrower question: is this being exploited? That does not make it a perfect prioritization system. Some exploited flaws affect products an organization does not run, while some non-KEV vulnerabilities may be devastating in a specific environment. But KEV status is a strong signal that the vulnerability has crossed from theoretical risk into adversary workflow.
This matters especially for Windows-heavy organizations because Windows endpoints are often the visible layer while the real dependencies sit elsewhere. A user’s browser, an identity provider, a VPN, an SD-WAN controller, a switching fabric, and an endpoint management system are all part of the same risk surface. The Windows machine may be where the symptom appears, but not necessarily where the compromise began.
The June 9 additions reinforce that patch management cannot be reduced to Windows Update compliance. That remains essential, of course, but it is only one lane. Browser engines, network operating systems, and infrastructure controllers have their own update cadences, approval chains, and outage risks. Attackers know this, which is why they like systems that are essential enough to be everywhere and delicate enough to patch slowly.
There is also a cultural lesson. CVE names make vulnerabilities look interchangeable, as though each one were a ticket in the same backlog. These three are not interchangeable. One is a client-side exposure likely to be touched by ordinary browsing, one is a network encapsulation flaw with topology-dependent consequences, and one is a management-plane privilege escalation issue with potentially broad administrative implications.
Modern Windows environments are no longer bounded by the operating system image. A domain-joined laptop may authenticate through cloud identity, browse to SaaS applications, route traffic through SD-WAN edges, and rely on network segmentation implemented by switches whose configurations are centrally orchestrated. The endpoint is one participant in a distributed control system.
That makes infrastructure flaws more relevant to Windows users than they may appear. If an SD-WAN controller is compromised, Windows clients can be redirected, isolated, monitored, or exposed in ways that endpoint hardening alone cannot prevent. If a network overlay mis-handles tunneled traffic, the segmentation assumptions that protect Windows servers and workstations may be weaker than the access control diagrams suggest.
For sysadmins, this is why cross-team coordination matters. The desktop team may own Chrome. The network team may own Arista EOS. The WAN team may own Cisco Catalyst SD-WAN Manager. The security team may own vulnerability prioritization but not the change windows. CISA’s catalog collapses those organizational boundaries because attackers do not care which team owns the vulnerable component.
The best response is not panic; it is sequencing. Patch the browser rapidly because user exposure is broad and the update path is mature. Assess Arista exposure based on affected platforms and tunnel configurations rather than product name alone. Treat Cisco SD-WAN Manager as a control-plane incident risk, not merely a software defect, especially where privileged access or prior SD-WAN vulnerabilities may create a chain.
The result is an awkward middle ground for IT teams. They have enough information to act but not always enough to feel certain. That is especially true when exploitation is targeted, when proof-of-concept code is not public, or when vendor advisories avoid describing exploit mechanics in detail.
CVE-2026-11645 follows a familiar browser-zero-day pattern: limited technical disclosure, an urgent update, and acknowledgment that exploitation exists. The lack of detail should not be misread as lack of seriousness. Browser vendors routinely restrict exploit details until users have had time to patch, and V8 bugs have a long history of being valuable to sophisticated attackers.
CVE-2026-7473 is different because the exposure depends on network design. An organization needs to know whether affected EOS versions and tunnel decapsulation features are present, whether untrusted traffic can reach relevant decapsulation IPs, and whether mitigations such as access control changes can be safely applied. That is not a one-click answer.
CVE-2026-20245 is different again because the exploit path involves authenticated access and root command execution. Defenders must think in terms of chains: how an attacker could obtain or abuse the necessary privileges, whether earlier SD-WAN vulnerabilities are relevant, and what forensic traces might indicate that the manager has already been used as a pivot.
For Chrome and Chromium-derived browsers, the practical step is version verification across the fleet. Administrators should not rely on policy intent or update-channel assumptions. They need reporting that shows installed versions, pending restarts, failed updates, and unmanaged browsers that escaped the normal deployment process.
For Arista EOS, remediation begins with determining whether the affected decapsulation scenarios exist. Network teams should review EOS versions, platform exposure, VXLAN and GRE usage, decap-group configurations, and any vendor-recommended fixed releases or mitigations. Because forwarding behavior is involved, changes should be tested carefully, but KEV status argues against letting caution become inertia.
For Cisco Catalyst SD-WAN Manager, the response has to include access control and compromise assessment. If a management plane vulnerability is being exploited, simply waiting for a fix or applying a future update may leave behind unauthorized changes, rogue accounts, persistence mechanisms, or altered configurations. The manager’s logs and the state of managed devices become part of the evidence.
The strongest organizations will treat this CISA update as an exercise in dependency mapping. Which browsers are actually in use? Which network overlays exist? Which SD-WAN managers are reachable, by whom, and from where? Which teams can make changes quickly without breaking production? Those questions are less glamorous than exploit analysis, but they determine whether a warning becomes action.
CISA will keep adding exploited vulnerabilities to the catalog, and vendors will keep issuing advisories that arrive faster than most organizations can comfortably absorb. The winners will not be the teams with the longest scanner reports or the prettiest dashboards, but the ones that can turn a short KEV entry into a fast, cross-functional decision about exposure, remediation, and evidence. This June 9 update is a reminder that the attack surface has become a system of systems — and defending Windows well now means understanding the infrastructure that Windows quietly depends on.
CISA Turns Three Vendor Advisories Into an Operational Deadline
The Known Exploited Vulnerabilities Catalog is often treated as a government spreadsheet, but that undersells its practical importance. Once a flaw lands there, it stops being an abstract CVE and becomes a federally recognized exploitation problem. For Federal Civilian Executive Branch agencies, that distinction triggers Binding Operational Directive 22-01 and the requirement to remediate by CISA’s due date.For everyone else, the KEV catalog has become a rough-and-ready triage layer. Security teams already drowning in scanner output use it to separate vulnerabilities that merely exist from vulnerabilities that adversaries have actually used. That is a blunt instrument, but blunt instruments have value when the patch queue is longer than the maintenance window.
This June 9 update is notable because the three additions do not share a single product category. They cut across network switching, web browsing, and centralized WAN orchestration. That spread matters because it mirrors the way attackers increasingly assemble campaigns: initial access through one layer, privilege or reach through another, and persistence through whatever management plane gives them the broadest control.
The phrase “known exploited” should also be read carefully. CISA is not saying that every exposed Arista switch, Chrome browser, or Cisco SD-WAN Manager is compromised. It is saying the threshold has been crossed where real-world exploitation evidence exists, and defenders should stop waiting for perfect telemetry before acting.
The Browser Bug Is the One Windows Users Will Feel First
For most WindowsForum readers, CVE-2026-11645 is the most immediately familiar entry. It affects Google Chromium’s V8 engine, the JavaScript and WebAssembly runtime that underpins Chrome and, by extension, much of the modern browser ecosystem. A memory safety flaw in V8 is the kind of bug that turns ordinary web content into a potential execution path.The public description is terse: an out-of-bounds read and write vulnerability that could allow a remote attacker to potentially exploit heap corruption through a crafted HTML page. That phrasing hides the practical reality. The browser is still the application most users leave open all day, the one that crosses corporate, personal, SaaS, and authentication boundaries with almost no ceremony.
For Windows administrators, the Chrome angle is deceptively simple: update the browser. In managed environments, however, that means verifying update rings, third-party patch catalogs, browser restart behavior, and the long tail of machines that are technically “managed” but rarely rebooted. A browser zero-day is rarely defeated by an update being merely available.
The Chromium dependency chain also complicates the story. Google Chrome may be the named product in many advisories, but Chromium code flows through Microsoft Edge, Brave, Vivaldi, Electron-based applications, and embedded browser controls. Not every downstream product is affected in the same way or on the same schedule, but the lesson for IT is broader than “check Chrome.” The lesson is to inventory where browser engines actually live.
There is a Windows-specific sting here. Microsoft has spent years making Edge a system-adjacent browser rather than a removable accessory, while enterprises have standardized on web apps for everything from identity to payroll to device management. The browser is no longer merely a user application. It is a privileged work surface where credentials, session tokens, and business workflows converge.
Arista’s Tunnel Bug Shows Why “Medium” Severity Can Still Matter
CVE-2026-7473, the Arista Extensible Operating System vulnerability, is the quietest of the three additions and may be the easiest to misread. Its score is not the kind that makes executives call emergency meetings. Its impact language is narrower than a remote code execution bug. But in network infrastructure, routing and forwarding mistakes can be strategically valuable even when they do not hand over a shell.The issue concerns affected Arista EOS platforms using tunnel decapsulation configurations such as VXLAN, decap-groups, or GRE tunnel interfaces. Under vulnerable conditions, a switch may incorrectly decapsulate and forward unexpected tunneled traffic when the destination IP matches a configured decapsulation IP. In plain English, the switch can be fooled about which tunneled packets deserve to be unpacked and forwarded.
That is not a desktop exploit. It is a fabric-level trust problem. VXLAN and GRE are used to stretch networks, encapsulate traffic, and build overlay designs that make modern data centers and service provider environments flexible. When decapsulation logic is too permissive, the attack surface is not a login screen; it is the packet path itself.
The risk calculus depends heavily on topology. A small shop with no affected tunnel configuration may have little exposure. A large enterprise, cloud-adjacent environment, carrier, or multi-tenant data center using overlays has a more serious question to answer: could unexpected tunneled traffic be introduced from a network position that attackers can reach?
This is where KEV status changes the conversation. A vulnerability that might otherwise be deferred because it lacks a dramatic CVSS number now has evidence of exploitation attached to it. That does not automatically make it the highest-risk flaw in every environment, but it does make “we will get to it next quarter” harder to defend.
Cisco’s SD-WAN Manager Flaw Aims at the Control Plane
CVE-2026-20245 is the most operationally ominous of the trio because it affects Cisco Catalyst SD-WAN Manager, formerly known as vManage. The vulnerability is described as an improper encoding or escaping issue in the command-line interface that can allow an authenticated local attacker to execute arbitrary commands as root by supplying a crafted file. Cisco rated the issue high severity, and public reporting has described active exploitation with no immediate workaround at the time of disclosure.The authentication requirement is important, but it is not comforting. Many serious enterprise compromises are built from chained weaknesses, stolen credentials, exposed management interfaces, or previously obtained footholds. Once an attacker has the right level of access to an SD-WAN manager, the goal is no longer to compromise one server; it is to influence the system that tells branches, edges, and policies how to behave.
That is why SD-WAN vulnerabilities have a different blast radius than ordinary application bugs. A compromised management plane can become a route into configuration manipulation, persistence, traffic visibility, and lateral movement. The most dangerous part is not always the exploited appliance itself, but the authority the appliance holds over the network.
Cisco’s SD-WAN security story has already been under scrutiny this year because earlier Catalyst SD-WAN issues involved high-impact authentication and control-plane concerns. CVE-2026-20245 fits into that broader pattern even if the mechanics differ. Attackers are not merely probing edge devices for opportunistic wins; they are looking for infrastructure that grants administrative leverage.
For administrators, the uncomfortable part is that “patch now” may not be a complete answer when a vendor fix is pending or when the exploitable path depends on chained conditions. In those cases, the work shifts to containment: restricting access to management interfaces, auditing privileged accounts, reviewing logs, checking for suspicious file activity, and validating that managed device configurations have not been tampered with.
KEV Is Becoming the Patch Queue’s Reality Check
The security industry still talks about vulnerability management as though organizations are choosing between known good options. In reality, IT teams are choosing between different forms of incompleteness. Asset inventories miss systems. Scanners disagree. Maintenance windows slip. Vendors publish mitigations that are operationally painful or fixes that require major version jumps.The KEV catalog cuts through some of that noise by asking a narrower question: is this being exploited? That does not make it a perfect prioritization system. Some exploited flaws affect products an organization does not run, while some non-KEV vulnerabilities may be devastating in a specific environment. But KEV status is a strong signal that the vulnerability has crossed from theoretical risk into adversary workflow.
This matters especially for Windows-heavy organizations because Windows endpoints are often the visible layer while the real dependencies sit elsewhere. A user’s browser, an identity provider, a VPN, an SD-WAN controller, a switching fabric, and an endpoint management system are all part of the same risk surface. The Windows machine may be where the symptom appears, but not necessarily where the compromise began.
The June 9 additions reinforce that patch management cannot be reduced to Windows Update compliance. That remains essential, of course, but it is only one lane. Browser engines, network operating systems, and infrastructure controllers have their own update cadences, approval chains, and outage risks. Attackers know this, which is why they like systems that are essential enough to be everywhere and delicate enough to patch slowly.
There is also a cultural lesson. CVE names make vulnerabilities look interchangeable, as though each one were a ticket in the same backlog. These three are not interchangeable. One is a client-side exposure likely to be touched by ordinary browsing, one is a network encapsulation flaw with topology-dependent consequences, and one is a management-plane privilege escalation issue with potentially broad administrative implications.
The Windows Angle Is Bigger Than Chrome
It is tempting for a Windows audience to focus almost entirely on the Chromium V8 issue because that is the part most users can act on immediately. Update Chrome, update Edge when applicable, restart the browser, and verify fleet compliance. That is necessary, but it is not sufficient.Modern Windows environments are no longer bounded by the operating system image. A domain-joined laptop may authenticate through cloud identity, browse to SaaS applications, route traffic through SD-WAN edges, and rely on network segmentation implemented by switches whose configurations are centrally orchestrated. The endpoint is one participant in a distributed control system.
That makes infrastructure flaws more relevant to Windows users than they may appear. If an SD-WAN controller is compromised, Windows clients can be redirected, isolated, monitored, or exposed in ways that endpoint hardening alone cannot prevent. If a network overlay mis-handles tunneled traffic, the segmentation assumptions that protect Windows servers and workstations may be weaker than the access control diagrams suggest.
For sysadmins, this is why cross-team coordination matters. The desktop team may own Chrome. The network team may own Arista EOS. The WAN team may own Cisco Catalyst SD-WAN Manager. The security team may own vulnerability prioritization but not the change windows. CISA’s catalog collapses those organizational boundaries because attackers do not care which team owns the vulnerable component.
The best response is not panic; it is sequencing. Patch the browser rapidly because user exposure is broad and the update path is mature. Assess Arista exposure based on affected platforms and tunnel configurations rather than product name alone. Treat Cisco SD-WAN Manager as a control-plane incident risk, not merely a software defect, especially where privileged access or prior SD-WAN vulnerabilities may create a chain.
“Actively Exploited” Does Not Mean “Fully Explained”
One frustration with KEV entries is that they often arrive with limited public detail. CISA confirms exploitation, names the vulnerability, and imposes urgency, but it rarely tells defenders everything they want to know about the campaigns behind the exploitation. That restraint is understandable. Revealing too much can help attackers, compromise investigations, or expose victims.The result is an awkward middle ground for IT teams. They have enough information to act but not always enough to feel certain. That is especially true when exploitation is targeted, when proof-of-concept code is not public, or when vendor advisories avoid describing exploit mechanics in detail.
CVE-2026-11645 follows a familiar browser-zero-day pattern: limited technical disclosure, an urgent update, and acknowledgment that exploitation exists. The lack of detail should not be misread as lack of seriousness. Browser vendors routinely restrict exploit details until users have had time to patch, and V8 bugs have a long history of being valuable to sophisticated attackers.
CVE-2026-7473 is different because the exposure depends on network design. An organization needs to know whether affected EOS versions and tunnel decapsulation features are present, whether untrusted traffic can reach relevant decapsulation IPs, and whether mitigations such as access control changes can be safely applied. That is not a one-click answer.
CVE-2026-20245 is different again because the exploit path involves authenticated access and root command execution. Defenders must think in terms of chains: how an attacker could obtain or abuse the necessary privileges, whether earlier SD-WAN vulnerabilities are relevant, and what forensic traces might indicate that the manager has already been used as a pivot.
The Real Work Starts After the Patch Is Installed
The phrase “timely remediation” sounds cleaner than the work it describes. In practice, remediation may mean updating software, applying configuration changes, restricting access, rotating credentials, auditing logs, validating backups, and checking whether compromise already occurred. A vulnerability with active exploitation is not just a future-risk problem; it may be a past-tense investigation.For Chrome and Chromium-derived browsers, the practical step is version verification across the fleet. Administrators should not rely on policy intent or update-channel assumptions. They need reporting that shows installed versions, pending restarts, failed updates, and unmanaged browsers that escaped the normal deployment process.
For Arista EOS, remediation begins with determining whether the affected decapsulation scenarios exist. Network teams should review EOS versions, platform exposure, VXLAN and GRE usage, decap-group configurations, and any vendor-recommended fixed releases or mitigations. Because forwarding behavior is involved, changes should be tested carefully, but KEV status argues against letting caution become inertia.
For Cisco Catalyst SD-WAN Manager, the response has to include access control and compromise assessment. If a management plane vulnerability is being exploited, simply waiting for a fix or applying a future update may leave behind unauthorized changes, rogue accounts, persistence mechanisms, or altered configurations. The manager’s logs and the state of managed devices become part of the evidence.
The strongest organizations will treat this CISA update as an exercise in dependency mapping. Which browsers are actually in use? Which network overlays exist? Which SD-WAN managers are reachable, by whom, and from where? Which teams can make changes quickly without breaking production? Those questions are less glamorous than exploit analysis, but they determine whether a warning becomes action.
The June 9 KEV Update Draws a Map of the Attack Surface
CISA’s three additions are not equally urgent for every organization, but they are concrete enough to drive immediate decisions. The common thread is exploitation pressure against widely trusted layers: browsers, network fabrics, and management planes.- Organizations should verify Chrome and Chromium-based browser versions across managed and unmanaged Windows systems, not merely assume that automatic updates have completed.
- Network teams running Arista EOS should determine whether affected platforms use VXLAN, GRE, decap-groups, or other relevant tunnel decapsulation configurations.
- Cisco Catalyst SD-WAN Manager deployments should be treated as high-value control-plane assets requiring restricted access, privileged-account review, and log analysis.
- KEV status should move these vulnerabilities ahead of similarly scored but non-exploited flaws in ordinary patch queues.
- Remediation should include compromise checks where exploitation could have produced configuration changes, persistence, or administrative abuse before the fix was applied.
- Security teams should use this update to test whether browser, network, and WAN ownership boundaries slow down emergency response.
CISA will keep adding exploited vulnerabilities to the catalog, and vendors will keep issuing advisories that arrive faster than most organizations can comfortably absorb. The winners will not be the teams with the longest scanner reports or the prettiest dashboards, but the ones that can turn a short KEV entry into a fast, cross-functional decision about exposure, remediation, and evidence. This June 9 update is a reminder that the attack surface has become a system of systems — and defending Windows well now means understanding the infrastructure that Windows quietly depends on.
References
- Primary source: CISA
Published: 2026-06-09T12:00:00+00:00
- Related coverage: brightnexus.com
[CVE-2026-20245] Cisco SD-WAN 0-day exploited, no patch available | Bright Nexus
Severity High Detail Cisco has disclosed an actively exploited privilege escalation vulnerability, tracked as CVE-2026-20245, affecting Cisco Catalyst SD-WAN Mawww.brightnexus.com
- Related coverage: thecybersignal.com
Cisco SD-WAN Manager 0-Day CVE-2026-20245 Exploited
Cisco warns that CVE-2026-20245, a zero-day in Catalyst SD-WAN Manager, is being exploited to gain root, with no patch available. Exploitation needs netadmin access — obtainable by chaining CVE-2026-20182 — making it Cisco's seventh exploited SD-WAN zero-day of 2026.
www.thecybersignal.com
- Related coverage: techradar.com
Google patches worrying Chrome zero-day flaw being exploited in the wild - here's how to stay safe
A bug in Google Chrome V8 allowed for arbitrary code executionwww.techradar.com
- Related coverage: abit.ee
Cisco SD-WAN zero-day CVE-2026-20245 actively exploited - no patch available
Cisco warns of active exploitation of CVE-2026-20245 in Catalyst SD-WAN Manager. CVSS 7.8, no patch available. Attackers have already modified edge device configurations.abit.ee
- Related coverage: digital.nhs.uk
