Patched Is Not Clean: The FortiOS Symlink Persistence Bypass (CVE-2025-68686)

On July 27, 2026, CISA added CVE-2025-68686 to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of August 10. Its CVSS 3.1 base score is 5.9 — Medium. If you triage by score, it will not make this week's list. That would be a mistake, and the reason is in the description rather than the number.

Per NVD, the flaw "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," and "an attacker would need first to have compromised the product via another vulnerability, at filesystem level." Read that twice. This is not a way in. It is a way to stay in — a bypass of the fix Fortinet shipped for a persistence mechanism that was found on devices after they had already been breached.

Which means the honest reading of CVE-2025-68686 is this: if it is exploitable against your firewall, the bad news happened some time ago. The advisory is not warning you about an attack. It is telling you that a class of leftover access survived a fix you probably believed had closed it.

The facts, as published

• → Affected: FortiOS 7.6.0 through 7.6.1, 7.4.0 through 7.4.6, and all versions of 7.2, 7.0, and 6.4.
• → Class: CWE-200, exposure of sensitive information to an unauthorized actor. CVSS 3.1 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) — network-reachable and unauthenticated, but high attack complexity, and confidentiality impact only.
• → Precondition: prior compromise of the device at filesystem level, through a separate vulnerability.
• → Status: KEV-listed July 27, 2026; federal due date August 10, 2026; vendor advisory FG-IR-25-934.

The score deserves a note of its own, because it is a good example of CVSS measuring the wrong thing for the decision you actually have to make. "Confidentiality impact only" and "high attack complexity" are accurate descriptions of the mechanics. They say nothing about the operational meaning, which is that read access to a compromised appliance's filesystem persisted through remediation. CISA's inclusion criteria are about confirmed exploitation, not severity — and a medium-scored entry in KEV is a stronger signal than a critical that nobody has ever used.

Step one: apply the fix

Fortinet's advisory FG-IR-25-934 carries the affected-and-fixed build matrix for each branch; check your exact running version against it rather than against a version number you read in a blog post, this one included. Devices on 6.4, 7.0, and 7.2 are called out as affected in all versions, and those branches are the ones most likely to be sitting in a closet at a remote site where nobody has logged in for a year.

CISA's required action for this entry points at BOD 26-04 rather than a simple "patch by" date, and explicitly references forensic triage requirements. That framing is the tell: the agency is not treating this as routine patching.

Step two: the part most people skip

Applying a fix removes a vulnerability. It does not remove an intruder, and it does not remove what an intruder changed. When a firewall has been compromised at filesystem level, the durable footholds are rarely exotic — they are ordinary configuration objects that look boring in a config file:

• → An extra administrator. A second super-admin, or an account with an unremarkable name that nobody on the team recognises. It survives reboots, upgrades, and the patch you just applied.
• → An admin account with no trusted-host restriction. If every admin but one is locked to the management subnet and one is not, that is not a policy inconsistency, it is a question.
• → A new VPN user, group, or portal. Remote access that pre-dates nothing and belongs to no ticket — often with MFA quietly not applied to that one group.
• → Admin services newly reachable. HTTPS or SSH enabled on a WAN interface, or a policy that exposes a management port from an untrusted source.
• → A widened rule, or logging switched off on one. The rule that got a little broader, and the rule whose logging stopped, are frequently the same rule.

None of these require a forensic toolkit to find. They require someone to read the configuration carefully and know what "normal" looks like — which is precisely what nobody has time to do across a fleet on an August deadline.

What CRWLR can tell you here — and what it can't

Being exact about this matters more than the pitch. CRWLR parses an exported FortiGate configuration and runs 175 checks over it. Several of them land directly on the list above: default and generic admin account names, an excessive number of super-admin accounts, admin accounts missing trusted-host restrictions, admins without two-factor, admin services enabled on WAN interfaces, management ports exposed through policies, SSL VPN portals with weak or default settings, VPN groups containing members without MFA, and default or self-signed VPN certificates. It also cross-references the running firmware against CISA KEV, NVD, and Fortinet PSIRT feeds, so a device sitting in an affected range surfaces as a finding rather than as an assumption. And because scans are stored, re-scanning a device shows what changed in its configuration since last time — which is the fastest way to spot an object that appeared without a change ticket.

