If You Run a FortiGate Firewall, Read This Before You Do Anything Else
The Fortinet logins database leak isn’t a theoretical threat — it’s a real credential dump that put thousands of active firewall admin accounts directly in attackers’ hands.
In late 2024, a threat actor published what they claimed was a database of approximately 15,000 to 30,000 working Fortinet VPN and management credentials scraped from publicly exposed FortiGate devices worldwide. The credentials weren’t cracked. They weren’t guessed. They were pulled directly from vulnerable devices using a known path traversal vulnerability — CVE-2022-40684 — that Fortinet had patched in 2022 but that tens of thousands of organizations never applied.
Security researchers confirmed the data was real. Many of the credentials in the dump were still active at the time of publication.
That’s the nightmare scenario for any organization running Fortinet hardware: your firewall — the device you installed specifically to keep attackers out — is being used as the entry point. And the key to the front door is now sitting in a publicly shared database that every motivated attacker can download.
This guide explains exactly what happened, how to check if your organization is affected, and the concrete steps to take right now.
Table of Contents
The Scale of the Fortinet Logins Database Leak
The Fortinet logins database incident needs context to understand properly — because it isn’t a single breach of Fortinet’s own systems. It’s an aggregated collection of credentials harvested from individual organizations’ FortiGate devices that were left vulnerable to a known, patchable exploit.
The distinction matters. Fortinet the company didn’t get hacked. Individual organizations running unpatched FortiGate hardware got harvested — automatically, at scale, by attackers scanning the internet for vulnerable devices.
The timeline: Fortinet disclosed CVE-2022-40684, a critical authentication bypass vulnerability, in October 2022 and released a patch simultaneously. The vulnerability had a CVSS score of 9.8 out of 10 — as critical as vulnerabilities get. Attackers immediately began scanning for and exploiting unpatched devices. Two years later, thousands of organizations still hadn’t applied the patch.
⚠️ ALERT: CISA added CVE-2022-40684 to its Known Exploited Vulnerabilities (KEV) catalog and issued a binding operational directive requiring federal agencies to patch it within days of disclosure. The fact that tens of thousands of credentials still appeared in the 2024 leak confirms that a large percentage of organizations — including those in critical sectors — simply never applied the patch. Read CISA’s Known Exploited Vulnerabilities catalog (opens in new tab)
The Fortinet logins database circulated on hacking forums in late 2024, verified by multiple independent security researchers who confirmed that a significant portion of the credentials remained active. The organizations affected ranged from small businesses to government entities across the US, Europe, and Asia-Pacific.
What the Fortinet Logins Database Actually Contains
Understanding what was in the Fortinet logins database helps you understand the actual exposure level for affected organizations.
The leaked database contained:
- IP addresses of vulnerable FortiGate devices
- Plaintext usernames and passwords for VPN and management accounts
- SSL-VPN session data in some cases
- Device version information identifying which firmware each device was running
This is not a list of hashed passwords that require cracking. These are plaintext credentials — directly usable without any additional processing. An attacker with this database could attempt to log directly into the listed devices’ management interfaces or VPN portals using the stolen credentials, assuming the credentials hadn’t been changed since they were harvested.
FORTINET LOGINS DATABASE — WHAT ATTACKERS GET
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DATA TYPE │ WHAT IT ENABLES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Device IP address │ Directly target specific org's firewall
Plaintext password │ Immediate login attempt without cracking
Username │ No enumeration needed — account known
VPN session data │ Potential session hijacking
Firmware version │ Know exactly which exploits apply
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━🔴 WARNING: The Fortinet logins database leak is particularly dangerous because the credentials are plaintext and device IPs are included. An attacker doesn’t need specialized skills to attempt to use this data — they need the database and a browser. The window between when credentials are confirmed still active and when an organization discovers and rotates them is the attack window. For any organization in the leak, that window is potentially still open. Read NIST’s credential management guidelines (opens in new tab)
How the Credentials Were Stolen — The CVE Behind It
The Fortinet logins database wasn’t created through a sophisticated zero-day attack. It was created by mass exploitation of a vulnerability that Fortinet had already patched and publicly disclosed.
CVE-2022-40684: Authentication Bypass in FortiOS
This critical vulnerability affected FortiGate firewalls, FortiProxy web proxies, and FortiSwitch Manager running specific firmware versions. The vulnerability allowed an unauthenticated remote attacker to perform operations on the administrative interface by sending specially crafted HTTP or HTTPS requests — effectively bypassing authentication entirely.
What this means practically: an attacker who knew about this vulnerability could connect to a vulnerable device’s management interface from the internet and read configuration files, user credentials, and VPN session data without needing a username or password.
Automated Scanning Did the Work
Attackers didn’t manually identify and exploit vulnerable devices one by one. They ran automated scanning tools that searched the internet for FortiGate management interfaces exposed on known ports, tested each one for the vulnerability, and harvested credentials from every vulnerable device found. The process was largely automated and continuous — running across months after the vulnerability was disclosed.
The Two-Year Gap
The gap between Fortinet’s patch release (October 2022) and the credential database leak (late 2024) represents two full years during which affected organizations were running exploitable hardware, actively exposing credentials to any scanner that found them.
This is the real lesson of the Fortinet logins database incident: the vulnerability existed, the patch existed, and the window between “patch available” and “credentials stolen” closed the moment an attacker’s scanner reached your device.
How to Check If Your Fortinet Credentials Were Exposed
If your organization runs FortiGate hardware, here’s how to assess your exposure to the Fortinet logins database leak.
Step 1: Check Your Firmware Version
The vulnerability CVE-2022-40684 affected:
- FortiOS 7.2.0 through 7.2.1
- FortiOS 7.0.0 through 7.0.6
- FortiOS 6.4.x (certain builds)
- FortiProxy 7.2.0, 7.0.0 through 7.0.6
If your device was running any of these versions between October 2022 and when you patched it, your credentials may have been harvested before you patched.
Step 2: Check Whether Management Interface Was Internet-Exposed
The vulnerability required access to the administrative management interface. If your FortiGate’s management interface was accessible from the internet during the vulnerable window — which it should not be in a properly configured deployment — your device was directly scannable.
Step 3: Assume Compromise if Conditions Were Met
If your device ran a vulnerable firmware version AND the management interface was accessible externally during that period, treat your credentials as compromised regardless of whether you can confirm they appeared in the specific database. The scan was comprehensive and continuous.
Step 4: Check Security Research Disclosures
Security firms including Hudson Rock, Cybernews, and others published analysis of the leaked database and in some cases provided checking tools for affected organizations. Search for the most current researcher disclosures for verification tools.
If your organization needs freshly configured Fortinet hardware with current firmware and proper hardening from the start, browse our Fortinet firewall collection — all units ship with current firmware and can be configured with management interface properly restricted from the beginning.
Immediate Response: What to Do Right Now
If there’s any chance your organization is affected by the Fortinet logins database leak, these steps need to happen immediately — not this week, today.
1. Patch to Current Firmware Immediately
If you haven’t patched CVE-2022-40684, stop reading and do it now. The remediated versions are FortiOS 7.2.2 or later and FortiOS 7.0.7 or later. Every minute a vulnerable device stays unpatched is continued active exposure.
2. Rotate Every Credential on the Device
Change every administrator password on the FortiGate. Change every VPN user account password. Change every service account that touches the device. Assume every credential that existed on the device during the vulnerable window is in attacker hands.
3. Restrict Management Interface Access Immediately
The FortiGate management interface should never be accessible directly from the internet. If it is, restrict access to specific trusted IP addresses or disable it entirely from internet-facing interfaces immediately. This is the configuration gap that made mass harvesting possible.
4. Review Access Logs for Unauthorized Activity
Pull your FortiGate’s access logs for the period spanning the vulnerability window. Look for logins from unfamiliar IP addresses, configuration changes you didn’t make, VPN connections from unusual locations, or any activity outside your normal operational patterns.
5. Check for Persistence Mechanisms
Attackers who gained access through the Fortinet logins database may have established persistence through additional backdoor accounts, modified configurations, or installed additional access mechanisms. A security review of your current configuration against your known-good baseline is warranted.
6. Notify Relevant Parties
Depending on your industry, a confirmed credential compromise affecting your firewall may trigger regulatory notification requirements. Consult with your legal and compliance team if you operate in a regulated sector.
⚠️ ALERT: IBM Security’s X-Force threat intelligence team has documented cases where attackers who obtained credentials from the Fortinet logins database used them not for immediate ransomware deployment, but for quiet persistent access — establishing a foothold they could leverage weeks or months later. Credential rotation and log review must happen even if you see no immediate signs of active intrusion. Read IBM’s threat intelligence research (opens in new tab)
Why Unpatched Fortinet Devices Remain at Risk
The Fortinet logins database incident involved CVE-2022-40684, but it isn’t an isolated case. Fortinet vulnerabilities have been a consistent high-value target for attackers because FortiGate devices sit at the perimeter of organizational networks — compromise one and you gain a privileged position to observe, intercept, and attack everything behind it.
The Fortinet Vulnerability Pattern
Fortinet has disclosed and patched multiple critical vulnerabilities over recent years — CVE-2022-40684, CVE-2023-27997 (SSL-VPN heap overflow), CVE-2024-21762 (out-of-bounds write), and others. Each of these vulnerabilities received CISA warnings and in some cases binding directives for federal agencies. Each was exploited in the wild before organizations universally patched.
The pattern is consistent: critical vulnerability disclosed, patch released, attackers begin mass scanning within days, organizations with deferred patching get harvested over the following months.
Management Interface Exposure Is the Root Cause
The Fortinet logins database leak was specifically enabled by organizations exposing their management interfaces to the internet. This is a configuration error that creates vulnerability regardless of which specific CVE gets disclosed next. A properly configured FortiGate restricts management interface access to specific trusted internal IP addresses or a dedicated management VLAN — it is never accessible directly from the internet.
Deferred Patching Creates Multi-Year Windows
The two-year window between patch release and database publication in this incident is not unusual. Research consistently shows that a substantial percentage of organizations take months or years to apply critical patches to network perimeter devices. For a device as consequential as a firewall, that delay creates exactly the kind of extended vulnerability window that mass credential harvesting exploits.
Long-Term Hardening: Beyond the Immediate Patch
Responding to the Fortinet logins database leak correctly means more than patching CVE-2022-40684 and rotating credentials. It means fixing the configuration patterns that made the mass harvesting possible.
Restrict Management Interface to Internal Only
The single most important configuration change for any FortiGate deployment: the management interface must not be accessible from the internet. Restrict it to an internal management VLAN or specific trusted IP ranges. Use a jump host or VPN to reach it from outside if needed — never expose it directly.
Enable Two-Factor Authentication on All Admin Accounts
Even if credentials get compromised in a future incident, MFA on all administrator accounts means stolen passwords alone aren’t sufficient for login. FortiGate supports multiple MFA methods including FortiToken and RADIUS-based authentication.
Implement Least Privilege for All Accounts
Not every administrator needs full read-write access to every configuration area. Role-based access control on FortiGate allows you to limit what each account can do, reducing the blast radius if any single account gets compromised.
Set Up Automated Firmware Update Alerts
Configure alerting that notifies you immediately when Fortinet releases a new critical security advisory or firmware update. The Fortinet PSIRT (Product Security Incident Response Team) publishes advisories at fortiguard.com — subscribe to their notification list so you’re alerted within hours of a critical disclosure, not weeks.
Segment Management Traffic
Use a dedicated management VLAN that’s completely separate from your data traffic. This means that even if something on your data network gets compromised, it can’t pivot to reach your firewall’s management interface.
For organizations upgrading to current FortiGate hardware with proper initial configuration, browse our Fortinet collection — and read our VLAN segmentation guide to implement the management VLAN isolation that prevents management interface exposure from the start.
How to Protect Yourself: Step-by-Step
Concrete action plan for anyone running FortiGate hardware right now:
- Verify your current firmware version — Log into your FortiGate and check which FortiOS version you’re running. If you’re below 7.2.2 or 7.0.7, patching is your first action.
- Patch to current firmware immediately — Download and apply the latest stable FortiOS release. Don’t defer this for a maintenance window — do it now.
- Rotate all credentials on the device — Every admin account, every VPN user account, every service account. Change them all to strong, unique passwords.
- Restrict management interface access — Go to System → Admin → Administrator Settings and restrict the trusted hosts for each admin account to specific internal IP addresses. Disable internet access to the management interface entirely.
- Enable MFA on all admin accounts — Configure FortiToken, RADIUS, or LDAP-based multi-factor authentication for every account with management access.
- Review your access logs — Pull logs from the past 12-24 months and look for unusual admin logins, configuration changes, or VPN connections you can’t account for.
- Audit current configuration against baseline — Compare your current running configuration against your last known-good configuration to identify any unauthorized changes.
- Disable unused services — If you’re not using SSL-VPN, disable it. If you’re not using HTTPS management from WAN, disable it. Reduce the attack surface to only what you actually use.
- Subscribe to FortiGuard security advisories — Set up notifications at fortiguard.com so future critical disclosures reach you the same day they’re published.
- Consider a security assessment — If you have any doubt about whether your device was compromised during the vulnerable window, engage a security firm for a proper incident assessment before considering the matter resolved.
Quick Reference Checklist
FORTINET LOGINS DATABASE — RESPONSE CHECKLIST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IMMEDIATE (DO TODAY)
[ ] Firmware version verified — confirmed patched
[ ] CVE-2022-40684 patch applied if not already
[ ] All admin passwords rotated to strong unique values
[ ] All VPN user passwords rotated
[ ] Management interface WAN access disabled
[ ] Management interface restricted to trusted IPs only
ACCESS LOG REVIEW
[ ] Admin login logs reviewed (past 12 months)
[ ] VPN connection logs reviewed for anomalies
[ ] Configuration change logs reviewed
[ ] Unfamiliar IP addresses identified and investigated
[ ] Session logs checked for unauthorized activity
HARDENING (THIS WEEK)
[ ] MFA enabled on all administrator accounts
[ ] Role-based access control reviewed and tightened
[ ] Unused services (SSL-VPN if not used) disabled
[ ] Management VLAN segmented from data traffic
[ ] FortiGuard advisory subscription set up
ONGOING
[ ] Firmware update process documented
[ ] Critical patches SLA defined (72 hours for CVSS 9+)
[ ] Regular configuration audits scheduled
[ ] Incident response plan covers firewall compromise
[ ] Credential rotation policy implemented
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Frequently Asked Questions
Q: Was Fortinet itself hacked to create this database?
A: No. Fortinet’s own systems were not breached to create the Fortinet logins database. The credentials were harvested from individual organizations’ FortiGate devices that had been left vulnerable to CVE-2022-40684 — a critical authentication bypass vulnerability that Fortinet had patched in 2022. Attackers ran automated scans across the internet, found devices still running the vulnerable firmware, and extracted credentials directly from those devices. The problem is unpatched customer hardware, not a breach of Fortinet as a company.
Q: If I patched CVE-2022-40684, am I safe?
A: Patching prevents future exploitation of that specific vulnerability — but if your device was vulnerable and internet-exposed before you patched it, credentials harvested before the patch may still be in circulation. You need to both patch the firmware AND rotate all credentials that existed on the device during the vulnerable window. Patching without credential rotation leaves your device protected from the original exploit but potentially accessible through the stolen credentials.
Q: How do I know if my specific device was in the leaked database?
A: Several security researchers published analysis of the leaked database and some offered checking services for affected organizations. Search for the most current research from firms like Hudson Rock or Cybernews who analyzed the specific dump. However, the more conservative and practical approach is to treat credentials as potentially compromised if your device ran vulnerable firmware with an internet-exposed management interface during the window, regardless of whether you can confirm presence in the specific database.
Q: Should my FortiGate management interface ever be accessible from the internet?
A: No. This is one of the clearest configuration rules in enterprise networking — the management interface of any security appliance should never be directly accessible from the internet. Access it through a dedicated management VLAN, a jump host, or a VPN connection. The organizations whose credentials ended up in the Fortinet logins database overwhelmingly had this configuration error in common.
Q: Are other firewall brands vulnerable to similar credential harvesting attacks?
A: Yes — this is not unique to Fortinet. Credential harvesting from vulnerable perimeter devices has affected Cisco ASA/FTD, Pulse Secure/Ivanti, Citrix NetScaler, and others. The pattern is consistent: critical vulnerability disclosed, slow patching by organizations, mass exploitation during the gap. The defense is also consistent: patch critical perimeter device vulnerabilities within 72 hours of disclosure, restrict management interfaces to internal access only, and enable MFA on all administrative accounts.
Conclusion
The Fortinet logins database incident is a case study in what happens when the gap between “patch available” and “patch applied” stretches into months and years for critical network perimeter devices. The vulnerability was disclosed. The patch was released. CISA issued warnings. And tens of thousands of organizations still hadn’t patched two years later when the credential database hit public forums.
If you run FortiGate hardware, the response is concrete and immediate: patch, rotate credentials, restrict the management interface, and enable MFA. Don’t wait for confirmation that your specific device appeared in the database — if the conditions for exposure existed, treat it as confirmed and respond accordingly.
The deeper lesson: a firewall is only as secure as the patching and configuration discipline behind it. The best hardware in the world runs on firmware that needs maintenance, and credentials that need rotation when any exposure event occurs. If you’re considering upgrading to current FortiGate hardware with proper initial configuration, browse our Fortinet collection — and build the patching and hardening habits from day one that keep the next credential database from including your device.
Related Reading
- Why Small Businesses Close After a Cyberattack
- How Ransomware Actually Works and How to Never Pay the Ransom
- VLAN for Home Network 2026: Complete Setup Guide
- Router Settings You Must Change Right Now
- How to Protect Your Business From Ransomware Without Spending a Fortune
