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.
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-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.
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:
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.
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.
That scope calls for accurate inventory rather than broad assumptions. Organizations should determine:
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:
Arista gives the flaw a 10.0 CVSS score because it is:
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.
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:
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.
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 are substantial:
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.
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.
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.
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-68686 — Fortinet FortiOS Exposure of Sensitive Information to an Unauthorized Actor Vulnerability
- CVE-2026-16812 — Arista VeloCloud Orchestrator On-Prem OS Command Injection Vulnerability
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:
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.Is this vulnerable asset reachable, exploitable, operationally important, and already being targeted?
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
That scope calls for accurate inventory rather than broad assumptions. Organizations should determine:
- Which FortiGate devices run an affected FortiOS release.
- Whether SSL-VPN has ever been enabled, rather than only whether it is currently enabled.
- Whether the management or VPN interface is—or was—reachable from the internet.
- Whether the appliance has been subject to prior exploitation attempts, suspicious configuration changes, or unexplained artifacts.
- 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
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
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
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:
- Remove direct internet exposure where business requirements permit.
- Restrict web-interface access to dedicated administrative networks, jump hosts, VPN addresses, or other narrowly scoped trusted sources.
- Upgrade to the appropriate fixed VCO release.
- Review for compromise before and after remediation.
- 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.
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.
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
- Identify all VCO On-Prem instances and record their version, hosting location, public IP exposure, web-interface access paths, and managed tenant/device scope.
- 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
- 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
- Preserve and review logs before making destructive changes, especially where exposure was public or otherwise broad.
- 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
- 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.
- Confirm SSL-VPN history and configuration. Fortinet says systems that never had SSL-VPN enabled are not affected by this issue. Fortinet’s advisory
- 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
- Review prior compromise evidence, especially on devices that were internet-facing or may have been exposed to older FortiOS vulnerabilities.
- 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
- Primary source: CISA
Published: 2026-07-27T12:00:00+00:00
CISA Adds Two Known Exploited Vulnerabilities to Catalog | CISA
CISA has added two new vulnerabilities to its KEV Catalog, based on evidence of active exploitation.
www.cisa.gov
- Related coverage: github.com
kev-data/known_exploited_vulnerabilities_schema.json at develop · cisagov/kev-data · GitHub
Mirror of cisa.gov/kev data files. Contribute to cisagov/kev-data development by creating an account on GitHub.
github.com
- Related coverage: analysis-atlas.com
CISA Known Exploited Vulnerabilities Dataset
The full CISA Known Exploited Vulnerabilities catalog as one table: vendor, product, CWE, dates and ransomware flag. CC BY 4.0.analysis-atlas.com