📢 New post: The Eviction That Didn't Take: FortiOS CVE-2025-68686 · 📝 Also fresh: The Same Door, Three Times: Langflow CVE-2026-0770 and a Clock That Already Ran Out · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISAIncident Response

The Eviction That Didn't Take: FortiOS CVE-2025-68686

Most KEV entries ask can they get in. This one asks something less comfortable: did they ever, and did your fix actually put them out?

On July 27, 2026, CISA added CVE-2025-68686 to the Known Exploited Vulnerabilities catalog, with a federal remediation due date of August 10 — a date that has now passed. It's an information-exposure bug (CWE-200) in Fortinet FortiOS, and reading the description cold is a little disorienting:

...may allow a remote unauthenticated attacker to bypass the patch developed for the symbolic link persistency mechanism observed in some post-exploit cases, via crafted HTTP requests. An attacker would need first to have compromised the product via another vulnerability, at filesystem level.

A patch bypass. Not a bypass of an authentication control — a bypass of a remediation. To know why that matters, you have to remember what the remediation was for.

The thing that's being un-fixed

In April 2025, Fortinet published an analysis of threat actor activity describing a persistence technique that was, in hindsight, almost elegant. An actor who had already compromised a FortiGate through some earlier vulnerability dropped a symbolic link joining the user filesystem to the root filesystem, inside the folder that serves SSL-VPN language files. That folder is reachable over the SSL-VPN web path. The symlink turned it into a read-only window onto device files, including configuration.

The important part: it survived patching. You could close the original RCE, upgrade the box, and the symlink was still sitting there, still served, still readable. Fortinet's answer came in two pieces — AV/IPS signatures to flag and remove the symlink, and firmware (7.6.2, 7.4.7, 7.2.11, 7.0.17, 6.4.16) that removed it and stopped the SSL-VPN UI from serving symbolic links at all. Customers were told to upgrade, review every configuration, and treat those configurations as potentially compromised.

A lot of teams did exactly that. They upgraded, they rotated credentials, they wrote the incident up, they closed the ticket.

CVE-2025-68686 is the finding that the second half of that fix can be walked around with crafted HTTP requests.

Why this one reads differently

The two FortiSandbox entries we wrote about last month — CVE-2026-39808 and CVE-2026-25089 — were 9.8s. Unauthenticated command injection, no prerequisites, patch it before Thursday. The work was urgent and the work was obvious.

This one is a 5.9 Medium, and every signal around it says deprioritize:

Signal Value Source
CVSS 3.1 base 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) Fortinet, as CNA
CVSS 3.1 temporal 5.3 (adds E:P/RL:O/RC:C) Fortinet advisory FG-IR-25-934
NVD base score none published (record is Analyzed, carries only the CNA metric) NVD
SSVC exploitation active CISA
SSVC automatable no CISA
SSVC technical impact partial CISA
Known ransomware use unknown CISA KEV

Two notes on that table, because both will show up in somebody's ConMon feed and cause an argument.

First, the 5.9 and the 5.3 are the same assessment, not a disagreement. 5.9 is the base score; 5.3 is what you get after Fortinet applies the temporal metrics — proof-of-concept exploit maturity, official fix available, confirmed report. Different tools surface different ones. Record which is which rather than letting a 5.3 quietly overwrite a 5.9 in your register.

Second, that temporal discount rests on E:P — exploit maturity assessed as proof-of-concept. CISA put this on the KEV catalog, which is a statement that exploitation is active. Re-score the exploit-maturity metric to match CISA's finding and the temporal number drifts back up toward the base. It stays a Medium either way. That's rather the point.

Because here's the thing BOD 26-04 made explicit and this CVE makes concrete: the federal due date is not derived from severity. CISA's own SSVC data says not automatable, partial impact. A well-run risk-based triage process — the kind BOD 26-04 asks you to build — will rank this below a dozen internal findings. And it still arrived with a two-week clock attached, exactly like a 9.8 would. A Medium on the KEV list outranks a Critical that isn't on it.

The scoping question is historical, not current

"An attacker would need first to have compromised the product via another vulnerability, at filesystem level." That prerequisite is why the score is a Medium. It's also what makes the assessment work strange, because it converts the question your inventory answers into one it doesn't.

