CISA’s addition of two actively exploited vulnerabilities to the Known Exploited Vulnerabilities catalog on July 27 puts network-edge administration platforms squarely in the urgent-remediation lane: Fortinet FortiOS SSL-VPN deployments and Arista VeloCloud Orchestrator On-Prem instances now require immediate exposure assessment, patch planning, and compromise review. The two entries—CVE-2025-68686 and CVE-2026-16812—are materially different in preconditions and severity, but both reinforce an uncomfortable security reality: management planes and remote-access infrastructure remain exceptionally valuable targets once they are reachable from untrusted networks. CISA’s alert says the additions were based on evidence of active exploitation.
For Windows administrators, this is not a story confined to routers and SD-WAN appliances. These systems frequently sit in front of—or hold privileged paths into—Windows domains, Azure-connected workloads, VPN users, branch networks, remote-management tools, and the identity infrastructure that ties them together. A compromise of a perimeter appliance or an orchestration server can become a route to credentials, configuration data, lateral movement, and persistent access across a Windows environment.
The practical takeaway is straightforward: treat both CVEs as incident-response priorities, not ordinary patch-management tickets. The right response is not simply to install an update. Organizations need to identify potentially affected systems, reduce exposure while maintenance is underway, preserve relevant evidence, and validate that a patch has removed the vulnerable condition without leaving an attacker’s foothold behind.

Cybersecurity infographic showing exploited VPN vulnerabilities threatening servers, Active Directory, and SD-WAN branches.Overview: Two KEV Additions, Two Different Risk Stories​

CISA’s Known Exploited Vulnerabilities Catalog is designed to focus attention on flaws that attackers are already using, rather than on the far larger universe of published CVEs. That distinction matters. A vulnerability’s severity score can describe technical potential, but a KEV designation establishes a much more operational fact: exploitation is no longer theoretical. CISA’s July 27 notice identifies the following additions:
  • CVE-2025-68686Fortinet FortiOS Exposure of Sensitive Information to an Unauthorized Actor Vulnerability
  • CVE-2026-16812Arista VeloCloud Orchestrator On-Prem OS Command Injection Vulnerability
The headline descriptions should not lead teams to treat the two cases identically.
CVE-2025-68686 is a FortiOS SSL-VPN issue related to bypassing a patch intended to prevent a symbolic-link persistence mechanism. The critical nuance is that Fortinet’s and NIST’s vulnerability descriptions say an attacker must first have compromised the device at the file-system level through another vulnerability. In other words, this is not presented as a standalone initial-access bug; it can help an existing intruder preserve or extend access after an earlier compromise. NIST’s NVD record describes the flaw as remotely reachable through crafted HTTP requests, but with that significant prerequisite.
CVE-2026-16812, by contrast, is a maximum-severity remote OS command injection issue in VeloCloud Orchestrator On-Prem. Arista says the vulnerability can expose privileged internal functionality that was not intended to be remotely accessible, can affect the VCO host and data managed by the orchestrator, and is known to be actively exploited. Arista assigns both CVSS v3.1 and CVSS v4.0 scores of 10.0. Arista Security Advisory 0144 also states that VCO is exposed by default and that tenant or operator credentials are not required when an attacker has network access to the VCO web interface.
That difference should shape the order of operations. An internet-accessible unpatched VCO instance should be considered the more immediate containment concern. The FortiOS issue remains urgent because it can be part of a post-exploitation chain, particularly on devices that may already have been targeted through older or unpatched weaknesses.

Why the KEV Catalog Changes the Conversation​

