On 17 June 2026, Volodymyr “Bob” Diachenko, owner of SecurityDiscovery.com and a cybersecurity researcher known for uncovering major data exposures, discovered an attacker-controlled server exposed to the internet containing verified administrator credentials for 73,932 FortiGate firewalls across 194 countries. The incident has since been dubbed FortiBleed.
The affected list includes the UAE, along with organisations operating in sectors such as telecommunications, financial services, government, healthcare, manufacturing, and logistics.
For organisations using FortiGate firewalls or Fortinet SSL VPNs, the discovery highlights the importance of reviewing administrative access and validating whether existing credentials and security controls remain secure.
What FortiBleed actually is
FortiBleed is not a single software vulnerability. There is no patch that fixes it. It is a large-scale, automated credential-harvesting campaign that has been running since at least March 2026 and was only disclosed publicly in mid-June.
The attackers built a self-sustaining operation: they scan the internet for Fortinet devices, test known credentials against them, and use any successful login as a listening post to harvest even more credentials from passing network traffic. Those new credentials go back into the scanner. The system feeds itself.
What the researchers found on the attacker’s server went beyond a simple password list. The dataset contains verified usernames, email addresses, and plaintext passwords, organised by country, industry sector, and company revenue. This is a precision targeting tool, not a commodity leak. Threat actors can query it and select targets by geography or industry before they launch an intrusion.
SOCRadar, which discovered the operational server independently, rates this campaign Critical.
The numbers
| Metric | Figure |
| Unique compromised FortiGate URLs | 73,932 |
| Countries affected | 194 |
| Organisations (unique domains) | ~21,600 |
| Verified working admin credentials | 30,791+ |
| Estimated total compromised devices | ~75,000 |
| Credential-stuffing attempts against FortiGate targets | 1.16 billion |
| Brute-force attempts against MSSQL servers (parallel campaign) | 2.1 billion |
To put the device count in context: researchers estimate the compromised devices represent roughly half of every FortiGate firewall currently reachable from the open internet.
How the attack was carried out
Understanding the attack chain matters, because it shapes what you need to fix.
Step 1: Configuration file extraction
The attacker harvested configuration files from internet-exposed FortiGate devices. Security researcher Kevin Beaumont noted that the dataset contains internal email addresses that only appear inside device configuration exports. This points to config-level extraction, well beyond scraping the login page.
How exactly the configs were obtained has not been definitively confirmed. The most likely explanation, based on researcher analysis, is a combination of known CVEs that went unpatched, credential reuse from earlier Fortinet breach datasets, and infostealer malware logs.
Step 2: Known CVEs, not a zero-day
Fortinet has confirmed there is no new, unknown vulnerability behind FortiBleed. Contrary to some early speculation, this is not a zero-day.
The primary CVE associated with the campaign is CVE-2026-24858, a FortiCloud SSO SAML authentication bypass with a CVSS score of 9.8. Fortinet disclosed it on 27 January 2026 and CISA added it to the Known Exploited Vulnerabilities catalogue. On any device where FortiCloud Single Sign-On was enabled, an attacker could authenticate without valid credentials, create a local admin account for persistence, and pull the configuration file.
Two additional CVEs are referenced in researcher reporting: CVE-2026-35616 and CVE-2026-25089 (a FortiSandbox OS command injection flaw). Both should be patched if your devices are in scope.
Step 3: Offline password hash cracking
This is the technical root cause that explains why so many credentials were recovered from config files.
Older versions of FortiOS stored administrator passwords using SHA-256, a fast cryptographic hash designed for data integrity checking, not password protection. A GPU cluster can test billions of SHA-256 candidates per second. The FortiBleed attackers ran a 45-GPU Hashtopolis cluster. At that throughput, typical enterprise passwords fall in minutes or hours, not months.
Fortinet fixed this. From FortiOS 7.2.11, 7.4.8, and 7.6.1 onwards, the platform uses PBKDF2-based hashing, which is deliberately slow and computationally expensive. Cracking a PBKDF2 hash with the same GPU cluster becomes orders of magnitude harder.
The problem: upgrading FortiOS to a version with PBKDF2 support does not automatically re-hash existing admin passwords. Each administrator must log in at least once after the upgrade before their stored hash converts. Until they do, the old SHA-256 hash persists in the config, including in a hidden old-password field that can survive even after the account appears to have been updated.
Step 4: Credential stuffing at scale
Alongside the hash-cracking operation, the attackers ran credential stuffing at industrial volume: 1.16 billion login attempts against 320,777 FortiGate targets. The credential lists are not random. They are compiled from earlier Fortinet breach datasets and infostealer malware logs, meaning many targeted organisations may have never rotated credentials after a previous incident.
SOCRadar found 2,645 Fortinet devices in the dataset using the username admin3 and the password 123456. The problem is not sophisticated attackers. The problem is basic credential hygiene that was never enforced.
Step 5: SSL VPN session interception
Once inside a FortiGate, the attackers used packet sniffing to intercept traffic flowing through the device. This gave them NTLM and Kerberos authentication hashes from Active Directory users passing through the VPN. Those hashes were then cracked offline and added to the dataset. A compromised FortiGate is a window into every Active Directory account in the environment, not just the perimeter device itself.
What the damage actually looks like
Appearing in the FortiBleed dataset means verified credentials associated with your device were exposed and validated by the attackers. It does not automatically mean your internal network has already been breached.
But the risk is real and immediate. Researcher Diachenko confirmed that at least four organisations were fully compromised through the campaign, including a Turkish NATO defence contractor from which classified documents were stolen. Enterprise organisations with revenue above $1 billion account for more than 20% of all entries in the dataset. The names confirmed in the data include Samsung, Oracle, Foxconn, Siemens, FedEx, Comcast, Chevron, Toyota, Mercedes-Benz, PwC, and Accenture.
Is this a Fortinet problem or a customer problem?
Both, in different ways.
Fortinet’s position is that FortiBleed represents recycled credentials from past incidents combined with brute-force activity, and that no new product vulnerability exists. That is technically defensible.
It does not help organisations whose credentials are sitting in the dataset right now. Whether those credentials were stolen last week or two years ago is irrelevant if they have not been changed. A device with unchanged passwords and a management interface exposed to the internet is an open door regardless of when the keys were first copied.
The SHA-256 password storage issue is a Fortinet design choice that remained in place for years. The patch is available. Most organisations never applied it.
What to do now
This is the remediation checklist. It draws on guidance from CISA, Arctic Wolf, SOCRadar, S-RM, and Fortinet’s own advisory. Work through it in order.
- Check whether you are in the dataset. Hudson Rock provides a free FortiBleed lookup tool. Run your public IP addresses and domains through it. A match should be treated as a confirmed compromise requiring immediate incident response, not a low-priority flag.
- Rotate every Fortinet credential today. Change all administrator passwords and all SSL VPN user accounts on every FortiGate device your organisation operates, including appliances that are not directly internet-facing. Assume every credential in a config file that has ever been exported is burned.
- Enforce MFA on all admin and VPN access. MFA makes a stolen password useless on its own. This is the single control that would have stopped most FortiBleed intrusions from progressing.
- Pull the management interface off the internet. FortiGate administration should never be reachable from a public IP address. Restrict access to trusted internal networks, a dedicated management VLAN, or a controlled jump path. This applies to the GUI, SSH, and any FortiCloud management interface.
- Upgrade FortiOS to a version with PBKDF2 support. The minimum versions are 7.2.11, 7.4.8, and 7.6.1. Running FortiOS 7.6.x or later is the cleanest path.
- Force credential re-hashing after upgrade. After upgrading, every administrator must log in at least once to trigger conversion of their stored hash from SHA-256 to PBKDF2. Until they do, the weak hash persists. On FortiOS 7.2.x and 7.4.x, enable the login-lockout-upon-weaker-encryption setting under the system password policy to force removal of residual SHA-256 hashes automatically.
- Patch CVE-2026-24858 and CVE-2026-25089. If FortiCloud SSO is enabled and the device is not patched against CVE-2026-24858, disable FortiCloud SSO immediately until the patch is applied. Review admin accounts for any local accounts you did not create, which is the primary persistence indicator for this CVE.
- Audit your logs. Review FortiGate admin logs, SSL VPN authentication logs, and Active Directory authentication logs for:
- Logins from unexpected geolocations
- Off-hours administrative sessions.
- Local administrator accounts that should not exist
- Lateral movement patterns following VPN authentication
- Treat Active Directory as potentially compromised.
If your FortiGate was a working SSL VPN endpoint and credentials may have been exposed, reset Active Directory user passwords broadly. The packet-sniffing stage of this campaign specifically harvested NTLM and Kerberos hashes from VPN traffic.
What this means for UAE organisations specifically
FortiGate is one of the most widely deployed firewall and VPN platforms across the UAE. It sits at the perimeter of banks, government entities, hospitals, telecoms operators, logistics providers, and manufacturers.
The combination of wide deployment and historically weak patching rates makes the UAE an attractive target. The FortiBleed dataset is searchable by country. Threat actors looking specifically for UAE targets can filter the list and get a ready-made hit list.
UAE organisations subject to NESA ISR, DESC information security regulations, or the UAE Personal Data Protection Law also face regulatory exposure if a breach results from known vulnerabilities or inadequate credential management. Containment carries compliance implications here too.
How iConnect can help
Our managed SOC operates 24/7 from Dubai and monitors FortiGate environments for exactly this class of threat: credential-based intrusions, unexpected admin sessions, anomalous VPN authentication, and lateral movement following perimeter compromise.
If your organisation runs FortiGate and you are not sure whether you are in the FortiBleed dataset, or you need help working through the remediation checklist with your specific configuration, get in touch with our team. We will review your exposure, walk through the log indicators, and help you close the gaps before an attacker uses what is already in the dataset.
The credentials are out there. The question now is how fast you move.
About the Author: Ammar Sheikh
Ammar Sheikh is a Cybersecurity Solutions Architect at iConnect IT Business Solutions, with deep hands-on experience designing and deploying enterprise security infrastructure across the UAE. His work spans next-generation firewalls, SASE, ZTNA, privileged access management, EDR, and SIEM, across complex multi-client environments and some of the region’s most security-conscious organisations.
