If your business runs a FortiGate firewall or Fortinet SSL VPN, this week’s headlines deserve a measured response, not panic. A credential-harvesting campaign that researchers have nicknamed “FortiBleed” is circulating working login credentials for tens of thousands of internet-facing Fortinet devices worldwide. Here is the part the alarming name obscures: there is no new zero-day. The credentials were largely stolen in earlier Fortinet compromises and are now being fired back at organizations that never rotated them.

This post breaks down what FortiBleed actually is, what Fortinet has said about it, why it still poses real risk despite being “old” data, and the specific steps Canadian mid-market teams should take to close the exposure.

FortiBleed is not a new vulnerability or a fresh breach of Fortinet’s products. It is a large collection of credentials harvested in earlier incidents, now being reused against organizations that never rotated them. Fortinet has stated the activity is not related to any recent incident or advisory. The risk is real but the fix is hygiene: if you run internet-facing Fortinet devices and have not rotated credentials in years, assume exposure, rotate every credential, enforce MFA, and pull the management interface off the public internet.

What is FortiBleed?

FortiBleed is the informal name given in June 2026 to a large dataset of administrator and SSL VPN credentials for internet-facing Fortinet devices, primarily FortiGate firewalls. Despite the dramatic name, it is not a vulnerability or a new product flaw. The credentials were largely gathered from device configuration files and weak password hashes exposed in earlier Fortinet compromises, and are now being reused and brute-forced against live devices across 194 countries.

The campaign came to light after security researcher Volodymyr “Bob” Diachenko found an attacker-controlled server left publicly accessible, exposing the operation’s stolen credentials, victim lists, and tooling. Threat intelligence firm SOCRadar independently analyzed the same infrastructure and rated the campaign critical. The scale is what makes it notable: depending on the dataset analyzed, researchers count between roughly 74,000 and 87,000 affected devices and tens of thousands of verified working credentials across more than 22,000 domains.

What has Fortinet said about FortiBleed?

Fortinet has stated it is aware of the credential-harvesting activity targeting FortiGate firewalls and VPN devices, but that the activity is based on data from previous incidents and is not related to any recent incident or advisory. In other words, attackers are reusing previously exposed credentials and applying brute-force techniques against devices, rather than exploiting a new flaw in current Fortinet products.

This matches what security researchers concluded after examining the dataset: there is no associated CVE or patch for “FortiBleed” itself because there is no new vulnerability. Much of the credential and configuration data traces back to older Fortinet compromises, including devices exploited through CVE-2022-40684, an authentication-bypass flaw from 2022. The data was collected years ago and is now being recirculated and tested at scale.

The takeaway is not “ignore it.” It is “this is a hygiene problem, not a patch problem.” Organizations most at risk are those that never rotated administrator or VPN credentials after the 2022-era Fortinet compromises. If that describes your environment, those old passwords may still work, and that is exactly what attackers are counting on.

Why is patching alone not enough?

Because the exposed credentials remain valid regardless of firmware version. Security researcher Kevin Beaumont noted that many of the affected devices were on fairly recent patches, and that the data appears to have come from exports of device configurations. A fully patched device still grants access to anyone holding a credential that was never rotated.

How older credentials were stored compounds the problem. Many devices still hold passwords hashed with salted SHA-256, which is feasible to crack offline with modern GPU hardware. Fortinet moved to the stronger PBKDF2 algorithm with randomized salt in early 2025, but devices upgraded without an administrator logging back in often keep the older, weaker hashes in place. In short: a device can be patched to the latest firmware and still be carrying crackable, never-rotated credentials.

A current FortiOS version does not mean you are safe. If your administrators have not logged in to re-hash credentials after upgrading, your device may still store passwords using the older, crackable SHA-256 format that FortiBleed operators are exploiting.

How does the FortiBleed campaign work?

FortiBleed is built on industrialized automation rather than manual hacking. According to SOCRadar’s analysis of the exposed attacker server, the operation runs as a self-perpetuating cycle: scan, validate, harvest, repeat. The mechanics break down into three reinforcing techniques.

Credential stuffing and password spraying: Attackers test large volumes of credentials gathered from infostealer logs, dark-web archives, and prior breaches against FortiGate web panels and SSL VPN portals, recording every successful login.

Passive listening posts: Once a device is compromised, attackers use it to quietly capture additional credentials flowing through the network, feeding fresh logins back into their automated scanner.

Hash interception and offline cracking: Where password reuse fails, attackers intercept SSL VPN authentication hashes and crack them offline on a GPU cluster, recovering plaintext passwords that work on internal systems too.

The end goal is straightforward and dangerous: valid credentials let an attacker log in as a legitimate user, reach the firewall and the network behind it, change security controls, and create backdoor accounts. Researchers traced the cracked passwords being used to pivot into internal Active Directory environments, which turns a perimeter exposure into a full network compromise.

Who is affected, and does it reach Canadian businesses?

Yes. With devices in 194 countries and over 20 percent of entries tied to enterprises with $1B+ in revenue, the dataset is global and includes Canadian organizations. Named victims reported in coverage include major brands such as Samsung, Siemens, Foxconn, Oracle, Accenture, and DHL, alongside government agencies in critical-infrastructure sectors.

