FortiBleed: how the Fortinet credential leak exposed working firewall logins worldwide

When the lock is fine but the keys are copied

A firewall is the thing you buy to keep other people out. The uncomfortable part of FortiBleed is that the firewalls did their job, and it did not matter. In this campaign attackers did not smash through the FortiGate. They collected the keys. Starting from configuration files stolen through older Fortinet vulnerabilities, they cracked the passwords those files contained, assembled a searchable list of working logins, and validated many of them against live devices. Think of a locksmith whose master key list walked out the door. The lock on your front door is still fine. Someone else may already have a copy of your key, and the question that matters is not whether to change the lock but whether anyone has already used it. That is the FortiBleed problem in one line, and it changes how you should respond. Fortinet credential leak stories usually end with "apply the patch." This one does not, because patching a device whose credentials are already in a criminal database closes a door that is no longer the way in.

What happened

The campaign became public on 13 June 2026, when security researcher Volodymyr Diachenko reported an exposed server on the open internet hosting a growing database of login credentials for Fortinet devices. These were not random guesses. They had been validated against live systems, so the operators already knew which ones worked. Over the following days the scale became clearer. Fortinet's own analysis, published on 19 June, put the number of affected FortiGate devices at 86,644 across 194 countries, while independent researchers gave lower validated counts, from roughly 30,000 confirmed by SOCRadar to an estimate near 75,000. The figures differ because they measure different things, confirmed-working versus likely-exposed, and that gap is worth keeping in mind. On 18 June, CISA in the United States and the NCSC in the United Kingdom issued advisories urging Fortinet customers to act, and Fortinet published its PSIRT analysis a day later. The Netherlands is among the affected countries, and later reporting pointed to Dutch organisations being reached indirectly when the Fortinet credentials of their IT service providers turned up in the same dataset.

How the attack worked

FortiBleed is not one new zero-day. It is a chain of older problems assembled into a single operation. The starting point was configuration data stolen from internet-facing FortiGate devices through vulnerabilities Fortinet had already documented, tracked internally as FG-IR-26-060 and FG-IR-25-647. Those config files are valuable on their own: they hold local admin accounts, VPN user definitions, pre-shared keys, certificates, and a map of the network behind the firewall. Passwords in older FortiOS builds were stored with a legacy SHA-256 hash, and versions before 7.2.11, 7.4.8, and 7.6.1 kept that weaker format, which let attackers crack the hashes offline into plain credentials. On top of that they ran brute-force, dictionary, and credential-stuffing attempts against VPN portals, reusing passwords leaked in earlier breaches. According to Fortinet, the campaign involved "reusing credentials from previous incidents" combined with brute force against poorly protected accounts. Researchers who traced the infrastructure believe a Russian-speaking group is behind it, though that attribution is theirs, not a confirmed fact. The result is the dangerous part. A valid VPN credential is not an exploit that trips an alarm. It is a login. The attacker connects like an employee, from a normal client, and nothing about the session looks wrong unless you are watching for the account behaving strangely.

Who is affected

Any organisation running an internet-facing FortiGate firewall or FortiOS VPN on an affected version is potentially in scope, which is a large population. Fortinet is one of the most widely deployed firewall brands in the world, and the exposure spans 194 countries. Researchers noted the heaviest concentrations in telecom, government, and education, with large volumes in India, the United States, Mexico, Colombia, and Thailand. According to Arctic Wolf, the attackers maintained "databases of validated credentials organized by country, sector, and organization revenue," which tells you this was targeted harvesting, not opportunistic noise. For the Netherlands the practical worry is twofold. FortiGate is common across Dutch mid-market companies, municipalities, and government suppliers, so many organisations are directly exposed. And because Dutch IT service providers manage firewalls for their clients, a single provider's leaked credentials can reach every customer behind them, which is how organisations that never appeared in a scan can still be affected. Whether your specific device is in the dataset is something you can check: the researchers and several security vendors published exposure lookups keyed on device serial or public IP.

What this means for your organisation

The instinct with a credential leak is to reset passwords and move on. Here that instinct is half right and half dangerous.

Resetting is necessary, but it does not answer the question that matters. If your credentials were valid and validated, the window that counts is not the future, it is the past. Someone may have logged in already, days or weeks before you heard the name FortiBleed. A password reset closes the door going forward and tells you nothing about who walked through it yesterday. That is why this incident is a detection problem before it is a hardening problem.

So the order is deliberate. Check whether your devices appear in the exposure lists. Terminate every active VPN and admin session. Reset all local credentials, not just VPN users, because the stolen config files held admin accounts and service accounts too. Rotate pre-shared keys and certificates, since those were in the same files. Then review your logs going back to the config-theft window for VPN logins you cannot account for, new or changed admin accounts, and configuration changes you did not make. Only after that comes the hardening: upgrade to a FortiOS version that uses PBKDF2 hashing, disable internet-facing management interfaces, restrict admin access to trusted hosts, and enforce MFA on every VPN and admin login.

There is one more step that is easy to skip. If an attacker had valid access and personal data sat behind that firewall, you may be looking at a reportable data breach under the AVG, and that assessment depends entirely on the log review most organisations never do.

If you find your device in the exposure lists, or you see VPN logins you cannot explain, treat it as an active incident rather than a maintenance task. SecDesk's incident response team helps Dutch organisations establish whether leaked credentials were actually abused and contain the intrusion if they were. You can reach the responders at response.secdesk.com.