Skip to content

FortiOS CVE-2025-68686 symlink-persistence bypass

Summary

On July 27, 2026, CISA added CVE-2025-68686 to the Known Exploited Vulnerabilities catalog. The flaw allows crafted unauthenticated HTTP requests to bypass Fortinet's protection against a previously implanted SSL-VPN symbolic-link persistence mechanism and expose files from a FortiGate filesystem. Exploitation is conditional: an attacker must already have compromised the appliance through another vulnerability and obtained filesystem-level access to plant the link.

Fortinet's underlying incident analysis describes attackers exploiting older FortiOS vulnerabilities and creating a symbolic link between the user and root filesystems inside an SSL-VPN language-file directory. That link could survive installation of fixes for the original entry vulnerability and preserve read-only access to files, including device configurations. Fortinet says devices that never had SSL-VPN enabled are not affected by this issue.

This is a post-compromise persistence and information-exposure problem, not a stand-alone initial-access path. Treat any affected or previously exploited appliance as compromised: preserve evidence, remove it from exposure, upgrade, inspect configuration and filesystem integrity, rotate secrets contained in or reachable through the configuration, and rebuild when integrity cannot be established.

Tags

Why this matters

  • CISA's KEV addition supplies current evidence of exploitation and sets an August 10, 2026 remediation due date for applicable US federal systems.
  • Patching only the original entry vulnerability may not remove a symlink already planted in the user filesystem. Fortinet explicitly observed persistence after the original access vector was closed.
  • Exposed FortiGate configuration can contain or reveal local accounts, password material, VPN settings, certificates, network topology, policies, and other information useful for renewed access and lateral movement.
  • The precondition changes prioritization but not incident scope: successful use means the attacker had already reached the appliance filesystem through another flaw.

Exposure and affected versions

Fortinet advisory FG-IR-25-934 lists these affected branches:

Branch Affected Fortinet guidance
FortiOS 7.6 7.6.0 through 7.6.1 Upgrade to 7.6.2 or later
FortiOS 7.4 7.4.0 through 7.4.6 Upgrade to 7.4.7 or later
FortiOS 7.2 All versions in the advisory table Migrate to a fixed release
FortiOS 7.0 All versions in the advisory table Migrate to a fixed release
FortiOS 6.4 All versions in the advisory table Migrate to a fixed release

Fortinet's incident-analysis post identifies 7.2.11, 7.0.17, and 6.4.16, alongside 7.6.2 and 7.4.7, as releases that remove the malicious link and prevent SSL-VPN from serving such links. Follow Fortinet's supported upgrade path rather than treating this table as permission to remain on an obsolete branch.

Appliances that never had SSL-VPN enabled are outside the issue scope according to Fortinet. Do not infer that currently disabled SSL-VPN proves historical non-exposure; validate configuration history where possible.

Exploitation and evidence caveats

  • CISA categorizes the vulnerability as known exploited as of July 27, 2026.
  • Fortinet's advisory page, last updated March 12, still displays Known Exploited: No. That older field conflicts with the newer KEV determination and should not be used to discount current exploitation.
  • CISA lists ransomware use as Unknown and publishes no actor, victim, request, path, or infrastructure indicators in the KEV entry.
  • Fortinet's 2025 incident post says the precursor activity was not concentrated in a specific region or industry. It references exploitation of known vulnerabilities including FG-IR-22-398, FG-IR-23-097, and FG-IR-24-015, but does not publicly identify the actor.

Defensive actions

Immediate response

  1. Identify every FortiGate that currently has or historically had SSL-VPN enabled, including standby and decommissioning assets.
  2. Record model, serial, FortiOS build, uptime, configuration revision, HA status, licenses, and management exposure before making changes.
  3. Preserve configuration, event, VPN, administrator, system, crash, and available filesystem/integrity evidence. Maintain chain of custody where an incident is plausible.
  4. Isolate internet-exposed management and SSL-VPN paths as operationally feasible. Do not rely on disabling the vulnerable route as proof that an existing link is gone.
  5. Upgrade through Fortinet's supported path. Fortinet also lists virtual patch FG-VD-60389.0day in FMWP database update 26.033; use compensating controls only as a bridge to supported remediation.
  6. Review the full configuration and follow Fortinet's compromised-device recovery guidance. Reimage or replace the appliance if filesystem integrity cannot be established.

Credential and trust reset

  • Treat the device configuration as potentially disclosed.
  • Rotate local and remote administrator credentials, VPN secrets, LDAP/RADIUS/TACACS integration secrets, API tokens, automation credentials, pre-shared keys, and private keys or certificates that could have been exposed.
  • Revoke active administrative and VPN sessions and review newly created accounts, API administrators, trusted hosts, policies, routes, address objects, and authentication changes.
  • Scope downstream identity, management, backup, hypervisor, and network-device activity from the appliance and VPN address pools.

Hunting

  • Review historical exploitation alerts and appliance logs for the precursor vulnerabilities cited by Fortinet and for unexplained configuration reads or exports.
  • Compare current configuration and filesystem-integrity results with known-good backups, but do not restore an unverified backup that may contain the planted link.
  • Investigate administrative successes after exploit traffic, unexpected SSL-VPN language-file requests, changes in user-writable SSL-VPN content, and outbound connections or lateral movement from management interfaces.
  • Use Fortinet support telemetry and vendor-provided checks where available; the public sources do not expose a safe universal filename or request signature for the malicious link.

Sources