FortiBleed: 73,000 Fortinet Firewalls Leaked Credentials — What Maldives Organisations Must Do Now

What happened

On 17 June 2026, security researcher Volodymyr "Bob" Diachenko of SecurityDiscovery.com disclosed that he had found an attacker-controlled server left open to the internet, hosting tooling, scripts, cron jobs, bash histories, logs, and the results of a large-scale credential harvesting campaign targeting Fortinet FortiGate firewalls worldwide. Kevin Beaumont independently verified that the credentials were authentic and that almost all of the affected devices were still online at the time of disclosure. Hudson Rock published a detailed analysis alongside a FortiBleed lookup tool so organisations could check their own exposure.

The exposed data includes plaintext usernames, email addresses, admin and VPN passwords, and per-organisation metadata covering industry classification, revenue, and employee count. A Turkish NATO defence contractor reportedly had classified documents exfiltrated, though that specific claim carries medium confidence at time of writing.

Industries represented in the confirmed-compromise dataset span telecoms, IT services, financial services, government, healthcare, education, manufacturing, and critical infrastructure. The highest concentrations are in India and the United States, with significant presence across Taiwan, Mexico, Turkey, Thailand, Colombia, Malaysia, Chile, and the UAE.

How the attackers pulled it off

The operation ran in four phases, and the technical execution is worth understanding in detail, because one of the decisions Fortinet made in its hashing upgrade creates a trap that affects organisations that believe they have already addressed this.

Phase 1 — Mass scanning. Attackers performed internet-wide scans targeting FortiGate devices with management interfaces or SSL-VPN portals exposed to the public internet. Shodan data suggests roughly 50% of internet-facing Fortinet firewalls were included in the scan corpus.

Phase 2 — Config extraction. From accessible devices, attackers extracted configuration files containing credential material.

Phase 3 — Offline cracking. Here is where the infrastructure investment becomes clear. The attackers ran a 45-GPU cracking cluster managed through Hashtopolis, a distributed hash cracking framework. The cluster was self-learning, reusing previously cracked passwords to accelerate future jobs. FortiOS has historically stored admin and VPN credentials as salted SHA-256 hashes. SHA-256 is fast to compute, which makes it poor for credential storage: a modern GPU cluster can attempt billions of SHA-256 hashes per second. The attackers exploited exactly this weakness.

Fortinet recognised this problem and introduced PBKDF2 hashing, a deliberately slow key-derivation function that makes brute-force cracking impractical, in FortiOS 7.2.11, 7.4.8, and 7.6.1. But the upgrade path contains a critical catch, which the next section covers.

Phase 4 — Validation and lateral movement. The cracked credentials were validated against live devices to confirm which ones still worked. Valid credentials were then used for lateral movement into connected Active Directory environments.

Why "we're already patched" may not save you

This is the detail that makes FortiBleed more dangerous than a straightforward patch-and-move-on scenario.

Fortinet's PBKDF2 fix is real and it works. But upgrading FortiOS to a version that includes it does not automatically re-hash existing admin passwords. The migration only happens when an admin actively logs in after the upgrade. Until that login occurs, the stored password hash for that admin account remains SHA-256, and is just as crackable as it was before the upgrade.

In practice, this means an organisation can be running FortiOS 7.4.8 and still have admin accounts with SHA-256 hashes for any administrator who has not logged in since the upgrade. If those hashes were captured before or during the upgrade window, they are crackable regardless of the current FortiOS version.

For FortiOS 7.2.x and 7.4.x, Fortinet recommends enabling login lockout on weaker encryption as a compensating control. But the right response is not to wait for the control to trigger. It is to force every admin to re-authenticate post-upgrade, and to rotate all credentials as a precaution now. "We're on a patched version" and "we're safe" are not the same sentence here.

Is it being exploited?

Yes. The credentials came from live attacker infrastructure, not a historical data dump. Beaumont confirmed that almost all affected devices remained online and internet-exposed at the time of disclosure. This is not a case where the window of exploitation is theoretical or future-tense.

Fortinet disputes the framing, characterising the dataset as "reshared information from previous incidents" combined with brute-forcing rather than a novel vulnerability. That position deserves a fair hearing. Fortinet is technically correct that FortiBleed has no assigned CVE and does not rely on a single undisclosed exploit. At the time of publication, Fortinet had not issued a formal security advisory, pointing instead to the PBKDF2 upgrade path and post-upgrade password re-hashing guidance.

