FortiBleed Cracks Open 80,000 Fortinet Firewalls And Thousands Used 123456

FortiBleed Fortinet credential leak. Attackers can log into more than 80,000 corporate firewalls right now, and on 2,645 of them the password was 123456. The username on those devices was admin3, the password was 123456, and it opened full administrative access to the firewall that stands between a company network and the open internet.

These are not stale guesses pulled from an old dump. They are verified working logins, tested by the attackers themselves with tools that run automatically around the clock. They cover devices in 194 countries, at banks, hospitals, telecom operators, universities, government agencies, and companies that pull in tens of billions a year.

The leak surfaced in mid-June 2026. A security researcher found a server the attackers had left exposed, and it held more than their stolen passwords. It held their tooling, their automation scripts, and a database of confirmed logins sorted by country, industry, company revenue, and headcount. Why would a thief sort stolen logins by how much money each company makes? Because a list like that is built to be sold. A buyer scrolls down and picks targets by size.

Fortinet itself was not hacked, and there is no new zero-day here. The firewalls did the one job they are built for, which is to let someone in who types the right password. The catch is what that password was. On many of these devices it was a factory default nobody ever changed, or a password that leaked in an older breach and never got swapped out.

The admin3 detail says more than it looks like at first. A fresh FortiGate ships with one administrator account, called admin. It does not ship with admin3. So admin3 is an extra account, added on top of the default one and handed the password 123456. What stands out is the repetition. The exact same admin3 with the exact same 123456 turned up on 2,645 separate devices. That does not look like 2,645 people each making the same poor choice. It looks like one weak default baked into a shared setup, a template or a deployment script that got rolled out across all of them. Either way, it is an admin account with full access and the worst password on the list, sitting on thousands of firewalls.

The break-in runs the same way from one device to the next. The attackers do not sit there guessing one password at a time. They built their list ahead of time, partly from passwords that already leaked in older Fortinet break-ins, and partly from infostealer malware, the kind that quietly lifts usernames and passwords off infected staff laptops. Then they throw that list at internet-facing FortiGate devices automatically, trying known passwords instead of guessing random ones. That trick has a name: credential stuffing.

They do not only target port 443, the standard port for Fortinet SSL VPN. They also try 4443, 8443, and 10443, so the odd setups that moved off the default do not slip past. Once a login works, they pull the device’s configuration file, and that file is what they are after.

Now the technical part.

A FortiGate keeps its settings in a configuration file, and that file holds the admin password in a hashed form. A hash is a scrambled version of the password that is meant to be hard to turn back into the original. For years Fortinet stored those admin hashes using SHA-256, which is fast to compute. Fast is good for logging in. Fast is also good for an attacker with a graphics card, because a modern GPU can run through an enormous number of guesses per second against a fast hash until it lands on the one that matches. So the moment a config file leaks, the admin password inside it can be recovered offline, on the attacker’s own hardware, with nobody watching.

A line in that config looks something like this:

1
2
3
4
5
6
7

config system admin
    edit "admin3"
        set accprofile "super_admin"
        set vdom "root"
        set password ENC SH2[hash removed]
    next
end

The SH2 at the start of that password line is the tell. It marks the value as a SHA-256 hash, and SHA-256 is the fast kind.

Fortinet did move to a stronger method called PBKDF2. It is built to be slow on purpose, so a graphics card cannot rip through billions of guesses against it. That change landed in FortiOS 7.2.11, 7.4.8, and 7.6.1.

There is a catch that traps the people who think they are already safe. When a device upgrades from an older version, the old SHA-256 hash stays put until that admin logs in again, and only then does it get rehashed. At that moment the prefix on the line flips from SH2 to PB2. Worse, Fortinet keeps the old SHA-256 hash in a hidden setting called old-password, just in case someone needs to roll back. An admin logged into the firewall never sees it. It only shows up in a full config backup pulled by a super_admin. So a config that looks like it moved to PBKDF2 can still be carrying the old, crackable hash underneath.

There is a second half to this that lets it grow on its own. Once the attackers are inside a FortiGate, the researchers who analyzed it say they use the device against its own network. They switch on the firewall’s built-in packet sniffer, a diagnostic tool meant for troubleshooting, and aim it at the traffic passing through the box. What it catches is the login traffic, the NTLM and Kerberos hashes from Active Directory sign-ins and the VPN logins moving across the device. Those hashes get cracked offline later and folded into the dataset. Each hacked firewall helps feed the next one. From there it largely runs on its own.

