CISA’s Known Exploited Vulnerabilities (KEV) Catalog continues to highlight a familiar pattern: vulnerabilities affecting network infrastructure, security appliances and management platforms are becoming operationally significant when exploitation is observed.
The latest additions around September 21–22, 2026 include vulnerabilities affecting Zyxel GS1900 switches, Arista VeloCloud Orchestrator, Check Point security infrastructure and F5 BIG-IP.
For security teams, these are not simply CVEs to add to a vulnerability backlog. They involve infrastructure that can sit directly on the network perimeter or control critical security functions.
1. Zyxel GS1900 — CVE-2026-7273
CVE-2026-7273 is a stack-based buffer overflow in the CGI program of the Zyxel GS1900-48HPv2 switch.
The vulnerability affects firmware versions through 2.90(ABTQ.1)C0 and can be triggered through a specially crafted HTTP request. An unauthenticated attacker with access to the adjacent network can potentially execute operating-system commands on the switch. The vulnerability carries a CVSS 3.1 score of 8.8.
The KEV addition is particularly significant because exploitation has moved beyond theoretical risk.
GreyNoise reported exploitation involving hundreds of compromised switches. Reporting indicates that attackers obtained configuration information, network information and hashed credentials from compromised devices.
Why it matters
A network switch is often treated as infrastructure rather than an application security asset. That makes vulnerabilities in its management interface easy to overlook.
Compromise of a switch can provide an attacker with:
- Network topology information
- Configuration data
- Credential material
- A foothold inside the network
- Potential opportunities for lateral movement
This makes network infrastructure vulnerability management just as important as endpoint and server patching.
2. Arista VeloCloud Orchestrator — CVE-2026-16812
CVE-2026-16812 affects VeloCloud Orchestrator (VCO) on-prem.
Arista describes the vulnerability as allowing a remote attacker to access privileged internal functionality that was intended only for internal use. Successful exploitation can affect the confidentiality, integrity and availability of the VCO host and the data managed by the orchestrator.
The vulnerability was significant enough to be exploited as a zero-day before the disclosure and remediation process progressed.
The affected architecture makes this particularly important: VCO is not simply another application server. It provides centralized orchestration and management capabilities for SD-WAN environments.
Why it matters
Compromising an orchestration platform can have a different blast radius from compromising an individual endpoint.
An attacker targeting the management plane may potentially gain visibility into:
- Managed network infrastructure
- Configuration information
- Connectivity relationships
- Administrative functionality
- Data handled by the orchestrator
The security boundary around the management plane therefore becomes critical.
Arista has stated that hosted and dedicated VCO versions were being actively patched, while the vulnerability specifically concerns on-premises VCO deployments.
3. Check Point — CVE-2026-85102
CVE-2026-85102 is a critical Check Point vulnerability involving improper certificate validation during VPN negotiation.
The vulnerability affects Check Point Security Gateway and Spark Firewall configurations using affected VPN functionality.
The vulnerability has a CVSS 3.1 score of 9.8, with network-based exploitation requiring neither authentication nor user interaction. Current vulnerability records identify it as a CISA KEV vulnerability.
The technical concern is particularly serious because the affected functionality operates at the VPN/security perimeter.
An attacker who can successfully exploit the vulnerability may be able to reach privileged functionality without first establishing legitimate authentication.
Why it matters
VPN gateways represent one of the most attractive attack surfaces in enterprise environments.
A vulnerability at this layer can potentially turn:
Internet exposure → perimeter compromise → internal access
into a much shorter attack path.
Check Point has issued security fixes and recommended customers apply the relevant security updates.
4. Check Point — CVE-2026-93616
The second Check Point vulnerability, CVE-2026-93616, affects the management side of the security infrastructure.
This is important because Check Point environments generally separate the security enforcement plane from the management plane.
A vulnerability in management infrastructure can have consequences beyond an individual firewall because management systems can control policies and configurations across multiple security gateways.
The broader lesson is important:
Protecting the firewall is not enough if the system that controls the firewall remains exposed.
Security teams should therefore validate both gateway and management-server exposure when responding to Check Point KEV entries.
5. F5 BIG-IP — CVE-2026-9501
The F5 vulnerability affects BIG-IP infrastructure and is particularly relevant to organizations using BIG-IP as an application delivery, access or security platform.
BIG-IP systems frequently sit at strategic points in enterprise architecture, including:
- Application delivery
- Reverse proxy
- Traffic management
- Authentication and access control
- Internet-facing services
A vulnerability affecting this layer therefore deserves infrastructure-level treatment rather than ordinary application vulnerability prioritization.
For F5 environments, teams should identify whether affected BIG-IP modules and configurations are deployed, validate the applicable vendor fix, and review externally accessible management and application interfaces.
The Common Pattern
These vulnerabilities appear across different vendors, but they share an important architectural characteristic.
They affect control points.
Zyxel provides network connectivity.
Arista VeloCloud provides network orchestration.
Check Point provides security enforcement and management.
F5 provides application and traffic infrastructure.
These are systems that sit between users, applications and networks.
That makes their compromise potentially more consequential than the compromise of an isolated endpoint.
The Vulnerability Management Takeaway
A KEV entry should immediately change the operational treatment of a vulnerability.
The workflow should move from:
Identify → Assess → Prioritize → Patch
to:
Identify → Confirm Exposure → Contain → Hunt → Patch → Validate
For these vulnerabilities, security teams should specifically validate:
1. Asset exposure
Identify every affected product and version across:
- CMDB
- Vulnerability scanners
- Cloud inventories
- Network discovery
- Configuration management
- External attack-surface monitoring
2. Internet exposure
Determine whether the vulnerable interface is:
- Internet-facing
- VPN-accessible
- Management-accessible
- Reachable from untrusted network segments
3. Exploitation evidence
Search for:
- Suspicious authentication activity
- Unexpected administrative sessions
- Abnormal configuration changes
- Unknown accounts
- Unexpected outbound connections
- Web/API exploitation indicators
- Changes to VPN or security policies
4. Patch validation
Do not stop at deployment.
Confirm:
Vulnerable version → Fixed version → Successful deployment → Rescan → Exposure closed
This is where vulnerability management becomes measurable remediation rather than simply ticket closure.
Final Takeaway
The latest KEV activity reinforces a critical security principle:
The most dangerous vulnerability is not necessarily the one with the highest CVSS score. It is the one that combines known exploitation with an exposed control point in your environment.
Network switches, SD-WAN orchestrators, security gateways and application delivery platforms are all part of the enterprise control plane.
When one of these technologies enters the KEV catalog, the question should not be:
“Do we have this CVE?”
The better question is:
“Where is this vulnerable control point, who can reach it, what does it control, and can we prove that exploitation has not already occurred?”
That is the difference between vulnerability tracking and exposure-driven vulnerability management.
