The Cybersecurity and Infrastructure Security Agency added two new vulnerabilities to its Known Exploited Vulnerabilities catalog on July 27, based on confirmed evidence of active exploitation: CVE-2025-68686, an exposure of sensitive information vulnerability in Fortinet FortiOS, and CVE-2026-16812, an OS command injection vulnerability in Arista VeloCloud Orchestrator On-Prem. If your organization runs Fortinet firewalls or Arista's SD-WAN orchestration platform anywhere in your network edge, this KEV addition isn't background noise — it's a specific, time-bound compliance and risk obligation, even if you're not a federal agency bound by CISA's directive.
What actually triggers a KEV catalog addition
CISA doesn't add vulnerabilities to the KEV catalog based on theoretical severity alone — a CVE only qualifies once CISA has confirmed evidence of real-world, in-the-wild exploitation, not just a high CVSS score or a published proof-of-concept. That distinction matters for prioritization: a KEV listing means attackers are actively using this vulnerability against real targets right now, which is a fundamentally different risk category than a critical-severity bug that's merely theoretically exploitable. Both CVE-2025-68686 and CVE-2026-16812 cleared that bar, which is why they landed on the list together on the same day.
The Fortinet vulnerability: information exposure with outsized consequences
CVE-2025-68686 is classified as an exposure of sensitive information vulnerability in FortiOS, Fortinet's operating system running across its firewall and network security appliance line. Information exposure vulnerabilities are frequently underestimated relative to remote code execution bugs, but in a network security appliance specifically, exposed sensitive information — configuration data, credentials, session tokens, or internal network topology — routinely becomes the reconnaissance step that enables a subsequent, more damaging attack. Fortinet appliances have been a recurring target throughout 2026 for exactly this reason: they sit at the network perimeter, they're widely deployed across enterprises of every size, and a single exploited vulnerability in the appliance managing your network edge has a disproportionately large blast radius compared to the same vulnerability class in an internal application.
The Arista vulnerability: command injection in SD-WAN orchestration
CVE-2026-16812 is an OS command injection vulnerability in Arista VeloCloud Orchestrator's on-premises deployment — the centralized management platform that configures and monitors SD-WAN edge devices across an organization's branch network. Command injection vulnerabilities in orchestration platforms are particularly dangerous because of what they control: successful exploitation doesn't just compromise the orchestrator itself, it potentially gives an attacker the ability to push malicious configuration changes to every SD-WAN edge device the orchestrator manages, turning one compromised management console into a foothold across an entire distributed branch network simultaneously.
What BOD 26-04 actually requires
CISA's Binding Operational Directive 26-04 requires federal civilian executive branch agencies to prioritize rapid remediation of high-risk vulnerabilities identified in the KEV catalog on any publicly exposed assets, typically within a mandated remediation window measured in days rather than the standard patch-cycle timelines many organizations default to. If you're a federal contractor or agency, this isn't optional guidance — it's a compliance deadline with specific reporting obligations attached. If you're a private-sector organization not directly bound by BOD directives, the KEV catalog is still the single most reliable, curated signal of which vulnerabilities deserve immediate attention over the dozens of CVEs disclosed in any given week, precisely because CISA only adds entries with confirmed active exploitation evidence.
Why third-party MSP-managed devices are the likeliest gap
Both Fortinet firewalls and Arista SD-WAN infrastructure are commonly deployed and managed by third-party managed service providers on behalf of the end customer, rather than by the customer's own internal IT staff — a common and often sensible arrangement for organizations without dedicated network security expertise in-house. That arrangement creates a specific risk during exactly this kind of urgent patch scenario: the end customer often assumes their MSP is tracking security advisories and applying patches proactively, while the MSP may be managing patch cycles across dozens or hundreds of client environments on a routine, non-expedited schedule that doesn't automatically escalate for a KEV catalog addition unless the customer specifically asks. This is precisely the kind of gap that turns a well-publicized, high-urgency vulnerability into a real-world breach weeks after the patch was available — not because the technology failed, but because the accountability for applying it was ambiguous between two parties who each assumed the other was handling it.
What to do this week
-
Identify every Fortinet FortiOS and Arista VeloCloud Orchestrator deployment in your environment immediately, including any instances managed by third-party MSPs on your behalf. Don't assume your network team has a complete inventory — perimeter security appliances are frequently deployed by different teams than the ones managing your core asset inventory.
-
Apply vendor patches for both CVEs without waiting for your standard change-management window. KEV catalog additions are, by definition, vulnerabilities under active exploitation — the calculus that normally justifies waiting for a scheduled maintenance window doesn't apply when attackers are already using the bug.
-
Check both vendors' security advisories for indicators of compromise specific to these CVEs, and review logs on affected appliances for signs of exploitation predating your patch, particularly unexpected configuration changes on Arista-managed SD-WAN devices or unusual data access patterns on Fortinet appliances.
-
If you use a third-party MSP to manage either platform, confirm in writing — not just verbally — that they've patched every instance under management on your behalf, and ask for a specific completion date. MSP-managed infrastructure is a common gap in patch management because the customer assumes the MSP has handled it and the MSP assumes it's on a routine, non-urgent cycle.
-
Build a standing internal process that treats every future KEV catalog addition as an automatic, non-negotiable expedited-patch trigger, rather than re-litigating urgency each time. Given how frequently CISA has updated the KEV catalog throughout 2026 — multiple additions nearly every month, often for widely deployed network and security infrastructure — organizations that don't have this process running by default will keep discovering these deadlines reactively.
Why these two vulnerabilities being added together is not a coincidence
CISA adding a Fortinet FortiOS vulnerability and an Arista VeloCloud vulnerability to the KEV catalog on the same day doesn't necessarily mean they're being exploited by the same threat actor or in a coordinated campaign, but it does reflect a broader trend worth naming explicitly: network perimeter and SD-WAN vendors have become sustained, high-value targets for vulnerability research by both defenders and attackers throughout 2026, and CISA's KEV catalog additions this year have skewed heavily toward this category of infrastructure compared to prior years. Attackers have clearly recognized that network edge appliances offer a favorable risk-reward ratio: these devices are frequently deployed with default or lightly reviewed configurations, patch cycles for network appliances tend to lag behind patch cycles for more visible application software, and a single compromised edge device can provide a foothold with visibility into a disproportionate share of an organization's traffic and internal network topology. Security teams that have historically deprioritized network appliance patching relative to application and endpoint patching should treat this as a clear signal that assumption needs to be revisited.
How to build a faster internal KEV response process
Many organizations' current vulnerability management workflow treats a CISA KEV catalog addition the same way it treats any other CVE disclosure — logged into a ticketing system, triaged during the next scheduled vulnerability review meeting, and patched during the next available maintenance window. That workflow is fundamentally mismatched to what a KEV addition actually represents: confirmed active exploitation, right now, not a theoretical future risk. A more appropriate internal process treats any new KEV catalog entry affecting infrastructure in your environment as an automatic trigger for an expedited, same-week patch cycle, bypassing the standard change-management queue specifically because CISA has already done the hard work of confirming this vulnerability warrants that urgency — you don't need your own internal risk assessment to reach the same conclusion CISA already reached with better visibility into actual exploitation activity than most individual organizations have access to. Building this as a standing, pre-approved fast-track process — rather than negotiating urgency case by case with change advisory boards — is the single highest-leverage change most vulnerability management programs could make in response to how frequently the KEV catalog has been updated throughout 2026.
Why network edge devices keep dominating the KEV catalog
Fortinet and Arista joining the KEV catalog this week continues a pattern that's defined much of 2026's vulnerability landscape: network perimeter and SD-WAN infrastructure — firewalls, VPN appliances, load balancers, orchestration platforms — has become one of the most consistently targeted categories of enterprise software, precisely because these devices sit at the boundary between your internal network and the internet, are frequently under-patched relative to more visible application infrastructure, and provide attackers with a foothold that's disproportionately valuable relative to the effort required to exploit them. If your organization's vulnerability management program still treats network appliances as lower-priority than application-layer software, this is the latest in a long series of data points arguing that assumption needs to change.
The specific patch deadline that matters here is CISA's, but the underlying lesson applies regardless of whether you're bound by BOD 26-04: when a vulnerability in widely deployed network edge infrastructure gets confirmed active exploitation, the organizations that get compromised in the following weeks are disproportionately the ones that treated the patch as routine rather than urgent.