The operators did this at industrial scale. They scanned 59 million hosts, picked out around 437,000 FortiGate devices, and threw billions of login attempts at them. That narrowed down to more than 80,000 compromised devices and over 105 million harvested credentials, which a rig of ten RTX 4090 graphics cards then cracked into plaintext.

The researcher who found the server, Bob Diachenko, confirmed that some of these went further than exposed passwords. Attackers broke all the way into the networks of organizations in Japan, Taiwan, Vietnam, Iraq, and Turkey. They did not stop at the firewall. They held onto their access and moved from one machine to the next deeper inside.

The worst case was a defense contractor working with NATO, where they reportedly walked off with classified documents. The same server gave more away. It held ready-made scripts for grabbing files off internal file shares, signs that the attackers had wiped their own tracks from the logs, and login details for what looked like a defense industry VPN. That last part points to aims beyond money. A working login on the firewall is only step one, and on some of these networks the later steps have already happened.

A few things are still being argued over, and I will say them straight. Start with the numbers. How many devices? Somewhere between 75,000 and 86,000. It moves depending on whether you count each separate firewall or each separate login, so different teams land on different totals. The bigger open question is how the attackers got hold of the configuration files at this scale in the first place. SOCRadar leans toward reused passwords and quiet harvesting. Other researchers think the config files were pulled off the devices and the hashes cracked offline. Officially, the way in is still listed as unknown.

That unknown is less of a mystery than it first sounds. Over the past year Fortinet has patched a run of authentication-bypass flaws that handed attackers admin access, and the more recent ones were used to steal configuration files outright:

• → January 2025: CVE-2024-55591 let attackers skip the login and reach super-admin. Arctic Wolf watched them create backdoor admin accounts and reconfigure the devices
• → December 2025: CVE-2025-59718 and CVE-2025-59719 did it again through a crafted SSO message, admin access without a password, this time with firewall configurations exfiltrated
• → January 2026: CVE-2026-24858 worked even on firewalls that had already patched the December pair, with automated tooling creating accounts and copying out configs within seconds of getting in

The configs taken in those later campaigns carry the SH2 admin hash. Put the run together and FortiBleed starts to look like the cracking and selling layer on top of a string of config-theft campaigns, not a fresh mystery. That is a reading the evidence supports, not a confirmed link.

Working out who did it is the hardest part. That job has a name in security, attribution, and it is never clean. The researchers who found the server point toward a Russian-speaking group, based on their tools, the way they set up their servers, and a victim list stacked heavily with NATO countries. That is a reasonable read, but it is a read. IP addresses can be spoofed. Tools get shared and reused. Language inside code can be planted on purpose. What stands on solid ground is how the operation works, not the name of whoever runs it.

This is not the first time Fortinet hardware has been on the receiving end. In 2021 a forum dump exposed credentials for roughly half a million FortiGate VPN accounts. In January 2025 a group calling itself Belsen released full configurations for around 15,000 devices, data that traced back to a 2022 zero-day. FortiBleed is bigger than either of those, and researchers say the addresses in it do not overlap with the Belsen set, which means these are different devices and not the same victims showing up a second time.

Fortinet plays it down. The company says this is mostly old leaked data getting passed around again, plus some password-guessing, and nothing to do with a fresh hole in their own gear. The researchers watching live, working logins see something else, a campaign that is still running right now. Both can be partly true at once.

CISA and several national cyber agencies have all put out guidance this week, and they line up on the same steps. If your organization runs an internet-facing FortiGate or SSL VPN, treat it as exposed until you have checked, and work through this:

• → Reset all admin and SSL VPN passwords now, starting with the devices reachable from the internet
• → Turn on phishing-resistant MFA on each admin and remote-access account, so a stolen password on its own is not enough to get in
• → Take the management interface off the public internet and limit it to trusted internal networks
• → Upgrade FortiOS to 7.2.11, 7.4.8, 7.6.1 or later so admin passwords are stored with PBKDF2
• → After the upgrade, make each admin log in at least once, which is what triggers the rehash to PBKDF2
• → Clear out the leftover SHA-256 hash in the hidden old-password setting, following Fortinet’s own guidance
• → Read your logs for logins at odd hours, accounts you do not recognize such as forticloud-sync or forticloud-tech, and configuration changes you did not make
• → If your device shows up in the dataset, handle it as a confirmed break-in and bring in incident response, because changing the password does not undo what an attacker already did while they were logged in

Credential attacks, cracking stored password hashes, finding exposed services on the open internet, and the moves an attacker makes after a valid login such as persistence, lateral movement, and reading traffic as it passes through a device, are what my ethical hacking course walks through step by step:

• → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

SOCRadar | CISA | Arctic Wolf