Patching is not cleaning: FortiOS and the extra slash

On 27 July, CISA added a FortiOS flaw almost nobody had on their list to its exploited-vulnerabilities catalogue, with a deadline attached: 10 August. CVE-2025-68686 opens no new door: it reopens the one Fortinet believed it had closed in April 2025, and it does so with one extra slash in the path. If you have a FortiGate that sat on the internet with SSL-VPN enabled between 2022 and 2024, this advisory is not about patching. It is about working out what somebody took, and since when.

It all starts in a language-files folder

In April 2025, Fortinet's security team published something that reads oddly the first time. Somebody who had broken into FortiGate devices using three already-known, already-patched vulnerabilities — those of advisories FG-IR-22-398, FG-IR-23-097 and FG-IR-24-015 — was leaving behind a symbolic link joining the user filesystem to the root filesystem, and leaving it precisely in the folder from which the SSL-VPN portal serves its language files. That folder is public: you do not need to log in to request a language file. From then on, anyone who knew the path had read-only access to files on the device, "which may include configurations", in the advisory's own words. Read-only, yes; we will get to why that is less comforting than it sounds.

The line that matters in Fortinet's advisory is this one: "even if the customer device was updated with FortiOS versions that addressed the original vulnerabilities, this symbolic link may have been left behind". You patched, you closed the way in, and the spare key stayed outside. The Shadowserver Foundation counted 16,620 compromised devices as of 16 April 2025, up from an initial tally of around 14,000. Fortinet shipped an antivirus/IPS signature that removes the link and FortiOS releases that also stop the portal from serving such links, and asked customers to do something that is easy to say and very rarely done: treat all configuration as potentially compromised.

No malware, no implant, no odd binary and no call home that a NetFlow feed could catch: a file that points somewhere else, a legitimate filesystem feature used where it should not be. That is why nobody spotted it for months. There was nothing strange to see.

The patch was a string comparison

Researcher Peter Gabaldón, of ITRESIT, did not take the patch on trust: he opened it. The new check leaned on the strstr function, looking for the text /lang/custom inside the requested path. If the text was there, the link's target was validated and anything out of place was blocked. If it was not, the request carried on. The problem is that the filesystem and the path as written are not the same thing.

.../lang/custom/...    strstr("/lang/custom") -> match         -> link is validated  -> blocked
.../lang//custom/...   strstr("/lang/custom") -> no match      -> nothing validated -> 200 OK
# to the filesystem both paths are the same directory;
# to a text comparison they are two different strings.

One extra slash. This is not some exotic slip: it is the pattern that has been failing in web security forever, validating the text that arrives over the wire instead of validating the object that text ends up resolving to. It is the same family as directory traversal, WAF blocklists and half the frights anyone who writes code gets sooner or later. The lesson is architectural and it fits in one line: validate after normalising, or validate the real destination — where does this link point? — rather than the string.

The timeline the researcher himself publishes is worth reading slowly. He found the bypass on 26 April 2025 — the same month as the original advisory, while analysing the freshly shipped patch. He reported it to Fortinet's security team on 9 October 2025. The corrected patch came out on 10 February 2026 and public disclosure the following day. And CISA did not add it to the exploited-vulnerabilities catalogue until 27 July 2026. Fifteen months between somebody seeing the hole and the thing becoming a deadline. And it is worth being precise about what that means: those April 2025 releases also removed the link and added an antivirus signature to strip it, so plenty of devices came out clean. What did not work during those fifteen months was the barrier: wherever the link was still in place — or got put back — the portal served it just the same to anyone who asked for the path with an extra slash.

The same researcher scanned 3,503 internet-exposed FortiGates and found 144 still compromised (4.11%), while 787 were already running the firmware with the integrity check. It is one person's sample, not a census, and should be read as such. But four in a hundred is not an anecdote.

The small print: on 7.2, 7.0 or 6.4 there is no patch for you

The table in advisory FG-IR-25-934 says this: affected versions 7.6.0 to 7.6.1 (fixed by moving to 7.6.2 or above) and 7.4.0 to 7.4.6 (to 7.4.7 or above). And for the 7.2, 7.0 and 6.4 branches, "all versions", with a solution that takes up one line in the table: migrate to a fixed release. Translated: on those branches there is no patch. You have to jump branch.

A branch jump means a maintenance window, checking which features behave differently on the other side, confirming that tunnels and policies still do the same thing and, sometimes, discovering that the model you own does not reach the branch you need. None of that happens on a Tuesday at six. And plenty of people are on 7.2 on purpose, for stability, because it works and because every jump has brought them some fright. It is a defensible decision: staying on a mature branch instead of chasing the newest one usually works out. What almost never gets written next to that decision is its expiry date. This advisory is that date.