Your CMDB can tell you what FortiOS version you run today. It cannot tell you whether a FortiGate was compromised in 2024, quietly, by a vulnerability that has since been patched. And that's the population this CVE applies to.

There is one genuinely useful shortcut, straight from the advisory: devices that never had SSL-VPN enabled are not impacted. Take it — but notice the tense. Never had, not doesn't currently have. Answering it correctly means config history, not a config dump: was SSL-VPN ever turned on, on this device, during the window when the original symlink persistence was in play? For most estates that's a question for change records and old backups, and it's worth answering properly, because a defensible "SSL-VPN was never enabled on these forty units" scopes forty units out of the finding with evidence behind it.

The version math has an unkind wrinkle too:

Branch Affected Fix
FortiOS 7.6 7.6.0 – 7.6.1 7.6.2 or above
FortiOS 7.4 7.4.0 – 7.4.6 7.4.7 or above
FortiOS 7.2 all versions no fix in branch — migrate to a fixed release
FortiOS 7.0 all versions no fix in branch — migrate to a fixed release
FortiOS 6.4 all versions no fix in branch — migrate to a fixed release

Look at 7.2 and 7.0 next to the 2025 remediation. The firmware that fixed the original symlink issue on those branches was 7.2.11 and 7.0.17. A team that did precisely what Fortinet asked in April 2025 — upgraded to 7.2.11, called it remediated — is today on a branch with no remedy for the bypass. The only path off it is a major-version migration, which is a change-window conversation, not a patch ticket. Fortinet's interim answer is a virtual patch (FG-VD-60389.0day, FMWP database update 26.033) — which is worth deploying today, and is a compensating control in your records, not a remediation.

Worth sitting with: doing the right thing last year is what put you here. Not a gap. Not negligence. The remediation was correct, it was applied, and its guarantee has since been reduced.

What the work actually is

The August 10 date is behind us. If this is still open on your side, the honest framing is that you're past due, and what you owe now is different from what you owed two weeks ago — a POA&M entry with a real date, not a backdated patch record. That's a better outcome than a tidy timeline nobody can support. Concretely:

  • Enumerate FortiOS by branch, and separate the no-fix branches. 7.6.1 and 7.4.6 boxes are a patch. Anything on 7.2, 7.0, or 6.4 is a migration project that needs an owner and a date this week, plus the virtual patch in the meantime.
  • Answer "was SSL-VPN ever enabled" with evidence. Config history, not current state. Every unit you can honestly scope out shrinks the population you have to investigate — and that reasoning is the artifact, not the conclusion.
  • Re-open the 2025 symlink incident rather than filing a fresh one. If you responded to the April 2025 persistence issue, this is a continuation of that record. Linking them is what lets an assessor follow the thread; a brand-new unrelated ticket makes the history disappear.
  • Go look for the symlink again. Fortinet's AV/IPS detection for the original artifact is still the mechanism, and this is the rare CVE where the KEV required action's pointer to forensics triage is the primary work rather than a footnote after patching. The prerequisite for exploitation is that someone already got in.
  • Note the score provenance, not just the score. 5.9 base, 5.3 temporal, no independent NVD base score, active exploitation per CISA. Four facts, one register entry, no silent reconciliation.
  • Re-check what you asserted in 2025. If you told an AO or an assessor that the persistence mechanism was removed and cannot be re-served, that statement was true when you made it and is now qualified. Updating it yourself is a considerably better look than having it updated for you.

What we keep coming back to

Every few weeks the KEV item is a different product, and the lesson underneath refuses to move: know what you run before you're asked to account for it under a clock. This one adds a tense to it. Knowing what you run includes knowing what has already happened to it — which compromises you responded to, which fixes you relied on, and which of those fixes are still worth what they were worth on the day you closed the ticket.

That's the shape of work the Novaprospect audit engine is built toward: discovery that keeps the history attached to the asset, so a remediation record isn't a dead entry in a closed ticket but a live claim that can be re-examined when the patch behind it gets bypassed. The thing worth being able to query isn't only what version are we on — it's what did we already fix here, and does that fix still hold?

Next KEV item, same question, different product. It usually is.

Reference