Executive briefing
What happened:
An invisible, persistent backdoor has been discovered in more than 16,000 Fortinet firewalls. This was not a new vulnerability – it was a case of attackers exploiting a subtle part of the system (the language component) to maintain unauthorized access even after the original vulnerabilities were patched.
What does this mean:
Devices that were deemed “safe” may still be at risk. Attackers had read-only access to sensitive system files via symbolic links placed on the file system – completely bypassing traditional authentication and detection. Even if the device was patched months ago, the attacker may still be in place.
Business risk:
- Exposure of sensitive configuration files (including VPN, admin and user data)
- Reputational risk when customer-facing infrastructure is compromised
- Compliance issues depending on the industry (HIPAA, PCI, etc.)
- Loss of control over device configuration and trust boundaries
What we do with it:
We have implemented a targeted remediation plan that includes firmware fixes, credential resets, file system audits, and access control updates. We’ve also incorporated long-term controls to track persistence tactics like this in the future.
Key information for management:
It’s not about one vendor or one CVE. This is a reminder that patching is only one step in the secure operations model. We’re updating our process to include continuous threat detection on all network devices—because attackers aren’t waiting for the next CVE to hit.
What happened
Attackers exploited Fortinet firewalls by placing symbolic links in language file folders. These links pointed to sensitive files at the root level, which were then accessible via the SSL-VPN web interface.
Result: attackers gained read-only access to system data without credentials and without warning. This backdoor remained even after firmware fixes – unless you knew to remove it.
FortiOS versions that remove the backdoor:
- 7.6.2
- 7.4.7
- 7.2.11
- 7.0.17
- 6.4.16
If you’re running something older, assume a compromise and act accordingly.
A real lesson
We tend to think of patching as a complete reset. it isn’t. Today’s attackers are persistent. They don’t just get in and move to the side – they quietly burrow in and stay.
The real problem here was not a technical glitch. It was a blind spot in operational trust: the assumption that once we patch, we’re done. This assumption is no longer safe.
Operations resolution plan: One-click runbook
Handbook: Fortinet Symlink Backdoor Remediation
Purpose:
Fix a symbolic link backdoor vulnerability affecting FortiGate devices. This includes remediation, auditing, credential hygiene, and confirming the removal of any persistent unauthorized access.
1. The scope of your environment
- Identify all Fortinet devices in use (physical or virtual).
- Inventory of all firmware versions.
- Check which devices have SSL-VPN enabled.
2. Firmware patch
Fix to the following minimum versions:
- FortiOS 7.6.2
- FortiOS 7.4.7
- FortiOS 7.2.11
- FortiOS 7.0.17
- FortiOS 6.4.16
steps:
- Download the firmware from the Fortinet support portal.
- Schedule a downtime or continuous upgrade window.
- Back up your configuration before applying updates.
- Use the firmware update via GUI or CLI.
3. Verification after repair
After update:
- Confirm the version with get system status.
- Verify that SSL-VPN is functional if used.
- Run the flash sys diagnostic list and confirm the removal of unauthorized symlinks (the Fortinet script included in the new firmware should automatically clean it up).
4. Credential and session hygiene
- Force password reset for all admin accounts.
- Revoke and reissue all local user credentials stored on the FortiGate.
- Cancel all current VPN sessions.
5. System and configuration audit
- Check the list of administrator accounts for unknown users.
- Verify current configuration files (view full configuration) for unexpected changes.
- Search the filesystem for remaining symlinks (optional):
find / -type l -ls | grep -v "/usr"
6. Monitoring and Detection
- Enable full logging on SSL-VPN and admin interfaces.
- Export logs for analysis and retention.
- Integrate with SIEM and alert on:
- Unusual admin login
- Access to unusual web resources
- VPN access outside expected geographic areas
7. Harden the SSL-VPN
- Limit external exposure (use IP whitelisting or geo-fencing).
- Require MFA for all VPN access.
- Disable web mode access unless absolutely necessary.
- Disable unused web components (eg themes, language packs).
Change control overview
Type of change: Security hotfix
Affected systems: FortiGate devices running on SSL-VPN
Impact: Short interruption during firmware update
Risk level: Medium
Change owner: (Insert name/contact)
Change window: (Insert time)
Backup plan: See below
Test plan: Confirm firmware version, verify VPN access, and run post-patch audits
Return plan
If the upgrade fails:
- Reboot to previous firmware partition using console access.
- Run: exec set-next-reboot primary or secondary depending on which was upgraded.
- Restore the backed up configuration (pre-patch).
- Temporarily disable SSL-VPN to prevent contact while investigating the issue.
- Notify infosec and escalate through Fortinet support.
A final thought
This was not a missed patch. It was a mistake to assume that the attackers would play fair.
If you’re just checking to see if something is “vulnerable” you’re missing the bigger picture. You have to ask: Could someone already be here?
Security today means reducing the space in which attackers can operate—and that’s assuming they’re smart enough to use the edges of your system against you.
The post When Patching Is Not Enough appeared first on Gigaom.