Two Bugs Hit KEV the Same Day. The 10.0 Gets Them In. The 5.3 Keeps Them There.

On July 27 CISA added two vulnerabilities to the Known Exploited Vulnerabilities catalog. Federal civilian agencies have until July 30 to remediate both. That is tomorrow.

The two entries look nothing alike, and the mismatch is the story. One is a perfect 10.0 in an SD-WAN controller, unauthenticated, exploited as a zero-day. The other is a 5.3 medium in FortiOS that was published back in February and cannot be exploited on its own at all.

The 10.0 is the one every outlet led with. The 5.3 is the one that should ruin your evening.

The one that gets them in

CVE-2026-16812 is an OS command injection in Arista VeloCloud Orchestrator On-Prem. Unauthenticated. No special configuration required. It scores 10.0 on CVSS 3.1 and 10.0 on CVSS 4.0, and it was found because someone was already using it.

The reason this one deserves the full 10 rather than the reflexive eye-roll that greets most maximum scores is what a VeloCloud Orchestrator actually is. It is not an appliance in your perimeter. It is the thing that programs the appliances. The Orchestrator holds device inventory, configurations, certificates, credentials, and key material for your entire SD-WAN estate, and Arista's own hunting guidance says to go looking for exactly that: unexpected command execution, database exports, file creation, and access to inventory, configs, certificates, credentials, and keys.

Compromise the Orchestrator and you have not breached one branch office. You have acquired the ability to reconfigure every Edge device it manages. This is the same shape as the Check Point SmartConsole authentication bypass that landed on KEV five days earlier — the management plane, not the data plane, and a blast radius equal to the size of the deployment rather than the size of the box.

Fixed releases are VCO 5.2.3.14 and later in the 5.2 train, 6.1.3.4 and later in the 6.1 train, 6.4.2.4 and later in the 6.4 train, and 7.0.0.1 in the 7.0 train. If you run VeloCloud Orchestrator on-premises, that is tonight's work regardless of whether you are a federal agency.

One honest note, because we would rather be useful than dramatic: Arista has published no indicators. No IP addresses, no domains, no hashes, no actor attribution. Nobody can hand you a blocklist for this, ours included, and any vendor telling you otherwise this week is selling something. What you have is the hunting guidance above and your own VCO web access logs, where you are looking for unusual URL-like components in request paths. That is thinner than we would like. It is what exists.

The one that keeps them there

CVE-2025-68686 is a 5.3. Medium. It was published on February 10. It sat for five and a half months and then CISA put it on KEV, which means somebody is using it right now.

Here is what it does. FortiOS had a persistence problem: attackers who had already compromised a device were planting symbolic links to maintain read access to the filesystem, and that access survived the patching that was supposed to evict them. Fortinet shipped a fix for that persistence mechanism. CVE-2025-68686 is a bypass of that fix. Crafted HTTP requests, unauthenticated, and the attacker gets the persistence back.

The catch — and it is the reason the score is only a 5.3 — is that it cannot be exploited on its own. It requires that the device was already compromised at the filesystem level through some other vulnerability. CVSS is measuring the wrong thing here, and it is measuring it correctly. As an isolated bug it genuinely is a medium: high attack complexity, no integrity impact, no availability impact, confidentiality only. The scoring system is answering the question it was designed to answer, which is "how bad is this vulnerability by itself." That question is not the question a defender has.

The defender's question is: what does its presence on KEV tell me about the world?

It tells you this. Somewhere out there is a population of FortiOS devices that were compromised, that were then patched, whose owners believe the incident is closed — and on which the attacker's read access is still live, because the eviction patch had a bypass and the bypass is being used in the wild. Federal agencies have been given until tomorrow to close it.

Affected versions are FortiOS 7.6.0 through 7.6.1, 7.4.0 through 7.4.6, 7.2.0 through 7.2.13, 7.0.0 through 7.0.19, and 6.4.0 through 6.4.16. The fixes Fortinet names are 7.6.2 or above and 7.4.7 or above — which means if you are on the 7.2, 7.0, or 6.4 branches there is no in-branch fix on offer and the remediation is a branch upgrade. That is a materially bigger piece of work than a point release, and it is the reason a chunk of this population is going to miss the deadline.

We have written the first half of this story twice already

On June 20 we published an argument that FortiBleed was not a campaign but an audit result — that someone had run a credential-collection pass across the global population of internet-exposed FortiGate devices and found roughly half sitting on harvestable material accumulated across eight years of unpatched CVEs. Two weeks later those credentials turned up as the initial access behind INC and Lynx ransomware, and we wrote the follow-up. The line we used then was that a harvested credential is worse than an exploited CVE, because there is no patch for a password that already left the building.

This is the same sentence with a different noun. There is no patch for a foothold you already evicted and did not actually evict. A patched device with live attacker persistence looks identical, from your dashboard, to a patched device. That is the entire problem. The compliance artifact says remediated. The box says otherwise, and the box is not going to volunteer it.

We are not claiming we called this one early. We did not — CVE-2025-68686 is not in any post we have published, and our indicator feed holds nothing attributed to its exploitation. What we have is the surrounding thesis, published, dated, and now embarrassing for everyone who treated a patched Fortinet appliance as a closed ticket.

What the pairing is actually teaching

Both of these landed on the same day, with the same deadline, and a triage process that sorts by severity will handle them in completely the wrong order.

The 10.0 gets attention automatically. It is critical, it is a zero-day, it has a vendor advisory and press coverage, and it will be at the top of every scanner report Monday morning. It will get patched, and it should.

The 5.3 will be deferred. It is a medium, it is five months old, it needs a precondition, and on a busy team triaging by score it lands somewhere below the third-tier work. Deferring it is defensible, documentable, and best practice. It is also how a live foothold survives another quarter.

This is the second time in two days we have written a version of this argument. Yesterday it was three medium-severity Artifactory bugs — none critical, none unauthenticated, all deferrable — that chained into a containment breach at a frontier AI lab. Today it is a 5.3 that is only a 5.3 because it assumes you were already owned.

Severity scores rank vulnerabilities. They do not rank your exposure, because they cannot see your history. A 5.3 that presumes prior compromise is not a low-priority bug. It is a question about your past that your vulnerability scanner is structurally incapable of asking.

Patch both. Start with the Orchestrator because the deadline is real and the blast radius is your whole SD-WAN. Then go do the FortiOS branch upgrades, and while you are in there, stop treating "we patched it" as the end of the FortiGate story. It has not been the end of that story since June.

Confidence capped at 95%, as always. The version data and exploitation status here come from the CVE records and the KEV catalog; the claim that a population of patched-but-still-persistent FortiOS devices exists is an inference from the KEV listing, and we are labeling it as one.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.