The CISA KEV Catalog is not merely another vulnerability feed. It is a prioritized list of vulnerabilities that represent a demonstrated threat to organizations, especially where exposed infrastructure is involved. CISA explicitly characterizes these types of flaws as frequent attack vectors for malicious cyber actors and as risks to the federal enterprise. The agency’s announcement also encourages all organizations—not only federal agencies—to use KEV status in risk-based vulnerability management.
That positioning is increasingly important as U.S. federal vulnerability management moves away from simplistic, score-only triage. Binding Operational Directive 26-04, released by CISA on June 10, 2026, centers remediation decisions on a combination of public exposure, KEV status, exploit automatability, and technical impact. FedRAMP’s implementation notice summarizes that approach and notes that the directive requires agencies to update their vulnerability-management processes.
This is a better fit for real-world defensive work than a patch list ordered exclusively by CVSS. A high score still matters, but the question that should drive action is more concrete:
Is this vulnerable asset reachable, exploitable, operationally important, and already being targeted?
For CVE-2026-16812, Arista’s advisory makes the answer particularly stark. The vulnerable application is an orchestration platform used to manage enterprise networking services. If its management interface is exposed, an unauthenticated attacker may gain access to privileged internal functionality and potentially affect not only the VCO host but the broader environment it manages. Arista’s advisory warns that compromise of the platform may provide access to VeloCloud Edge devices as well.
For Windows-centric IT teams, that elevates VCO from a “network team system” to a shared enterprise-risk system. Its compromise can influence routing, remote connectivity, branch operations, device trust boundaries, and access paths used by Windows endpoints and administrators.

CVE-2025-68686: FortiOS SSL-VPN Persistence Patch Bypass​

What the Fortinet vulnerability does​

CVE-2025-68686 is classified as an Exposure of Sensitive Information to an Unauthorized Actor vulnerability, mapped to CWE-200. NIST’s National Vulnerability Database says that affected FortiOS SSL-VPN versions may allow a remote unauthenticated attacker to bypass a patch developed for a symbolic-link persistence mechanism observed in post-exploitation cases, using crafted HTTP requests. The NVD entry further specifies that the attacker would first need to have compromised the product through another vulnerability at the file-system level.
This prerequisite is essential. The advisory does not mean every internet-facing FortiGate appliance is exposed to unauthenticated takeover solely because of this CVE. It does mean that an attacker who has already obtained an appropriate degree of access may have another means to interfere with persistence protections or access sensitive information.
That is still a serious enterprise problem. Security teams often place a dangerous dividing line between “initial access” vulnerabilities and “post-exploitation” vulnerabilities. Attackers do not. A weakness that sustains access, defeats a cleanup effort, or permits the retrieval of sensitive device data can be just as consequential as the bug that originally opened the door.

Affected FortiOS release families​

NIST lists the following Fortinet FortiOS ranges as affected:
  • FortiOS 7.6.0 through 7.6.1
  • FortiOS 7.4.0 through 7.4.6
  • All FortiOS 7.2 versions
  • All FortiOS 7.0 versions
  • All FortiOS 6.4 versions NVD
Fortinet’s advisory directs customers on the 7.6 branch to upgrade to 7.6.2 or later and those on the 7.4 branch to upgrade to 7.4.7 or later. The vendor’s guidance for the 7.2, 7.0, and 6.4 trains is to migrate to a fixed release. Fortinet’s PSIRT advisory also states that systems which never had SSL-VPN enabled are not impacted by this specific issue.
That scope calls for accurate inventory rather than broad assumptions. Organizations should determine:
  1. Which FortiGate devices run an affected FortiOS release.
  2. Whether SSL-VPN has ever been enabled, rather than only whether it is currently enabled.
  3. Whether the management or VPN interface is—or was—reachable from the internet.
  4. Whether the appliance has been subject to prior exploitation attempts, suspicious configuration changes, or unexplained artifacts.
  5. Whether legacy FortiOS branches are still in production because of compatibility, appliance age, or operational inertia.

Why “medium” severity should not create false comfort​