The dispute is about causation, not about the credentials. Whether the data originated from prior incidents or from fresh extraction, 30,000 devices have confirmed working credentials in the hands of a Russian-speaking multi-operator criminal group. That fact is not in dispute.

Separately, and worth tracking on its own, CVE-2026-24858 is a FortiCloud SSO SAML authentication bypass (CWE-288, CVSS 9.4) disclosed and added to the CISA Known Exploited Vulnerabilities catalogue on 27 January 2026. Active exploitation of this CVE is creating rogue local administrator accounts on patched devices. FortiBleed and CVE-2026-24858 are distinct issues, but they share attack surface: an adversary holding working admin credentials and a SAML bypass is in a far stronger position than one holding either alone.

What to do right now

1. Rotate all admin, VPN, and service-account credentials immediately. Assume exposure. Do not wait for confirmation that your specific devices appear in a lookup tool.
2. Enforce MFA on all VPN and admin access. A cracked password against an MFA-protected account is much harder to weaponise.
3. Remove management and admin portals from the public internet. Use IP allowlists or require VPN-only access to reach the management interface. There is no operational justification for leaving a firewall's admin portal internet-reachable.
4. Force PBKDF2 re-hashing. Update FortiOS to 7.2.11, 7.4.8, or 7.6.1 or later, then require every administrator to log in post-upgrade so their passwords migrate off SHA-256. On 7.2.x and 7.4.x, also enable login lockout upon weaker encryption.
5. Conduct a retrospective log review. Check VPN and gateway logs for unauthorised access patterns and look for rogue local admin accounts, particularly relevant given CVE-2026-24858 activity.
6. Patch known Fortinet CVEs and disable unused services. CVE-2026-24858 is actively exploited and CISA KEV-listed. If you are not patched, stop reading and patch first.

What this means for Maldives organisations

FortiGate is one of the most common edge firewall and SSL-VPN platforms across the Maldives. Resorts, banks, government agencies, ISPs, and SMEs all use it. The devices sitting at the perimeter of your network, handling VPN access for staff, protecting internal infrastructure, and sometimes managing guest Wi-Fi separation at properties, are exactly the class of device this campaign targeted.

Two factors compound the local risk. First, many Maldives-based FortiGate deployments are managed by overseas managed service providers or by IT staff who do not have dedicated security oversight. Default-internet-exposed management interfaces are common in these configurations, and the post-upgrade re-hash requirement described above is the kind of nuance that gets missed when there is no full-time security engineer watching the estate. Second, the data exposed here is not just passwords. It includes organisation metadata, so an attacker with confirmed credentials plus industry classification and employee count already has a head start on targeted follow-on attacks.

The regulatory picture adds urgency. The Maldives Data Protection Act 2021 creates obligations around personal data exposure, and admin credentials, VPN user accounts, and email addresses extracted from your systems qualify as personal data under that framework. Financial institutions operating under Maldives Monetary Authority IT Risk Management Guidelines have explicit requirements around access control and credential management that a confirmed FortiBleed exposure would place directly in scope. Tourism operators and any entity handling card payments are subject to PCI-DSS requirements covering network segmentation and access control.

"We're patched" is not a sufficient answer to give your compliance team, your board, or the MMA. The specific re-hash trap means patching status and credential exposure status are two different questions, and both require a direct answer.

If your FortiGate or VPN edge is managed by someone else, now is the time to ask them directly: has every admin account been re-authenticated post-upgrade? Are the management interfaces off the public internet? Have VPN credentials been rotated? These are not unreasonable questions. They are the baseline.

An independent penetration test and edge security assessment confirms your actual exposure posture, not just your theoretical patch status. CyberCloud works with Maldives organisations to check whether FortiGate and VPN infrastructure is exposed, rotate and harden credentials, and document the outcome in a format that satisfies regulatory and board reporting. Start with a risk assessment if you need to prioritise where to begin, or get in touch directly. This is not the kind of finding that warrants a scheduled review cycle.

References

1. FortiBleed Leak Exposes Fortinet VPN Credentials for 73,000 Devices — BleepingComputer, June 2026
2. Fortinet FortiBleed Data Leak — Help Net Security, June 2026
3. FortiBleed Campaign Exposes 75,000 Fortinet Firewalls Worldwide — CSO Online, June 2026
4. Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries — Arctic Wolf, June 2026
5. Fortinet FortiBleed: Global Compromise and Active Exploitation of Fortinet Vulnerabilities — Kudelski Security, June 2026
6. Fortinet Releases Guidance: Authentication Bypass Vulnerability CVE-2026-24858 — CISA, January 2026