Attackers can slip past Fortinet's fix and keep reading a hacked firewall's files, CISA warns

Fortinet spent last year telling FortiGate owners to patch, then patch again, because attackers who had broken into the firewalls left themselves a way back in. CVE-2025-68686 is the sequel: a way to slip past the fix that was supposed to close that back door. On July 27, 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog, the list of bugs it has evidence are being used in real attacks, and set a federal patch deadline of August 10.

The severity number is deliberately unremarkable. Fortinet scores it 5.3, a plain medium. Read that as a trap. This is not a flaw that lets a stranger break in. It is a flaw that lets an intruder who is already inside stay there, quietly reading the firewall's files long after you thought you had cleaned up.

The back door this reopens

To understand the bug you have to remember the original trick. Through 2023 and 2024, attackers exploited a run of older FortiGate SSL-VPN flaws, the browser-based VPN portal that runs on the device (CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762 among them). Once inside, some of them planted a symbolic link, a filesystem shortcut, inside the folder that serves the SSL-VPN's language files. That link pointed at the device's root filesystem. Because it lived in a user-writable area and rode along with a legitimate feature, it survived reboots and, crucially, survived patching. Even after an owner fixed the original hole, the symlink kept handing the attacker read-only access to the whole device: configuration, settings, and any secrets stored in them. Fortinet reported more than 16,000 devices carrying that persistence mechanism in April 2025 and shipped a patch to stop the language folder from serving the linked content.

CVE-2025-68686 is a bypass of that patch.

What actually broke

Fortinet's fix added a guard so the SSL-VPN would refuse to serve the symlinked path. The bypass, found and documented by Peter Gabaldon of the Spanish security firm ITRESIT, is a path-normalization mistake. Add an extra slash inside the request URL for the language directory and the guard no longer recognizes the path as the one it is meant to block, yet the underlying web server still resolves the doubled path to the same file and serves it. The protected content comes back and the check is simply stepped over.

One condition matters, and it bounds the blast radius. As Fortinet's advisory and the CISA entry both state, an attacker "would need first to have compromised the product via another vulnerability, at filesystem level." In plain terms: this is not initial access, it is persistence. It only helps someone who already has a foothold on the box, which is exactly the population the earlier cleanup was meant to evict. If a FortiGate of yours was breached before you patched the symlink issue, this bug means your cleanup may not have actually locked them out.

That is also why a 5.3 landed on a federal must-patch list. Severity scores measure how hard a flaw is to reach and how much one use of it costs you. They are poor at pricing persistence, which is worth far more to an intruder than any single request. CISA's catalog is the better signal here than the score: it means this is being used now, not that it might be one day.

Am I affected

The affected range is broad. On the current trains, FortiOS 7.6.0 through 7.6.1 and 7.4.0 through 7.4.6 are vulnerable, and the entire 7.2, 7.0, and 6.4 lines are affected in all versions. The fixes are FortiOS 7.6.2 or later and 7.4.7 or later. If you are on 7.2, 7.0, or 6.4, there is no patch that keeps you on that branch: Fortinet's guidance is to migrate to a fixed release. One note on the CISA record, since firewall bugs on the exploited list are often tied to ransomware crews: for this one, the catalog's ransomware field reads "unknown," so treat the persistence risk on its own terms rather than pinning it to a named group.

Patching is not the finish line here

Upgrade first, and on the exploited-catalog clock rather than the convenience one: move to FortiOS 7.6.2 or later, or 7.4.7 or later, and if you are on an older branch, start the migration to a fixed release now instead of after the August 10 deadline.

Then treat the upgrade as step one of two. Because this bug only bites where an attacker already had filesystem access, patching it does not answer the question that actually matters: were you one of the devices compromised during the 2023 to 2025 SSL-VPN campaigns? If a FortiGate was internet-facing and unpatched during that window, assume its configuration and stored secrets were read. Rotate everything the device held or trusted: local and administrative passwords, pre-shared keys, VPN and IPsec secrets, certificates, and any credentials that lived in the config. Pull the current configuration and compare it against a known-good copy for accounts, routes, or admin entries nobody added on purpose. Then remove any lingering symlink and other artifacts per Fortinet's guidance, and confirm on the fixed build that the language path no longer serves anything it should not.

How you would know

An appliance is a hard place to watch, because the box that would raise the alarm is the box the attacker is sitting on. Push the evidence off the device and watch it there. In the SSL-VPN web logs, the tell for this specific bypass is a request to the language directory carrying a doubled slash in the path, something a normal client never sends; a single rule that flags anomalous double-slash sequences in language-folder requests will surface attempts. More broadly, ship the firewall's logs somewhere the device itself cannot rewrite, alert on configuration changes and new administrative sessions, and flag outbound connections from the firewall to addresses you do not recognize.

Watch the estate around the firewall too, because a leaked config is a map. If your management network, VPN secrets, or internal credentials sat in a config an attacker could read, the next move is to use them on the servers behind the box. A central monitoring layer is what turns that into an alert instead of a surprise. A platform like Suriq, built on Wazuh, pulls logs and file-integrity events from the hosts it watches into one place and flags the unexpected: a config file that changed without a ticket, a credential reused where it should not appear, an administrative login at the wrong hour. It does not run on the FortiGate itself, but it watches the machines an attacker reaches next once a firewall's secrets are in hand.

The perimeter keeps being the soft way in

None of this is a Fortinet problem in isolation. The edge appliances sold to defend the network keep becoming the quietest way to persist inside it, because they hold the keys to everything behind them and they are hard to inspect from the outside. We have watched the same shape with Fortinet's own FortiBleed credential exposure and the backlog of unpatched edge devices that ransomware crews quietly mine. The lesson CVE-2025-68686 sharpens is narrower: patching the door an intruder walked through does not prove they left. On anything that faces the internet, assume a past compromise until you have looked, and build the looking into the routine.