There is one detail worth putting on the table because it changes the reading. The April 2025 fix did reach those branches: the releases Fortinet published then were 7.6.2, 7.4.7, 7.2.11, 7.0.17 and 6.4.16. The bypass fix did not. Anyone who updated to 7.2.11 back then — doing exactly what they were told — has since February 2026 had a portal capable of serving the link if one were there, and no release in their own branch to move to.

Before planning anything, three things can be checked today without touching the configuration: exactly which release each device runs (the advisory's table decides, not the feeling of being up to date); whether the antivirus/IPS signature Fortinet published in April 2025 to detect and remove the link is applied and current; and whether the SSL-VPN portal is reachable from the internet or only from where it should be. Those are three facts, not three opinions, and they are enough to order the work. What the version number will not tell you is whether that device ever had the link in place: for that you ask the vendor's support with the diagnostics file in front of you.

The myth: "we already updated it"

None of this is about Fortinet any more. Patching is an action; being clean is a conclusion. The first happens in a half-hour window and gets logged on the job sheet. The second needs evidence, and evidence costs somebody hours of reading logs. When a perimeter device shows up in an advisory, almost every organisation performs the action and skips the conclusion, because the action can be shown in a steering meeting and the conclusion has no box on any dashboard.

What stands out is that both official sources in this case say precisely the opposite. Fortinet asks you to treat all configuration as potentially compromised. And CISA's KEV entry, under required action, does not stop at "apply the patch": it points explicitly at its forensics triage requirements. The catalogue is not asking you to update. It is asking you to look.

The score — 5.9 base, the one we mentioned in passing yesterday — is low for a reasonable reason: to use this, an attacker must already have got in some other way. On 16,620 devices, that precondition stopped being a hypothesis in April 2025.

What you lose when you lose the configuration

This is where "read-only" stops being a comfort. A perimeter firewall's configuration is the map of the house with the keys taped to it: local users and their hashes, pre-shared keys for the IPsec tunnels, the credential the device uses to query the corporate directory, certificates, internal addressing, which service is published and where it points. Reading it is enough. With that in hand there is no need to come back in through the firewall: you come in the way everybody does, with a valid credential, at a normal hour. And that, in the logs, looks an awful lot like an employee working. It is the same criterion we applied to the zero-days in a VPN concentrator last week.

And here we should say something that does not flatter the people who sell what we sell: an EDR does not run inside your FortiGate. On a closed appliance there is no agent to install; the box is, by design, a blind spot. What you can do is change the premise — that configuration has been outside your control since 2025 at the earliest — and watch everything else: service credentials being used at hours that do not add up, VPN logins from new places, local firewall accounts nobody remembers creating, a lateral hop from the machine of somebody who had never touched that server. That is visible, and it is visible from the inside. The difference between having logs and having somebody read them is the one we wrote about this morning regarding alerts nobody attends to: an alert with no owner is not a defence, it is a record.

The question we ask in an audit

It is not "is it patched?". An inventory answers that. The useful one is what did your firewall know that is no longer a secret? If the device sat on the internet with SSL-VPN between 2022 and 2024, if nobody has rotated anything since, and if the answer to "who reviewed the logs that week?" is silence, the honest reply is: everything.

A patch closes a door and can be shown to people. Cleaning is another job: longer, duller, with no CVSS score to defend it in a budget meeting and no clear moment at which you get to say it is done. That is why it almost never happens. And it is why four in every hundred devices in that sample still had the link in place.

Sources (verified): CVE-2025-68686 added to the exploited-vulnerabilities catalogue on 27 Jul 2026, due 10 Aug 2026, description and required action pointing at the forensics triage requirements: CISA, Known Exploited Vulnerabilities Catalog. Vendor advisory FG-IR-25-934, "SSL-VPN Symlink Persistence Patch Bypass" (published 10 Feb 2026, updated 12 Mar 2026): affected and fixed versions, CVSS 5.3 with temporal metrics, credit to Peter Gabaldón (ITRESIT). Base score 5.9 supplied by Fortinet as CNA: NVD. Symbolic link in the SSL-VPN language-files folder, persistence after updating, initial-access CVEs, the AV/IPS signature, the releases published at the time (7.6.2, 7.4.7, 7.2.11, 7.0.17 and 6.4.16) and the recommendation to treat configuration as compromised: Fortinet PSIRT, April 2025. The count of 16,620 devices by Piotr Kijewski (Shadowserver Foundation) as of 16 Apr 2025: BleepingComputer. Technical analysis of the double-slash bypass, disclosure timeline and the scan of 3,503 devices with 144 compromised: Labs at ITRES, 11 Feb 2026. The review criteria, the reading of the case and the opinions are ours.