Telecom was the single most-targeted sector, followed by government, with healthcare and finance also heavily represented. For Canadian mid-market firms, the compliance stakes are real: a credential-driven breach can trigger mandatory breach reporting under PIPEDA, and regulated organizations in finance or healthcare face additional obligations under OSFI guidance and PHIPA. The Canadian Centre for Cyber Security has repeatedly flagged edge devices like VPN gateways as a priority target, and FortiBleed is a textbook example.

What should you do right now?

If your organization runs internet-facing Fortinet appliances and has not rotated credentials in the last few years, treat your existing credentials as potentially exposed until proven otherwise. The actions below are the same whether or not your specific device is in any dataset, because they close the reuse window that FortiBleed depends on. From a security operations standpoint, the response order matters: contain access first, then verify exposure, then harden.

Rotate every credential: Force a complete reset of all passwords tied to Fortinet VPN access and local administrative accounts. Assume current passwords are already in the attackers’ dataset.

Enforce MFA everywhere: Require multi-factor authentication on every administrator and remote-access session. Stolen passwords alone should never be enough to log in.

Pull the management interface off the internet: Restrict the FortiGate admin interface so it is not directly exposed to the public internet. Limit SSL VPN access to known sources where possible.

Upgrade FortiOS and re-hash credentials: Update to a supported FortiOS release (Fortinet guidance points to 7.2.11+, 7.4.8+, and 7.6.1+), then have every admin log in after the upgrade so passwords are re-stored using the stronger PBKDF2 algorithm.

Hunt for compromise: Review VPN and admin login histories for unfamiliar sources, check for unauthorized admin accounts or config changes, and watch for lateral movement into Active Directory. Engage incident response if anything looks off.

Do not just reset passwords and move on. Because compromised devices were used as passive listening posts, any credential that traversed that network, not only the firewall login, should be considered exposed. Rotate downstream service and domain accounts too, and monitor for replays over the following weeks.

Patching vs. credential hardening: where to focus

FortiBleed is a reminder that perimeter security is about identity as much as firmware. The table below maps the common assumption against the reality of this campaign, so you can prioritize the actions that actually reduce risk.

Action Stops a software exploit? Stops FortiBleed?
Apply latest FortiOS patch Yes Partially (firmware alone leaves old hashes)
Rotate all VPN and admin credentials No Yes, removes the stolen credentials
Enforce MFA on all access No Yes, blocks reuse of stolen passwords
Remove admin interface from public internet Partially Yes, shrinks the attack surface
Re-hash passwords to PBKDF2 after upgrade No Yes, defeats offline cracking

Track developing indicators of compromise and the latest outbreak guidance directly from Fortinet’s FortiGuard Labs outbreak alerts. Pair vendor advisories with active monitoring rather than relying on either alone.

The lesson of FortiBleed is that a patched device is not automatically a secure device. Credentials, MFA, exposed management interfaces, and password-hash hygiene are what separate the breached organizations from the protected ones. If you cannot quickly confirm all four are handled across your Fortinet estate, you have exposure to close.

If you are not certain whether your Fortinet devices store crackable hashes, expose their management interface, or enforce MFA on every session, that uncertainty is the gap attackers are counting on. As a managed security partner to Canadian mid-market firms, our team handles exactly this kind of rapid exposure review: credential rotation, MFA rollout, and locking down edge devices. Start with our managed Fortinet firewall services, harden access with a zero-trust MFA rollout, or get continuous detection through our MDR and XDR service. If you suspect you are already affected, our incident response and forensics team can help you scope and contain it.

Frequently asked questions

Is FortiBleed caused by a Fortinet vulnerability?

No. Fortinet has stated the activity is not related to any recent incident or advisory, and there is no CVE or patch for “FortiBleed” because it is not a new flaw. It is a collection of credentials harvested in earlier compromises, some tracing back to CVE-2022-40684 in 2022, now being reused and brute-forced against live devices. That is why patching alone does not resolve it: you have to rotate the old credentials and re-hash passwords with PBKDF2.

How do I know if my Fortinet device is affected?

Assume potential exposure if any FortiGate or Fortinet SSL VPN interface is reachable from the internet. Review VPN and admin login histories for unfamiliar source addresses, check for unauthorized admin accounts or configuration changes, and watch for unusual Active Directory activity. Threat-intel lookup tools released alongside the campaign can also indicate whether your domain appears in the dataset.

Does enabling MFA fix the problem?

MFA is essential but not sufficient on its own. It blocks attackers from reusing stolen passwords, which is critical, but you still need to rotate the exposed credentials, remove the management interface from public internet access, and re-hash stored passwords to PBKDF2. MFA is one layer of a four-part response, not a single fix.

What are the compliance implications for Canadian companies?

A credential-driven breach can trigger mandatory breach-of-security-safeguards reporting to the Office of the Privacy Commissioner under PIPEDA, with notification to affected individuals where there is a real risk of significant harm. Regulated organizations in finance or healthcare may have further obligations under OSFI guidance or provincial health-privacy laws such as PHIPA. Document your response and timeline carefully.

Sources