FortiBleed: FortiGate Credential Leak - What UAE Companies Must Do Now

FortiBleed is the name given to a mass credential-exposure campaign against Fortinet FortiGate firewalls, and if your organisation runs FortiGate on the UAE perimeter - which a large share of local enterprises and government entities do - you need to treat it as an active incident, not a headline. Security researcher Volodymyr “Bob” Diachenko first surfaced the dataset on 13 June 2026, and CISA issued a hardening alert on 18 June 2026. This post is not a blow-by-blow of the campaign. It is what UAE security leads should do this week.

What actually happened

The FortiBleed dataset contains valid administrative and SSL VPN credentials for roughly 73,932 unique FortiGate firewall URLs, spanning 194 countries and more than 21,000 domains. Researchers estimate this represents about half of all internet-reachable FortiGate devices - one of the largest firewall-credential exposures on record. Named organisations in the dataset reportedly include large enterprises, critical infrastructure operators, and government agencies.

Here is the part that matters for your remediation: this was not a single remote-code-execution CVE. A Russian-speaking threat group ran roughly 1.16 billion credential attempts against more than 320,000 FortiGate targets, pulled configuration files from internet-facing devices, and cracked the stored password hashes offline on GPU infrastructure. The underlying weakness is in FortiOS credential management. When a device is upgraded from an older version, administrator passwords stay stored as weak SHA-256 hashes - which crack fast - until an admin manually logs in after the upgrade to trigger migration to the stronger PBKDF2 format.

Fortinet introduced PBKDF2 password hashing in FortiOS 7.2.11, 7.4.8, and 7.6.1. But per Fortinet’s own PSIRT analysis, the old SHA-256 hash is retained in a hidden old-password setting for backward compatibility, invisible to a normal admin session but visible in a config backup taken by a super_admin. So a device you consider “fully patched” can still be sitting in the leaked dataset with a crackable hash. Patching without logging in and rotating does not save you.

Why this matters for UAE organisations specifically

Fortinet is the dominant perimeter firewall vendor across UAE banking, government, healthcare, oil and gas, and mid-market enterprise. That concentration means FortiBleed is not a distant international story - it is a local exposure problem. A stolen FortiGate admin credential is a keys-to-the-kingdom event: it gives an attacker management of the firewall itself, visibility into the internal network topology, the ability to open SSL VPN tunnels, and a launch point for lateral movement into everything the perimeter was protecting.

The regulatory implications in the UAE are real and immediate:

• NESA / NCA IAS - the Information Assurance Standards cover perimeter and network security controls. A firewall compromise affecting critical information infrastructure triggers incident reporting expectations.
• CBUAE Information Security - banks and payment institutions must report cyber incidents affecting customer-facing systems. A compromised perimeter firewall routinely qualifies.
• DFSA and VARA - DIFC-licensed firms and regulated VASPs have supervisory notification duties for significant cyber incidents.
• UAE PDPL - if the compromise enabled access to personal data behind the firewall, Data Office notification obligations apply, typically within 72 hours of discovery.

The 6-step FortiBleed response checklist

Not theoretical. Specific actions your team can run this week, in order.

1. Rotate every credential (do this first)

The attackers already hold working credentials, so rotation is what actually locks them out. Following CISA’s guidance: reset all local FortiGate administrator passwords, all SSL VPN user passwords, and any RADIUS or LDAP bind accounts referenced in the config. Do not forget service and shared accounts that appear in a config backup. If you only do one thing, do this - and do it before you announce anything internally, so an attacker who is watching does not get a warning window.

2. Audit the configuration for the weak hash

Take a config backup as super_admin and inspect for the hidden old-password SHA-256 setting on admin accounts. Its presence means a crackable hash existed on that device. While you are in the config, review admin accounts for unauthorised additions, unexpected trusted hosts, altered admin profiles, new local users, and any config changes you cannot account for. Rebuild trust in the config, do not assume it.

3. Review and terminate VPN and admin sessions

Terminate all active SSL VPN and administrative sessions, per CISA. Then pull SSL VPN authentication logs and look for logins from unfamiliar geographies, impossible-travel patterns, off-hours access, and successful authentications you cannot tie to a real user. A valid credential produces a clean-looking login, so you are hunting for context anomalies, not failed attempts.

4. Hunt for indicators of compromise

Assume the credential may already have been used. Look for new or modified admin accounts, changed firewall or routing rules, new VPN tunnels or portal mappings, disabled logging, altered DNS or DHCP settings, and outbound connections from management interfaces. Cross-reference against the IOCs published by Arctic Wolf and Bitsight. Extend the hunt to internal systems the firewall protects - a perimeter breach is a starting point, not an endpoint.

5. Patch and force re-hashing

Upgrade affected devices to FortiOS 7.2.11, 7.4.8, 7.6.1 or later, then log in as each admin after the upgrade to trigger migration to PBKDF2 hashing. Patching without that login leaves the weak SHA-256 hash in place. While you are at it, get management interfaces off the public internet entirely, enforce MFA on admin and SSL VPN access, and restrict admin access to trusted hosts.

6. Validate externally

Once you have rotated, patched, and hunted, confirm you actually closed the door. Check your domain and public IP ranges against a FortiBleed exposure checker (SOCRadar publishes a free one), then validate the perimeter with an independent external test rather than trusting your own config review. A network penetration test confirms whether your firewall, VPN, and management surfaces are genuinely hardened, and produces the documented evidence UAE regulators expect after a reportable event.

How to check your exposure

Two layers. First, the fast signal: enter your organisation’s domains and public IPs into a FortiBleed checker to see whether records tied to you appear in the leaked dataset. Treat a hit as confirmation to act, but treat a miss as inconclusive - the dataset is a snapshot, and any internet-exposed FortiGate on a pre-7.2.11 / 7.4.8 / 7.6.1 build should be assumed in scope regardless. Second, the ground truth: enumerate every FortiGate you own, check each one’s FortiOS version and config for the old-password hash, and reconcile against your asset inventory. Shadow firewalls in branch offices and acquired business units are exactly where this bites.

Document it, because you will be asked

Even if you find no evidence of active compromise, record what you checked, when, by whom, and the outcome. File it in your security programme as due-diligence evidence. If a UAE regulator asks whether you responded to FortiBleed - and for CBUAE, NESA, DFSA, and VARA entities that is a realistic question - a dated remediation record is the difference between a routine answer and a supervisory problem. Update your incident playbooks with what the exercise taught you about your own FortiGate footprint.

Scanners find the exposure - a pentest confirms the fix

Automated exposure checkers and vulnerability scanners are great at telling you a FortiGate credential leak touched your perimeter. They are much weaker at answering the question that actually matters after remediation: is the door really shut, or did rotation miss a service account, a forgotten branch firewall, or a VPN tunnel an attacker already established? Scanners find roughly the first 40 percent - the known exposure. A skilled tester finds the rest: the misconfiguration your config review skipped, the trust relationship the stolen credential could still abuse, the lateral path from the firewall into everything behind it.

If you run FortiGate on the UAE perimeter, treat FortiBleed as the forcing function to validate your whole external posture, not just this one device. Start with a network penetration test to confirm your firewall and VPN are genuinely hardened, then talk to us about scoping an external validation that produces the documented evidence your regulator will want to see.

Related resources

• Network Penetration Testing UAE - external and internal perimeter validation
• Vulnerability Assessment Services UAE - rapid external attack surface scan
• Security Testing Services UAE - coordinated multi-layer testing programme
• NESA Penetration Testing Guide - UAE federal framework incident reporting context
• CBUAE Penetration Testing Guide - banking incident expectations