Fortinet assigned the CVE a CVSS v3.1 score of 5.9, with the vector indicating network reachability, no privileges, no user interaction, high confidentiality impact, and high attack complexity. NVD has not supplied an independent score. NVD’s record makes clear that this is a relatively constrained issue in isolation.
But the KEV designation alters the operational significance. A medium CVSS rating does not mean a low-priority incident when the flaw is associated with active exploitation and may operate in the persistence phase of an intrusion. It can be precisely the kind of vulnerability attackers use after exploiting a more obvious weakness—when defenders believe the most dangerous window has already closed.
This is a strong example of why a risk-based vulnerability program should combine:
  • Technical severity
  • Internet exposure
  • Known exploitation
  • Asset criticality
  • Whether the vulnerability enables persistence or post-exploitation
  • Evidence that a device may already be compromised
A FortiGate device terminating VPN access for administrators, remote employees, or privileged contractors deserves special scrutiny. The appliance may retain session information, authentication configuration, certificates, logs, routes, and policy definitions that can be valuable to an attacker trying to map a Windows enterprise.

CVE-2026-16812: A Critical VCO On-Prem Command Injection Threat​

The higher-risk scenario​

Arista’s CVE-2026-16812 advisory presents a much more direct threat model. The company identifies the issue as CWE-78, or improper neutralization of special elements used in an OS command—commonly called OS command injection. The vulnerability can allow a remote attacker to access privileged internal functionality and affect the VeloCloud Orchestrator host. Arista Security Advisory 0144 says successful exploitation could compromise the confidentiality, integrity, and availability of both the orchestrator and data managed by it.
Arista gives the flaw a 10.0 CVSS score because it is:
  • Reachable over the network
  • Low complexity to exploit
  • Unauthenticated
  • Free of required user interaction
  • Capable of high impact to confidentiality, integrity, and availability Arista’s advisory
The vendor says the vulnerable functionality was intended for internal use only, yet had become remotely accessible. That is exactly the kind of management-plane exposure that attackers prize: functionality designed around trusted internal assumptions can have far weaker defensive controls than public-facing application paths.

Affected VCO versions and fixed releases​

According to Arista, the following VeloCloud Orchestrator On-Prem release families are affected:
  • VCO 5.2.x before 5.2.3.14
  • VCO 6.1.x before 6.1.3.4
  • VCO 6.4.x before 6.4.2.4
  • VCO 7.0.x before 7.0.0.1 Arista’s advisory
Arista identifies the affected product as VeloCloud Orchestrator On-Prem, formerly branded under Broadcom. The advisory separately says hosted VCO, VeloCloud Gateway, VeloCloud Edge, and a wide range of Arista EOS, CloudVision, wireless, and other products are not affected by this vulnerability. Arista’s product-scope section is the authoritative source for distinguishing affected on-prem orchestration deployments from non-affected Arista products.
A potentially overlooked complication is end-of-support software. Arista says unsupported VCO versions have not been assessed. That does not establish that they are safe, and it should not be interpreted as a clean bill of health. It means organizations with older deployments need an escalation path through vendor support and should not delay exposure reduction while an upgrade strategy is determined.

Default exposure makes segmentation crucial​

Arista’s advisory contains one of the most significant details in the entire story: VCO is exposed by default, and there is no configuration that fully prevents the exposure. Successful exploitation requires network access to the VCO web interface, but it does not require tenant or operator credentials. Arista’s required-configuration guidance recommends restricting access to trusted administrative networks as a way to reduce exposure.
That does not mean access restrictions replace patching. They do not. A firewall rule or reverse-proxy control is a compensating control designed to buy time and narrow the attack surface. It may also be valuable after patching, because management interfaces should generally not remain broadly exposed merely because a single identified flaw has been fixed.
The proper operational sequence is:
  1. Remove direct internet exposure where business requirements permit.
  2. Restrict web-interface access to dedicated administrative networks, jump hosts, VPN addresses, or other narrowly scoped trusted sources.
  3. Upgrade to the appropriate fixed VCO release.
  4. Review for compromise before and after remediation.
  5. Rotate credentials and validate managed-device state if intrusion indicators are found or cannot be confidently ruled out.

Compromise Review Must Accompany Remediation​