The limits, stated plainly: a configuration audit cannot see a symlink. It does not read the filesystem, it does not inspect running processes or memory, it does not verify that a hotfix binary was applied, and it cannot certify that a device is uncompromised. For CVE-2025-68686 specifically, the vulnerable mechanism lives in a layer a config export does not contain. If you have reason to believe a device was breached, that is an incident response engagement — vendor support, forensic triage per CISA's guidance, and in the serious cases a rebuild from known-good rather than a cleanup in place.

What a config audit does is answer the adjacent question quickly and across every device at once: is there anything in these configurations that should not be there? That is a genuinely useful answer to have before you decide which devices deserve the expensive kind of attention.

FAQ

What is CVE-2025-68686?

An exposure-of-sensitive-information vulnerability (CWE-200, CVSS 3.1 5.9) in Fortinet FortiOS that allows a remote unauthenticated attacker to bypass the patch Fortinet developed for the symbolic-link persistency mechanism observed in some post-exploitation cases, using crafted HTTP requests. Exploitation requires that the device was already compromised at filesystem level through a separate vulnerability. CISA added it to the Known Exploited Vulnerabilities catalog on July 27, 2026, with a due date of August 10, 2026. The vendor advisory is FG-IR-25-934.

Which FortiOS versions are affected?

Per the NVD record: FortiOS 7.6.0 through 7.6.1, FortiOS 7.4.0 through 7.4.6, and all versions of FortiOS 7.2, 7.0, and 6.4. Check your exact build against Fortinet's advisory FG-IR-25-934 for the fixed-version matrix for your branch — and note that 7.2, 7.0, and 6.4 are affected in every version, so any device still on those branches needs attention regardless of its patch level.

Why is a CVSS 5.9 vulnerability in the KEV catalog?

Because KEV is a catalog of vulnerabilities with reliable evidence of exploitation, not a severity ranking. The 5.9 score reflects mechanics — high attack complexity, confidentiality impact only — rather than consequence. The consequence here is that read access to a previously-compromised appliance survived the fix intended to remove it. A medium-scored entry with confirmed exploitation warrants more urgency than a critical that nobody has ever used in the wild.

If I patch, is my FortiGate clean?

No — patching and remediation are different things. This vulnerability concerns a persistence mechanism used after a device was already breached, so applying the fix removes the bypass but says nothing about what an intruder did while they had access. Anything they wrote into the configuration — an extra administrator, a VPN account, a widened rule, an exposed management service — survives the upgrade untouched. If you have reason to believe a device was compromised, treat it as an incident: vendor support, forensic triage in line with CISA's guidance, credential and certificate rotation, and a rebuild from known-good configuration where the evidence warrants it.

What should I look for in the configuration after a suspected firewall compromise?

Start with anything that grants access and outlives a reboot: administrator accounts you cannot map to a person, admins missing trusted-host restrictions or two-factor, VPN users, groups and portals that belong to no ticket, MFA missing on one group, admin services newly enabled on a WAN interface, management ports reachable through a policy, certificates that changed, rules that got broader, and logging switched off on a rule that used to have it. Compare against a known-good export from before the suspected intrusion if you have one — the diff is far more informative than any single config read.

Can a configuration audit detect the symlink backdoor itself?

No. The symbolic-link persistence mechanism lives on the device filesystem, and an exported configuration does not contain it — no config-based tool can see it, ours included. Detecting it is a job for the vendor's guidance in FG-IR-25-934 and for forensic examination of the device. A configuration audit answers the neighbouring question — whether anything in the configuration itself should not be there — which is worth having quickly, and across every device, while you decide where to spend the expensive investigation.