CVE-2025-68686 is an unauthenticated information disclosure flaw (CWE-200) in the FortiOS SSL-VPN web portal. Fortinet published advisory FG-IR-25-934 on February 10, 2026; CISA added the CVE to the Known Exploited Vulnerabilities catalog on July 27, 2026 with a federal remediation deadline of August 10, 2026.
The scoring needs stating up front, because it is unusual. Fortinet scores this 5.3 (temporal) and NVD publishes 5.9 (base), with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. Those are Medium numbers on a KEV-listed CVE, and EPSS sits at 0.0003. The reason is that this is not a standalone entry point. It is a bypass of the patch Fortinet shipped for a persistence technique, and it only pays off on an appliance an attacker already compromised at filesystem level through an older SSL-VPN flaw. CISA's own SSVC decision records Exploitation: active, Automatable: no, Technical Impact: partial.
That changes what you do about it. Patching closes a read path on devices that were already breached. If your FortiGate was in the 2025 symlink-persistence population, the patch is the smaller half of the job and credential rotation is the larger half.
Am I vulnerable?
Two conditions have to hold: the device runs an affected FortiOS build, and the SSL-VPN web portal is enabled. Fortinet states products without SSL-VPN enabled are not affected.
Affected versions
| Branch |
Vulnerable range |
Fixed release |
| FortiOS 7.6 |
7.6.0 through 7.6.1 |
7.6.2 or above |
| FortiOS 7.4 |
7.4.0 through 7.4.6 |
7.4.7 or above |
| FortiOS 7.2 |
All versions (7.2.0 through 7.2.13) |
No in-branch fix. Migrate to 7.4.7+ or 7.6.2+ |
| FortiOS 7.0 |
All versions (7.0.0 through 7.0.19) |
No in-branch fix. Migrate to 7.4.7+ or 7.6.2+ |
| FortiOS 6.4 |
All versions (6.4.0 through 6.4.16) |
No in-branch fix. Migrate to 7.4.7+ or 7.6.2+ |
The 7.2, 7.0 and 6.4 rows are the operationally awkward ones. Fortinet's remedy for those branches is "migrate to a fixed release", which means a major-version upgrade rather than a patch, and that is a change-window conversation, not a Tuesday-night one.
Diagnostic checks
These are read-only. Commands 1 and 2 determine whether you are in scope; 3 and 4 determine whether your compensating controls are actually live.
- Firmware level:
get system status. The Version: line gives the branch and build. Anything reporting v7.6.0, v7.6.1, v7.4.0 through v7.4.6, or any v7.2.x, v7.0.x or v6.4.x is in an affected range.
- Is the affected surface even on?
show vpn ssl settings. set status enable alongside a set source-interface naming an internet-facing port means the portal is live. An empty stanza or set status disable puts you in Fortinet's "not affected" category.
- What is exposed per interface:
show full-configuration system interface | grep -B10 -i allowaccess. An external interface carrying https in allowaccess means the listener is reachable from untrusted networks.
- Is the virtual patch loaded?
diagnose autoupdate versions. Fortinet's only non-upgrade mitigation is signature FG-VD-60389.0day, shipped in FMWP database 26.033. An FMWP database older than 26.033, or a contract showing expired or not licensed, means the signature is not protecting the device.
- External exposure check (run from outside):
curl -4 -sI --max-time 10 https://<fortigate-fqdn>/remote/login. A 200 or a redirect to the portal confirms the SSL-VPN surface is internet-reachable. This confirms exposure only, not patch level.
The check that matters most is not on that list, because it is not a version question. This CVE is only reachable through a symlink an intruder planted earlier, so the real question is whether your appliance is carrying one. On an affected build, the language-file symlink should resolve to the custom language directory; if it resolves to the root filesystem, the device is backdoored and the CVE is the least of the problem. Note the sequencing trap: upgrading to 7.6.2, 7.4.7, 7.2.11, 7.0.17 or 6.4.16 removes the symlink, and Fortinet's AV/IPS signature removes it automatically where licensed. If you need the forensic evidence, preserve it before you patch.
Vulnerability
The underlying technique is one Fortinet documented in 2025. A threat actor with filesystem access placed a symbolic link joining the device root filesystem into the directory that serves SSL-VPN portal language files, a directory reachable without authentication. That link survived firmware upgrades and gave continued unauthenticated read access to files on the appliance, including its configuration.
Fortinet's fix added a validation check on requests to that directory. Peter Gabaldon of ITRES Labs, credited in FG-IR-25-934, found that the check compared the request against a literal path segment as a string, while the web server independently normalized the path before resolving it on disk. Inserting a redundant path separator produces a request the string comparison does not recognize and the filesystem resolves identically. This is a parser differential between a substring match and path normalization, which is a recurring failure mode when a security check operates on request text rather than on the resolved target.
Two things follow. First, the impact is confidentiality-only: read access, no write, no code execution, which is why the CVSS lands at Medium. Second, the precondition is a prior compromise, which is what the AC:H rating encodes. AC:H here does not mean the request is hard to construct. Gabaldon's disclosure timeline runs from discovery on April 26, 2025 to report on October 9, 2025 to patch on February 10, 2026.
Gabaldon also published scale data. Of roughly 3,500 internet-exposed FortiGate units scanned, about 4.11 percent still carried the malicious symlink, and only 787 were running firmware containing the symlink integrity check at all. Shadowserver counted 16,620 exposed devices carrying the backdoor at the time of the original 2025 disclosure. Fortinet's advisory page still reads "no known exploitation" while CISA has KEV-listed it; the KEV entry is the stronger signal, but the vendor has not corroborated it.
Threat model
Who would exploit this: Because the flaw requires pre-existing filesystem access, the natural operators are the actors who ran the 2023 to 2025 FortiOS exploitation waves against CVE-2022-42475, CVE-2023-27997 and CVE-2024-21762 and planted symlink persistence at the time, primarily espionage-motivated state-aligned intrusion sets and initial-access brokers holding an inventory of previously compromised appliances. The published bypass writeup opens a cheaper second category: opportunistic scanners probing exposed portals for symlinks another actor left behind, reading the configuration for free. Insider abuse is not a meaningful category, since an insider with device access has no need for the bypass.
What they are after:
- Persistence recovery: regaining unauthenticated read access to appliances the owner believes were remediated, which is the bug's entire purpose
- Credential harvest from the configuration: local admin password hashes, SSL-VPN and local user accounts, IPsec pre-shared keys, LDAP and RADIUS bind credentials, API tokens, SNMP community strings
- Reconnaissance for lateral movement: policy, NAT tables, routing and VPN topology reveal internal addressing and the inventory of published services
- Resale: validated, still-live access to a named organization's perimeter device is the product initial-access brokers sell
- Pre-positioning for follow-on intrusion including ransomware (CISA records known ransomware campaign use as Unknown, so treat this as a category rather than an observation)
Attack chain: An attacker who compromised the FortiGate earlier through an older FortiOS flaw planted a symbolic link exposing the root filesystem through the portal's publicly reachable language-file directory. Fortinet's 2025 mitigation blocked requests to that directory with a string check, and this CVE defeats that check with a path-normalization trick. The attacker then issues an ordinary unauthenticated HTTPS request and reads configuration and other filesystem contents. The pivot is credential reuse: authenticating as a legitimate SSL-VPN or administrative user with what the configuration disclosed, or taking the LDAP or RADIUS bind account into Active Directory.
Blast radius: A FortiOS configuration functions as a keyring for the network behind it: administrator password hashes, the SSL-VPN user list with group and portal mappings, IPsec pre-shared keys, LDAP and RADIUS bind credentials (frequently a domain service account with directory read across the forest), API tokens, SNMP strings, and any certificates or private keys stored on the device. The policy set, NAT table and routing configuration supply an accurate map of internal addressing and of internal services published to the internet, removing most of the discovery work from the next stage. Access is read-only, so nothing on the appliance is modified, but the disclosed material converts directly into authenticated access elsewhere.
No named actor or campaign is publicly tied to exploitation of this bypass, and the 2025 symlink activity was never publicly attributed either.
Mitigation
Patch
| Branch |
Action |
| FortiOS 7.6 |
Upgrade to 7.6.2 or above |
| FortiOS 7.4 |
Upgrade to 7.4.7 or above |
| FortiOS 7.2 / 7.0 / 6.4 |
No in-branch fix. Migrate to 7.4.7+ or 7.6.2+ |
Upgrading to 7.6.2, 7.4.7, 7.2.11, 7.0.17 or 6.4.16 also removes the planted symlink and changes the portal so it will not serve one. Preserve forensic evidence first if you intend to investigate.
Rotate credentials, independently of patching. This is the step most often skipped and it matters more than the upgrade. Patching closes the read path but does not invalidate anything already read, and the attacker no longer needs the appliance to use it. Rotate administrator and SSL-VPN user credentials, IPsec pre-shared keys, LDAP and RADIUS bind accounts, API tokens and SNMP strings, and reissue affected certificates. Fortinet's standing guidance from the 2025 campaign is to treat all configuration on any previously exposed device as compromised. A patched device carrying unrotated secrets is not a recovered device.
Configuration mitigation
Fortinet published no CLI workaround for this CVE. Its only vendor-stated non-upgrade mitigation is virtual patch FG-VD-60389.0day in FMWP database 26.033, which requires a licensed and enabled FortiGuard IPS/FMWP subscription with a current database. The advisory does state that products without SSL-VPN enabled are not affected, which makes disabling an unused portal a supported way out.
Disable the SSL-VPN web portal if it is not in use:
# READ-ONLY first: inspect current settings
show vpn ssl settings
# If SSL-VPN is unused, disable the listener:
config vpn ssl settings
unset source-interface
unset source-address
unset source-address6
set status disable
end
The remaining snippets are standard FortiOS hardening rather than advisory guidance. They reduce exposure while an upgrade is scheduled; they do not remediate the flaw.
Trim allowaccess so the HTTPS listener is not internet-facing:
# READ-ONLY first: see what is exposed
show full-configuration system interface | grep -A2 -i allowaccess
config system interface
edit "wan1"
set allowaccess ping
next
end
Constrain administrative access to management networks:
# READ-ONLY inventory of admin accounts and trusted hosts
show system admin
config system admin
edit "admin"
set trusthost1 10.0.0.0 255.255.255.0
set trusthost2 192.0.2.0 255.255.255.0
next
end
Limit who can reach the SSL-VPN listener with a local-in policy (requires an address group of permitted sources):
config firewall local-in-policy
edit 1
set intf "wan1"
set srcaddr "VPN-Allowed-Sources"
set dstaddr "all"
set service "HTTPS"
set schedule "always"
set action accept
next
edit 2
set intf "wan1"
set srcaddr "all"
set dstaddr "all"
set service "HTTPS"
set schedule "always"
set action deny
next
end
Compensating controls
Ensure IPS is applied to the SSL-VPN VIP or policy so the virtual patch can actually fire, and confirm the FMWP database is at 26.033 or later. Treat the management plane as a closed set of source addresses and alert on anything outside it. Where a WAF, reverse proxy or load balancer already fronts the portal, that device is the only place you can see the exploitation request at all, so make sure its logs are shipped and retained. Finally, scope the credential rotation by asking which secrets were resident in the configuration during the exposure window rather than which ones look sensitive today.
Detection (starter rules, validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production.
Neither Fortinet nor CISA has published Sigma, Suricata or YARA content for this CVE. Fortinet's coverage is proprietary IPS/AV signatures plus the virtual patch, so what follows is original behavioral work grounded in the published mechanism.
Network and log signals
- Unauthenticated requests to the portal's language-file directory using a non-canonical path. Visible only where a WAF, reverse proxy or load balancer terminates TLS in front of the FortiGate, because FortiOS event logs do not record portal request URIs.
- Large successful (HTTP 200) responses to unauthenticated portal paths. Post-patch the device returns 403, so a 403 spike on those paths indicates probing rather than a breach.
- IPS and virtual-patch telemetry: alert on any
type="utm" subtype="ips" log referencing FG-VD-60389.0day. High fidelity, and it needs no TLS termination on your side.
- Any
srcip in a type="event" subtype="system" record with ui="https(x.x.x.x)" that is not a known jump host or management subnet. The management plane should be an enumerable set, which makes any new source a strong signal.
- Admin login anomalies:
logid="0100032001" (success) or 0100032002 (failed) where srcip falls outside management ranges or lands outside change-window hours. Success on first attempt from a source that has never authenticated before is the pattern to hunt.
- The signal that actually matters: valid credential use after you patched. This is a disclosure bug, so alert on successful admin or SSL-VPN authentication using accounts, certificates or PSKs that predate the exposure window and have not been rotated. Absent rotation, the attacker's next login is indistinguishable from a legitimate one.
- SSL-VPN success from new ASNs or geographies with little preceding failure activity:
logid="0101039424" not preceded by 0101039426 / action="ssl-login-fail". Credentials lifted from a config do not need brute forcing, so the absence of failures is itself suspicious.
- Configuration revision changes with no matching change ticket:
type="event" subtype="system" records carrying cfgpath, cfgobj and cfgattr. Treat unmatched revisions on an internet-exposed FortiGate as an incident until disproven.
- New or modified accounts under
system.admin, user.local or vpn.ssl.settings, anything granted accprofile super_admin, and trusted hosts appended to an existing admin account (a quieter variant than creating a new one).
- Unexpected IPsec phase1 negotiations from new peer addresses using an existing PSK, and gzip or archive files matching FortiOS config naming appearing on jump hosts, file shares or cloud storage.
YARA
rule FortiOS_Config_Backup_Staged_Or_Exfiltrated
{
meta:
description = "Detects a cleartext FortiGate/FortiOS configuration backup, the artifact disclosed by CVE-2025-68686 (FG-IR-25-934). Intended for attacker staging hosts, exfiltration archives, DFIR disk images and shared storage, NOT for scanning the FortiGate itself."
author = "CVE Brief (AI-generated starter rule)"
date = "2026-08-03"
reference = "https://fortiguard.fortinet.com/psirt/FG-IR-25-934"
cve = "CVE-2025-68686"
confidence = "medium"
note = "AI-generated starter rule. Validate before deploying. Matches DECOMPRESSED content only: the disclosed file is gzip, so scan after decompression or use a scanner that unpacks archives. Contains no CVE-specific hashes or infrastructure indicators by design."
strings:
$hdr1 = "#config-version=" ascii
$hdr2 = "#conf_file_ver=" ascii
$hdr3 = "#buildno=" ascii
$hdr4 = "#global_vdom=" ascii
$cfg1 = "config system global" ascii
$cfg2 = "config system admin" ascii
$cfg3 = "config system interface" ascii
$cfg4 = "config vpn ssl settings" ascii
$cfg5 = "config vpn ipsec phase1-interface" ascii
$cfg6 = "config user local" ascii
$cfg7 = "config system dhcp server" ascii
$sec1 = "set passwd ENC " ascii
$sec2 = "set psksecret ENC " ascii
$sec3 = "set private-key \"-----BEGIN" ascii
$sec4 = "set accprofile \"super_admin\"" ascii
condition:
filesize < 64MB
and (
( 2 of ($hdr*) and 2 of ($cfg*) )
or ( 3 of ($cfg*) and 1 of ($sec*) )
)
}
Sigma
title: FortiOS SSL-VPN Language Directory Path Normalization Bypass (CVE-2025-68686)
id: 7b1e4c8a-2f63-4d19-9a5e-c0d84f7b1e62
status: experimental
description: |
Detects requests to the FortiOS SSL-VPN portal that reach the language file
directory using a non-canonical path, the documented bypass for the
FG-IR-25-934 symlink persistence patch, and requests that read FortiOS
configuration or key material through that directory.
Requires a TLS-terminating proxy, WAF or load balancer in front of the
FortiGate: FortiOS event logs do not record SSL-VPN portal request URIs, so a
product:fortigate logsource cannot see this traffic.
AI-generated starter rule. Validate in your environment before deploying.
references:
- https://fortiguard.fortinet.com/psirt/FG-IR-25-934
- https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-activity
author: CVE Brief (AI-generated starter rule)
date: 2026/08/03
tags:
- attack.credential-access
- attack.t1552.001
- attack.persistence
- attack.t1505
- cve.2025-68686
logsource:
category: webserver
definition: 'Requires a TLS-terminating device (WAF, reverse proxy or load balancer) in front of the FortiGate SSL-VPN portal, or FortiWeb logs. FortiOS native event logs do not contain request URIs.'
detection:
selection_noncanonical:
cs-uri-stem|contains:
- '/lang//'
- '/lang/./'
- '/lang/%2f'
- '/lang%2f%2f'
selection_lang:
cs-uri-stem|contains: '/lang/'
selection_sensitive:
cs-uri-stem|contains:
- '/data/config/'
- '/data/etc/'
- '/data2/'
- '.conf.gz'
condition: selection_noncanonical or (selection_lang and selection_sensitive)
fields:
- c-ip
- cs-method
- cs-uri-stem
- sc-status
- sc-bytes
- cs-user-agent
falsepositives:
- Authorized vulnerability scanners and penetration tests probing FG-IR-25-934, which reproduce the non-canonical path pattern exactly
- Web crawlers, uptime monitors and link checkers that emit paths containing duplicated slashes
- Misconfigured reverse proxies or CDN rewrite rules that concatenate a base path with a leading slash
- Organizations serving genuinely customized SSL-VPN portal language packs
level: high
Rule notes
The Sigma rule keys on the published bypass mechanism: the patch compared the request against a literal path segment as a string, so a non-canonical separator skips validation while the web server resolves the path identically. A second branch flags reads of configuration or key material through the language directory. It targets category: webserver rather than product: fortigate deliberately, because FortiOS event logs do not record portal request URIs, so the rule only fires where something terminates TLS in front of the appliance. If you have no such device, rely on the log signals above and on Fortinet's own IPS virtual patch.
The YARA rule does not detect exploitation at all. It detects the stolen artifact, a cleartext FortiGate configuration, sitting on a staging host or in an exfiltration archive, and it cannot match the gzip stream as transmitted. Neither rule detects the prerequisite intrusion, and neither detects the quiet end state that matters most: an attacker authenticating with valid credentials harvested from the leaked configuration after you patched. That case is covered by rotation, not by detection.
References