Two vendors, one pattern: perimeter gear under active attack
CISA's August 20 alert added two vulnerabilities to its Known Exploited Vulnerabilities catalog: CVE-2025-68686, described as an exposure of sensitive information in Fortinet's FortiOS, and CVE-2026-16812, an OS command injection vulnerability in Arista's VeloCloud Orchestrator On-Prem. Both entries carry CISA's standard justification for inclusion, evidence of active exploitation, which means these are not theoretical findings from a research lab sitting in a disclosure queue somewhere. Someone is using them against real targets right now, and CISA's own catalog entry is effectively a public confirmation that incident responders have already seen it happen.
The pairing reflects where attackers have concentrated effort for most of the year rather than a coincidence of timing. Firewalls, VPN gateways, and SD-WAN management consoles sit at the network edge, are frequently internet-reachable by design, and in many organizations are patched on a slower cycle than internal servers because taking them offline risks an outage that a business unit will notice immediately. That combination, high value paired with low patch velocity, is exactly what keeps this category of device near the top of CISA's KEV additions month after month, and this week's pair of entries fits the pattern precisely.
Why the Arista flaw is the sharper edge
An information-exposure bug in FortiOS is serious on its own, since FortiOS underpins firewall and VPN appliances across a huge share of the enterprise install base, and any flaw that leaks configuration data, session tokens, or credentials from that OS gives an attacker a workable foothold into whatever network sits behind it. The OS command injection flaw in Arista's VeloCloud Orchestrator On-Prem deserves even more attention from architecture teams, though, because of what an orchestrator actually controls across an entire organization's branch footprint.
A VeloCloud Orchestrator is the central management plane for an SD-WAN deployment, pushing routing policy, security configuration, and software updates out to every edge device in the fleet, often hundreds of branch locations for a retail chain, bank, or distributed enterprise with regional offices. Command injection against the orchestrator itself means an attacker who compromises that one system inherits the ability to reconfigure or redirect traffic across the entire branch network it manages, all from a single point of entry. That concentration of control sits at the center of infrastructure most network teams treat as a stable, low-touch appliance rather than an active attack surface worth watching daily.
What BOD 26-04 actually requires, and why it matters beyond federal agencies
CISA's KEV additions come with a standing directive, BOD 26-04, that applies formally only to federal civilian agencies but functions as a de facto best-practice deadline for everyone else watching the catalog. The directive requires agencies to prioritize rapid remediation of these flaws on any publicly exposed system, and notably, to verify whether systems have already been compromised before applying patches, since patching over an active compromise does nothing to remove an attacker's existing foothold or any persistence mechanism already installed.
That compromise-check requirement is worth borrowing directly, regardless of whether your organization answers to a federal directive. Any enterprise running FortiOS or VeloCloud Orchestrator On-Prem in an internet-facing configuration should assume, until logs prove otherwise, that the device may already be attacker-controlled. Patching first and investigating later is the wrong order of operations for a flaw already flagged as under active exploitation, because a patch can quietly restore a clean-looking, fully-updated appliance that still has an attacker's backdoor sitting inside it undetected.
The blind spot: gear nobody remembers is internet-facing
The recurring failure mode in perimeter-device incidents traces back to uncertainty about the asset inventory more often than it traces back to a missed patch notice. Firewalls and SD-WAN orchestrators accumulate over years of acquisitions, branch openings, and regional IT decisions made without central visibility, and security teams routinely discover an internet-facing management interface on a device they believed was locked down to internal access only. Attackers who monitor KEV additions understand this pattern well and specifically scan for exactly that kind of forgotten exposure within days of a CVE going public, often faster than internal teams complete their own inventory sweep.
Any organization with a distributed footprint, retail chains, multi-site healthcare systems, logistics networks with dozens of regional hubs, should run an external attack-surface scan against its own IP ranges this week, matched against both CVE numbers, rather than relying on a vendor-supplied asset list that may already be stale by months. The gap between what IT believes is exposed and what actually sits reachable from the internet is precisely where incidents like this one begin, and closing that gap is cheaper before an incident than during one.
The decision this puts on your desk
Confirm patch status on every FortiOS and VeloCloud Orchestrator On-Prem instance in your environment this week, prioritizing anything internet-facing, and treat any device you cannot immediately confirm as patched as a presumed compromise pending log review. Given CISA's active-exploitation language, this belongs on the incident-response track this week, well ahead of the next scheduled change window your network team has planned for routine maintenance, and it warrants a direct status report to whoever owns risk at the executive table.
Longer term, the recurring lesson from this category of KEV addition is that perimeter and SD-WAN infrastructure needs the same patch SLA and asset-inventory discipline applied to servers and endpoints, rather than a slower cadence justified by uptime concerns. A firewall or orchestrator that takes six months to patch because change control is heavier for network gear tends to be exactly the device that eventually lands on a KEV list. Push your network team for a documented, enforced patch SLA on edge devices, and audit it with the same rigor you already apply to endpoint compliance reporting.