Patching an exploited management-plane vulnerability is necessary, but it does not evict an attacker who already used it. CISA’s broader risk-based direction recognizes this distinction by setting expectations for agencies to consider whether compromise occurred before a patch was applied. CISA’s KEV update specifically references those expectations under BOD 26-04.
Arista provides concrete guidance for VCO investigation. It says there is no single definitive indicator of compromise, but operators should examine web-access logs for unusual URL-like path components, encoded characters, references to local or internal services, and unusually high request rates. The vendor also recommends checking backend application and operating-system logs around suspicious timestamps. Arista’s indicators-of-compromise section highlights unexpected outbound HTTP or HTTPS traffic, unexplained privileged maintenance actions, command execution, file creation, database exports, and unexpected access to configuration data, credentials, certificates, or key material.

A practical Windows enterprise investigation checklist​

A Windows-focused security operations team should coordinate with networking teams rather than assume the appliance owner will handle all downstream impact. A sensible review includes the following areas.
  • Identity systems: Review privileged account sign-ins, newly created accounts, MFA policy changes, conditional-access exceptions, and suspicious federation or directory synchronization activity.
  • Remote access: Check RADIUS, Active Directory, Entra ID, VPN, and identity-provider logs for unexpected authentication patterns. FortiOS and VCO systems frequently connect to centralized identity services.
  • Administrative workstations: Investigate whether privileged Windows endpoints interacted with the affected management plane during the suspected period. Session tokens, saved credentials, browser artifacts, and remote-management activity may be relevant.
  • Network configuration: Review unauthorized changes to routes, firewall rules, SD-WAN policies, DNS settings, tunnel configuration, and administrative access lists.
  • Secrets and certificates: Determine whether the affected platform stored administrative credentials, API keys, device certificates, private keys, or configuration backups. If so, prepare targeted rotation and re-enrollment plans.
  • Lateral movement signals: Look for unusual WinRM, Remote Desktop Protocol, SMB, PowerShell remoting, service creation, scheduled tasks, or domain-controller access originating from networks associated with the compromised appliance or orchestrator.
This work should be evidence-led. Not every VCO or FortiGate patch event needs to become a full-scale breach declaration. But where an internet-facing affected system was reachable during the exploitation window, the organization should preserve logs and establish a documented rationale for its conclusion.
Arista explicitly advises preserving VCO web-access, backend application, system, database, and relevant file-system timestamp evidence before remediation when feasible. Its advisory also notes that a compromised VCO platform can potentially provide attackers access to VeloCloud Edge devices. This makes evidence preservation especially important before a hasty reboot, cleanup, or upgrade potentially overwrites the most useful forensic data.

The Strengths—and Limits—of the New Risk-Based Model​

A meaningful improvement over patch-everything triage​

BOD 26-04’s emphasis on public exposure, KEV status, automatability, and impact is a practical improvement over vulnerability programs that treat every high CVSS score as equally urgent. FedRAMP’s explanation of BOD 26-04 says the directive reprioritizes remediation around those dimensions, while its associated FedRAMP rules require assessments of likely internet reachability and exploitability.
The strengths are substantial:
  • It directs scarce security resources toward vulnerabilities attackers are actually exploiting.
  • It recognizes that internet-facing management interfaces are categorically riskier than isolated internal systems.
  • It moves vulnerability management closer to exposure management and incident response.
  • It creates a stronger expectation that remediation includes a check for prior compromise.
  • It discourages organizations from confusing a monthly scan report with a complete security program.
FedRAMP goes further by requiring providers to assume exploits are automatable unless evidence shows otherwise, a rule designed to prevent teams from relying on wishful thinking or narrow technical caveats. FedRAMP’s notice says legacy monthly vulnerability-scanning processes are insufficient for the updated approach.

The residual risk organizations still need to manage​

