CVE-2025-68686: FortiOS SSL-VPN Symlink Patch Bypass — How to Find Affected Instances

This is not an initial-access vulnerability, and its CVSS base score of 5.9 will not put it near the top of anyone's queue. It is on the CISA KEV catalog anyway, with a federal remediation deadline of August 10, 2026 — today. The reason is what it protects: a 2025 attacker technique that left read-only access to the FortiGate filesystem in place after the original vulnerability was patched. Fortinet shipped a fix for that technique. CVE-2025-68686 is a bypass of that fix. Here's how to find affected instances and what to ask for when you do.

What Was Actually Patched in 2025

In April 2025, Fortinet documented a persistence technique it had observed in the field. After compromising a FortiGate through a known vulnerability, threat actors created a symbolic link "in a folder used to serve language files for the SSL-VPN," connecting the user filesystem to the root filesystem. The significant detail is where that change lived. In Fortinet's words: "this modification took place in the user filesystem and avoided detection. Therefore, even if the customer device was updated with FortiOS versions that addressed the original vulnerabilities, this symbolic link may have been left behind."

The result was read-only access to files on the device's filesystem, "which may include configurations." Read-only is a genuine limit and worth stating plainly — this was never code execution. But a FortiGate configuration is not a low-value file. It carries interface and routing detail, VPN settings, policy, and credential material. An attacker holding a persistent read channel to it retains a foothold that patching the entry vector does nothing to close.

Fortinet's remediation had two halves. Upgrading to 7.6.2, 7.4.7, 7.2.11, 7.0.17, or 6.4.16 would "remove the malicious symbolic link", and the SSL-VPN UI was modified "to prevent the serving of such malicious symbolic links." The first half cleans up what is already there. The second half is the control that stops it working again.

The Bypass

CVE-2025-68686 (CWE-200) defeats that second half. Fortinet describes it as a flaw in FortiOS SSL-VPN that "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." The hardening that was supposed to stop the SSL-VPN from serving a malicious symlink can be worked around with the right request.

Three Branches With No In-Branch Fix

The remediation table deserves attention. FortiOS 7.6 and 7.4 have fixed builds — 7.6.2 and 7.4.7. For 7.2, 7.0 and 6.4, all versions are listed as affected and the guidance is to migrate to a fixed release. Those three branches received the original symlink remediation in 2025 (7.2.11, 7.0.17, 6.4.16) but get no build that closes the bypass. An operator on 7.0 who patched diligently last year, confirmed the symlink was removed, and considers the matter closed is on a branch where this issue has no fix at all short of a major upgrade.

Two Sources That Disagree

Fortinet's advisory page currently reports Known Exploited: No. CISA added the CVE to its Known Exploited Vulnerabilities catalog on July 27, 2026. Both statements are worth reading with their dates attached: FG-IR-25-934 was published February 10, 2026 and last revised March 12, 2026, so its exploitation field predates the KEV listing by more than four months rather than contradicting it. Cite the KEV catalog for exploitation status and the vendor advisory for version scope, and do not let a stale "No" on the vendor page settle the question.

Investigation Workflow

One caveat governs everything below. Remote scanning can establish that a FortiGate exists, that it presents an SSL-VPN portal, and sometimes which firmware branch it runs. It cannot establish the prerequisite — that a device was previously compromised at filesystem level. Discovery here produces a list of candidates for compromise review, not a list of victims, and it is worth saying so in the report before somebody reads a port scan as an incident.

1. Port Scan: Find FortiGate SSL-VPN Portals

SSL-VPN is the affected surface, so enumerate where it is listening:

• • 443 — SSL-VPN web portal on the default configuration
• • 10443 — very common alternate SSL-VPN port when 443 is used by something else
• • 8443, 4443 — other frequently chosen alternates
• • 541, 8013 — FortiManager and FortiGate management channels, useful for identifying the estate

Because the port is operator-chosen, an SSL-VPN portal on a non-standard port is normal rather than suspicious. Scan a range and fingerprint what answers, rather than checking 443 and concluding the portal is absent.

2. TLS Inspect: Identify Fortinet Certificates

Read the certificate on each candidate port. FortiGate devices commonly present a self-signed certificate with FortiGate or Fortinet in the subject or issuer, and default deployments often retain a factory certificate naming the model or serial. Where operators have installed a public certificate, the SAN list usually still carries a vpn.* or remote.* hostname that identifies the function.

3. HTTP: Fingerprint the SSL-VPN Portal

The FortiGate SSL-VPN login portal is distinctive. Look for /remote/login, redirects to /remote/login?lang=, and static assets served from /sslvpn/ paths. The lang parameter is a direct pointer at this issue: the language-file directory is exactly where the 2025 symlink was planted, which is why the SSL-VPN UI hardening — and this bypass of it — lives on that code path.

Restrict this to unauthenticated fingerprinting of systems you are authorised to test. Establishing that a portal exists and which branch serves it is discovery; attempting to retrieve files through the symlink path is exploitation, and on a device that may already be compromised it also risks contaminating evidence.

4. DNS: Map the Remote-Access Estate

Query for the names organisations give remote access: vpn.*, sslvpn.*, remote.*, fw.*, fortigate.*, fg-*. Branch offices and acquired subsidiaries are where forgotten FortiGates live, and an old 6.4 or 7.0 device at a remote site is precisely the profile with no in-branch fix.

5. CVE Lookup: Confirm Status and Scope

Pull CVE-2025-68686 and note both scores — 5.9 base at NVD, 5.3 as displayed by Fortinet with temporal metrics applied. Neither number reflects the KEV listing, which is the reason this is on today's deadline rather than next quarter's backlog.

Cross-Reference with External Data

Remediation

1. Upgrade to 7.6.2 or 7.4.7 and above. If you run 7.2, 7.0, or 6.4, there is no fixed build in your branch — plan a migration to a fixed release rather than waiting for a patch that is not coming.
2. Establish whether SSL-VPN was ever enabled. Fortinet states that products which never had SSL-VPN enabled are not impacted. The operative word is never. A device with SSL-VPN disabled today, but enabled at some point during the exposure window, does not meet that bar — check configuration history, not just the running config.
3. Apply the virtual patch if you cannot upgrade now. FG-VD-60389.0day in FMWP database update 26.033 is Fortinet's stopgap; it requires a licensed and enabled engine to do anything.
4. Treat this as an incident-response question, not just a patching one. The prerequisite is a prior compromise. If a device was running an affected build with SSL-VPN enabled, the question is not only "is it patched now" but "was a symlink ever planted, and what was read through it." Review for unexpected symbolic links in the SSL-VPN language-file directory.
5. Assume configuration disclosure and rotate accordingly. If review indicates the device was compromised, the configuration should be treated as read by a third party: rotate local accounts, VPN pre-shared keys, certificates, RADIUS and LDAP bind credentials, and any shared secrets the config carries. Upgrading removes the symlink; it does not un-disclose what was already read.
6. Scope the log review to the whole exposure window. The 2025 technique was designed to survive upgrades and evade detection, so the relevant period runs from when the device was first exposed on an affected build — not from the KEV date, and not from the date you upgraded.

Triage Notes

Sources

• → Fortinet PSIRT: FG-IR-25-934 (CVE-2025-68686)
• → Fortinet PSIRT Blog: Analysis of Threat Actor Activity (April 2025 symlink technique)
• → NVD: CVE-2025-68686
• → CISA Known Exploited Vulnerabilities Catalog (CVE-2025-68686 added July 27, 2026)