Keep three results separate. A leftover SHA-256 hash answers whether each guess stays cheap once the material has been copied off the device. A reused password answers whether any guess is required at all. Being locked out of the firewall means someone changed or removed the original account after they got in. The storage algorithm does not bolt the door by itself. After you move to a FortiOS release that supports PBKDF2, the current password field switches to the new scheme when that administrator logs in successfully, or when a super_admin resets the password. The previous SHA-256 value stays in a hidden field by default, which is what keeps a later downgrade possible.
Answer the search intent in one sentence
People searching for FortiBleed, a firewall administrator locked out, or “SHA-256 stored the password” are looking at three events that the same news item stacks together. First, attackers take passwords from earlier leaks or infostealer logs and try them directly against FortiGate SSL VPN portals that are still on the public internet. Second, if the device still holds what the vendor calls a legacy SHA-256 administrator password, a copied hash can be guessed offline on a GPU cluster. Third, once they are in, they create accounts and change or delete the original administrator, so the legitimate person cannot open the portal.
This note is for operators who still own firewall or VPN accounts, and for the colleague who was told to reset every administrator password tonight. It stays separate from the password generator page, and Password Audit stays a local check: it does not look up whether this device appears in FortiBleed. Take away which failure a fast hash, a slow key derivation, password reuse, and a deleted account each stop, and which two markers in a configuration backup you can check on a machine you already administer.
What the 6 October advisory actually says
The FBI and U.S. Secret Service joint advisory of 6 October 2026 (JCSA-20261006-01, marked TLP:CLEAR) names the operation FortiBleed. The targets are internet-facing Fortinet FortiGate firewalls and SSL VPN gateways. The advisory cites a SOCRadar figure: more than 86,644 devices across 194 countries. It says the campaign uses reused or leaked credentials and legacy SHA-256 password storage, so authentication material can be taken in bulk and cracked. Initial findings say attackers are still scanning internet-exposed Fortinet firewalls with credentials they already hold.
The same document describes how the operators’ own backend directory was exposed, which is how the toolchain became visible. After a scan finds a FortiGate SSL VPN portal, earlier Fortinet leak dumps and infostealer logs feed credential stuffing and password spraying. Stolen password hashes go to a GPU cluster scheduled with Hashcat and Hashtopolis for offline cracking. Cracked results are filtered, checked, and then used to create new administrator accounts on the firewall. The advisory describes later impact as initial access that is resold, and says this chain has been observed handed to ransomware affiliates, naming INC/Lynx and Payload. Treat those sentences as the advisory’s account. This page did not run a separate investigation.
The section that collides with “just change the password” is the lockout note. Based on early response, if the other party deletes the original account or changes its password, the organization finds it cannot sign in to the Fortinet device. During the intrusion they create accounts that were not on the device before. In some cases, deleting existing accounts is how they block the organization’s own access while they keep moving inside the environment. The advisory therefore says remediation can go beyond ordinary patching and password resets. It maps that step to MITRE ATT&CK T1531 (Account Access Removal).
This article does not provide hash extraction, wordlists, or cracking commands, and it does not copy the advisory’s address list or account-name list. Those lists are for defenders who are already reviewing their own logs. The checks below use a device you are authorized to administer, plus the vendor’s public documentation. Do not download an untrusted open directory “to verify the news,” and do not paste a configuration backup that contains password hashes into a ticket or a chat window.
Reused passwords and offline cracking are different paths
A headline tends to collapse the story into “the password was weak.” The advisory contains at least two paths that fail under different conditions. Credential stuffing and password spraying happen at an online login. The other party submits plaintext they already know, or a short list they are trying. The algorithm the device uses to store passwords affects how the device compares the submission. It does not change the characters already in the attacker’s hands. If that string matches a VPN or administrator account that is still valid, the login succeeds.
Offline cracking starts after the hash has already been copied away. The other party stops knocking on your portal. On their own machines they enumerate guesses, turn each guess into a hash, and compare it with the copied material. The cost of that step depends on how much work the storage scheme demands per guess, and on how large the password’s search space is. SHA-256 is a fast hash designed for integrity: the same input always produces the same output, and one computation finishes the job. It is a fit for checking a file. It is a poor fit, by itself, for making each password guess visibly expensive. A rented GPU cluster runs that one-pass operation in parallel. Hashtopolis, in the advisory, distributes cracking jobs across machines. The cipher stays whatever the device stored. Hashtopolis only spreads the work.
| Path | What they already hold | After storage moves to PBKDF2 |
|---|---|---|
| Credential stuffing / password spraying | Plaintext, or a short list of common passwords | Known plaintext still logs in. A slow derivation does not stop a password they already have. |
| Offline cracking | A password hash copied off the device | Each guess costs more. Short passwords and reused passwords can still be guessed. |
| Lockout | An administrative session that has already logged in | Changing the algorithm does not stop them from changing or deleting the original account. |
The third row blocks a common over-read: writing “we switched to a slower hash” as if that meant “administrators can no longer be shut out.” Lockout happens after authentication has already succeeded. It depends on the other party being able to change the configuration. It does not depend on how fast SHA-256 runs. Resetting passwords while the public management plane stays open, and without phishing-resistant multi-factor authentication, covers only part of that list. The FBI and the Secret Service put tighter management access, ending current admin and VPN sessions, resetting passwords, enabling phishing-resistant MFA, checking for unknown accounts, and confirming PBKDF2 in the same set of mitigations. The advisory also asks defenders to review REST API keys, remove keys they do not recognize, and rotate the legitimate ones, because a key can keep automated access after a password change.
What SHA-256 and PBKDF2 each prove
The OWASP Password Storage Cheat Sheet pulls password storage out of “compute one fast hash.” It asks for a slow key derivation with a unique salt, such as Argon2id, bcrypt, scrypt, or PBKDF2 with enough iterations. A salt stops a precomputed table from moving from one person to the next. Iteration count, or a memory-hard parameter, makes every guess repeat a large amount of work. Those two answers are different questions. A unique salt on a single SHA-256 still defeats a rainbow table, and a GPU can still exhaust a short password cheaply. A slow function that shares one salt across everyone still lets one table cover a large set of hashes. The advisory does not describe Fortinet’s older scheme as “completely unsalted.” This article does not fill that gap. The sentence that can be written is the comparison the vendor later published itself.
Fortinet’s technical tip on administrator password hashes says that from FortiOS 7.2.11, 7.4.8, and 7.6.1, the hash used in the configuration to store firewall administrator credentials changes from SHA256 to PBKDF2. The tip uses SH2 for SHA256 and PB2 for PBKDF2. Below those starting versions, the same tip still labels the hash function SHA256. The 7.2.11 release notes describe the new scheme as PBKDF2 with a randomized salt, to raise the storage security of local system administrator passwords. That is a different sentence from “the page says encrypted.” SHA-256 and PBKDF2 here are both one-way derivations. Neither is a symmetric key wrapping the password into reversible ciphertext. Seeing SH2 does not mean the disk holds plaintext. Seeing PB2 does not mean a leaked plaintext no longer matters.
PBKDF2 has no single worldwide iteration count that already counts as “slow enough.” The vendor documents the algorithm name, the salt, and the SH2 / PB2 markers in the configuration. The tip above does not publish an iteration integer you can paste into a ticket. A record that says “this account in the backup is already PB2” stays closer to what the documentation supports than a record that says “so a GPU cannot crack it.” Short passwords, and passwords copied from an old leak, remain cheap guesses under a finite iteration count. A long random password that differs per account raises the search space. It does not close a management interface that is open to the internet.
An upgrade does not replace the old hash before login
The sentence in the technical tip that is easiest to skip: when you upgrade from an earlier version, administrator passwords are still stored as SHA256 until that specific administrator logs in successfully on the new firmware. To move every local administrator to PBKDF2, each person has to log in at least once. Anyone who has not logged in yet needs a super_admin to update the password by hand. Writing the firmware version number into a change ticket does not prove the configuration no longer contains SH2.
Even after the current password field has become PBKDF2, the old hash does not vanish on its own. The tip says that, for backward compatibility, the previous SHA256 value remains by default in the hidden old-password setting. The management GUI after an ordinary login does not show this item. A configuration backup exported by super_admin can. As long as that older material is still in the backup, it is still an object for offline cracking. An attacker does not have to wait until you finish the firmware upgrade to copy it. A backup file that lands in a cloud drive, a ticket, or a chat transcript is another copy of SH2.
Clearing the SH2 value inside old-password is a separate switch. The upgrade leaves that field in place. On FortiOS 7.2.x and 7.4.x the setting is login-lockout-upon-downgrade. Later documentation also names login-lockout-upon-weaker-encryption. Turning it on shows a confirmation warning. PBKDF2 is available from 7.2.11, 7.4.8, and 7.6.1. If you later move to a release that does not support that hash, local administrators cannot log in. Fortinet’s own troubleshooting note treats an upgrade from 7.2.11 to 7.4.7 as that lock: the version number is higher, and 7.4.7 still has no PBKDF2. The same note says this lockout applies to locally stored administrator accounts. Administrators who authenticate with LDAP, RADIUS, or SAML do not use this local hash, and this downgrade lock does not apply to them. Local accounts are the ones the SH2 / PB2 markers describe.
So “turn on removal of the old hash” and “we might still roll the firmware back tonight” conflict. On the day of an incident, if you have not yet decided which PBKDF2-capable release the device will stay on, do not open this lock just to erase SH2. Keep a path that can still enter the device. Clear the old material after you have confirmed you will not go back. The advisory’s line “confirm PBKDF2 and remove weaker legacy hashes” points at this vendor note. Changing the password once in the portal leaves that step unfinished.
The lockout happens after a successful login
The first reaction to the news is often to reset every administrator password. A reset can retire a plaintext string the other party has not used yet. If you can still get in, it can also push storage from SH2 toward PB2. It does not handle “they already signed in as you and changed that account itself.” The advisory describes deleting the original account or changing its password so the legitimate administrator cannot log in, while creating accounts that did not exist before, to keep their own access. An authentication failure on the VPN portal then proves “the device no longer accepts this credential.” It does not prove “they have no new account.”
The ticket should therefore have two columns. One column is passwords and hashes: whether each local administrator is SH2 or PB2 now, whether the backup still has old-password, and whether the new password is reused with email, a cloud console, or another VPN. The other column is the account inventory: local administrators that did not exist before the advisory, whether every current session has been ended, and whether the public management interface is still open to any address. Phishing-resistant multi-factor authentication makes “password only” insufficient for remote administration and VPN. It does not delete a new account already written into the configuration, and it does not pull an already copied old hash back out of someone else’s GPU queue.
Keep the ransomware sentence in its place. The advisory says initial access was handed on. It does not say every firewall still using SHA-256 will be encrypted today. A device you can no longer sign in to should be handled as a device whose integrity you cannot confirm: isolate it, compare configuration and accounts, then talk about recovery. A device you can still sign in to should first pull the public management plane back, end sessions, move local administrators that are still SH2 over to PB2, and store the new password separately. Neither path should become “paste the same new password into the group announcement.”
Check the backup markers on a device you administer
A version number, a news headline, and the words “already upgraded” do not replace the hash marker in this configuration. The four steps below assume you are already an authorized administrator of this device. Do not open the backup on an untrusted computer. Do not upload the backup to a generative chat “to see whether it contains SH2.”
- Compare the firmware version with the three starting points: 7.2.11, 7.4.8, and 7.6.1. Below the starting point for that branch, the vendor tip still labels the local administrator hash SHA256. A version above the starting point only means a new login can be written as PB2. It does not mean every older account has already been rewritten.
- Export a configuration backup as
super_adminand search it on this machine forSH2,PB2, andold-password. You can record “this backup shows no leftover SHA-256 for this account” only when that account hasPB2and noold-password. The GUI hides that field, so a blank management screen still leaves the backup as the place to look. - List local administrators and mark accounts that have never logged in since the upgrade and have not had their password reset by a super administrator. The tip says those accounts stay on SHA256 until a login or a reset happens. Do not fold remotely authenticated accounts into the same conclusion as this local hash.
- If you are considering
login-lockout-upon-downgrade(orlogin-lockout-upon-weaker-encryptionin later docs), read the downgrade-lock warning first and confirm you will not move back to a release without PBKDF2 in the short term. After the switch is on, local administrators who have only PBKDF2 left cannot log in on that rollback. Fortinet documents the 7.2.11 to 7.4.7 path as one of those moves.
Those four steps answer “which scheme this configuration uses for the administrator password right now.” They do not answer “whether someone else’s GPU queue already holds an earlier copy.” Once a hash has left the device, changing storage on this machine does not invalidate the copy. Invalidating it means changing the password itself, and confirming the new material is no longer left as SH2 inside old-password. Whether the public management plane is closed is an interface policy. The hash prefix answers a different question.
Four readings that outrun the advisory
First, reading “the firmware is already 7.2.11 or later” as “SHA-256 is no longer in the configuration.” The tip binds conversion to that administrator’s successful login or to a password reset, and it leaves the old hash in a hidden field by default. The version number marks where conversion can start. Completion is a successful login or a reset, visible as PB2 with no old-password.
Second, reading PBKDF2 as “reused passwords have stopped working.” A slow derivation raises the unit price of offline guessing. Plaintext already taken from another site, an old leak, or an infostealer log is submitted unchanged at login. A different password in each place stops that path. It does not stand in for pulling the management interface back.
Third, reading “I changed the password” as “lockout cannot happen,” or as “a lockout that has already happened can be undone by the same reset.” A password change requires that you can still submit the change. If the other party has deleted the account or replaced the password, failure on the portal means the old credential is not accepted. The new password does not automatically delete an administrator they created.
Fourth, reading “this string is absent from the local weak-password list” as “it is absent from FortiBleed’s hash queue,” or as “this firewall is already on PBKDF2.” The list comparison happens in the browser tab. The device hash marker lives in the configuration backup. The two pieces of evidence do not stamp each other. A miss can still be a long password that was reused. A hit only means the string is too common. It does not, by itself, prove this FortiGate has been intruded.
FAQ
After upgrading to FortiOS 7.2.11, is the SHA-256 hash gone immediately?
No. The vendor tip says that from 7.2.11, 7.4.8, and 7.6.1, local administrator passwords move to PBKDF2, and after the upgrade they remain SHA256 until that administrator logs in successfully, or a super_admin resets the password. The old hash stays in the hidden old-password field by default. A super_admin configuration backup can show it. The ordinary management GUI cannot. Clearing the old hash requires a separate policy of the downgrade-lock kind, and you accept that local administrators cannot log in if you later move to a release that does not support PBKDF2.
After the switch to PBKDF2, does stolen plaintext still work?
Yes. PBKDF2 raises the cost of the case “hash only, guess one candidate at a time.” If the other party already has the plaintext from an old leak or an infostealer log, they submit that string at login and do not have to crack the hash. Reuse of the same password across email, VPN, and the administrator account stays valid. A slow derivation does not turn that plaintext into the wrong string.
If you are already locked out, does another password change help?
That change on the portal requires that you can still log in. The advisory says the other party may delete the original account or change its password, so the legitimate administrator cannot sign in, while creating accounts that were not there before. Treat a device you cannot enter as a device to isolate and whose configuration you compare. One more password reset leaves that isolation and comparison still to do. A password change also does not replace an old hash that the firmware has not converted, or that is still sitting in old-password.
Can a local weak-password list prove this firewall’s hash was not cracked?
No. The local list only answers whether this string matches the public high-frequency list in the current tab, including a few variants. It does not query FortiBleed, and it does not read the firewall configuration. A miss does not prove the password was never leaked, and it does not prove the hash on the device has become PBKDF2. A hit only means the string is too common, should be replaced, and should not keep being reused.
Keep the new password on this machine
After storage moves from SH2 to PB2, you still need an administrator password that has not been used anywhere else. You can make that string in the current tab with FastPwd’s password generator. No registration, and the site has no password vault. Random mode uses crypto.getRandomValues, length 6–128, default 16. Below 8 characters the page warns that security is lower. The result is not uploaded by default. It does not log in to your firewall, it does not change SH2 into PB2, and it does not close a public management interface. What it gives you is a string you do not have to invent from “admin / company name / the season,” for a local account you can still reach.
Open DevTools, switch to Network, enable preserve log, and search the request line and the request body for the entire new password. Business requests should not contain that string. This step proves “this time it did not leave the tab as an HTTP body.” It does not prove you later pasted it into a chat app. If the browser asks to save the password, decline. A password saved in the browser is a different door, and it has nothing to do with FortiOS PB2. A default 16-character password drawn from uppercase, lowercase, digits, and symbols has a search space far larger than the short words spraying usually tries. Do not rewrite that sentence as “therefore SHA-256 can never compute it” or “therefore the management interface can stay open to the internet.”
If you also want to see whether a string looks like a weak password on a public high-frequency list, take a disposable test string and check it in Password Audit. The password under test is not uploaded. The comparison uses the public list downloaded with the page. Have I Been Pwned and the FortiBleed hash set sit outside that check. A miss does not prove the string has never been seen on the web. Do not paste the firewall password you are about to enable into the check box, and do not run a configuration backup through the checker.
If the new password has to reach one other on-call colleague a single time, do not put it in a group message or a ticket body that stays on a server. Use Burn-Link instead. The server stores ciphertext only, the key sits after # in the link, and both creating and reading need no account. The link shape is s.html?id={id}#{key}. That channel answers “how to hand it over once.” It does not answer “how to repair the firewall.” If a configuration backup contains SH2 or old-password, do not place the whole file in a burn link or a cloud drive. Keep the backup on a machine you already trust, and handle it under your own configuration-custody rules when you are done. A screenshot, or a forward of the complete link, is a copy that burn-after-read does not cover.
Further reading
A local weak-password list can catch common weak passwords. A full-web breach lookup, and the hash set from one incident, are separate checks: see What a local leaked-password list can prove, and why it is not a full-web lookup. A generated password should use a cryptographically secure random source. Math.random is a different generator: see Why a password from Math.random can look messy and still not be cryptographically secure. When a one-time key sits after the hash mark in a link, the server does not receive that fragment by default: see Why a URL hash can hold a key, and when that protection fails.