However, a KEV-centered approach is not a substitute for disciplined asset management and secure architecture.
The most obvious limitation is timing. A vulnerability is only added to KEV after CISA has evidence of exploitation and has completed its cataloging process. An attacker may exploit a new flaw before it appears on any list. Teams should therefore retain rapid triage processes for critical vendor advisories, especially those affecting internet-facing VPNs, security appliances, web applications, hypervisors, identity systems, and management platforms.
There is also a risk of scope confusion. The Fortinet issue is constrained by a post-compromise prerequisite, whereas the Arista VCO flaw is described as unauthenticated and reachable by a network attacker. Treating both entries as identical can lead to wasted effort in one case and inadequate urgency in the other.
Finally, patching cannot compensate for an unnecessarily exposed administration plane. The VCO advisory’s default-exposure warning should prompt a broader architecture review. Administrative surfaces should be reachable only through controlled paths, protected by strong authentication, monitored continuously, and isolated from ordinary user networks.

Immediate Actions for IT and Security Teams​

The following response plan is appropriate for organizations that operate affected FortiOS or VCO environments.

For Arista VeloCloud Orchestrator On-Prem​

  1. Identify all VCO On-Prem instances and record their version, hosting location, public IP exposure, web-interface access paths, and managed tenant/device scope.
  2. Determine exposure immediately. If the VCO web interface is publicly reachable, restrict it to trusted administrative networks as an urgent containment measure. Arista identifies web-interface network access as the key requirement for exploitation. Arista’s advisory
  3. Upgrade to a fixed version in the relevant release train: 5.2.3.14, 6.1.3.4, 6.4.2.4, or a later suitable supported release. Arista’s resolution guidance
  4. Preserve and review logs before making destructive changes, especially where exposure was public or otherwise broad.
  5. Prepare post-compromise actions if evidence warrants them: credential rotation, review of administrator actions, validation of device configuration, and restoration from trusted sources where necessary. Arista explicitly recommends these steps after a possible VCO compromise. Arista’s post-remediation guidance

For Fortinet FortiOS SSL-VPN​

  1. Inventory FortiOS versions across all appliances, including standby devices, branch units, lab environments, and appliances that may be overlooked because they are managed by a separate network group.
  2. Confirm SSL-VPN history and configuration. Fortinet says systems that never had SSL-VPN enabled are not affected by this issue. Fortinet’s advisory
  3. Move to fixed releases where available, or migrate out of affected legacy trains. Fortinet lists 7.6.2 and 7.4.7 as fixed points for those release branches. Fortinet’s PSIRT guidance
  4. Review prior compromise evidence, especially on devices that were internet-facing or may have been exposed to older FortiOS vulnerabilities.
  5. Harden remote-access architecture beyond this one CVE: minimize public administration access, limit VPN exposure to required services, enforce strong identity controls, maintain trusted configuration backups, and retain logs long enough to support retrospective investigation.

Conclusion​

CISA’s latest KEV additions are a reminder that enterprise security often fails at the seams between teams: the network appliance owned by one group, the Windows identities managed by another, the cloud service connected by a third, and the incident response process that begins only after suspicious activity becomes undeniable.
CVE-2026-16812 demands immediate attention because Arista describes it as a critical, actively exploited, unauthenticated command injection vulnerability affecting VeloCloud Orchestrator On-Prem deployments with reachable web interfaces. CVE-2025-68686 deserves equal seriousness in a different way: it highlights how attackers can use post-compromise flaws to preserve access and undermine remediation on FortiOS SSL-VPN infrastructure.
The most effective response is therefore broader than patching. Reduce management-plane exposure, upgrade affected systems, preserve evidence, investigate reachable assets for signs of compromise, rotate secrets when justified, and connect network security telemetry with Windows identity and endpoint monitoring. That is the kind of risk-based vulnerability management CISA’s KEV program is designed to encourage—and the kind that meaningfully reduces the odds that a patch window becomes an intrusion timeline.

References​

  1. Primary source: CISA
    Published: 2026-07-27T12:00:00+00:00
  2. Related coverage: github.com
  3. Related coverage: analysis-atlas.com