Critical analysis of the 75,000-device Fortinet credential exposure

In June 2026, headlines began circulating claiming that 75,000 Fortinet firewalls had been compromised worldwide. Articles quickly described the event as one of the largest perimeter security incidents ever discovered. The campaign received the name FortiBleed, and organizations began asking the same question:

“Is there a new Fortinet vulnerability?”

Surprisingly, the answer appears to be no. After examining the reporting from Hudson Rock, Bob Diachenko, Kevin Beaumont, SOCRadar, Arctic Wolf, Rapid7 and Fortinet itself, the picture that emerges is considerably more nuanced than many headlines suggest.

 

What actually happened?

According to Hudson Rock, a dataset involving approximately 73,932 Fortinet devices was discovered. Kevin Beaumont independently verified that:

• the data is genuine;
• most devices are still online;
• many are running recent firmware;
• the information appears to originate from configuration exports rather than internet scanning alone.

Importantly: No researcher has publicly identified a new Fortinet zero-day. Neither Fortinet nor independent researchers currently attribute FortiBleed to a previously unknown vulnerability.

 

Why the headlines are misleading

Many articles give the impression that 75,000 devices compromised = 75,000 devices hacked today. This is almost certainly false. The evidence suggests something very different:

Compromises accumulated over several years + Weak credentials+
Previously compromised devices + Configuration exports + Offline password cracking
= Large credential database discovered in 2026. In other words: Discovery does not equal compromise date. The most likely chain of events. Based on currently available evidence, the following reconstruction appears most plausible:

═════════════════════════════════════════════════════
STAGE 1 – INITIAL ACCESS
═════════════════════════════════════════════════════

This stage represents the original compromise. Attackers first needed a way to gain administrator-level access to FortiGate devices. Public evidence does not point to a single cause, but rather a combination of older vulnerabilities, weak or reused passwords, credential stuffing and previously stolen credentials. Once administrator privileges were obtained, the attackers had the same capabilities as a legitimate administrator.

 

Internet-facing FortiGate devices
├── old vulnerabilities
├── credential stuffing
├── password reuse
├── brute forcing
└── previously stolen credentials
↓
Administrator access obtained

═════════════════════════════════════════════════════
STAGE 2 – CONFIG EXPORT
═════════════════════════════════════════════════════
After obtaining administrative access, attackers exported the FortiGate configuration files. These backups contain far more than firewall rules; they effectively represent a blueprint of the entire device and often include administrator accounts, VPN users, certificates, internal network ranges and password hashes. Over time, attackers likely accumulated tens of thousands of such configuration files.

Attackers export:
config.conf

containing:
• administrator accounts
• VPN users
• LDAP settings
• certificates
• firewall policies
• internal network ranges
↓
Large collection of configuration files

═════════════════════════════════════════════════════
STAGE 3 – HASH EXTRACTION
═════════════════════════════════════════════════════
With the configuration files in hand, the attackers began extracting authentication material. Rather than immediately possessing plaintext passwords, they obtained usernames together with their associated salts and password hashes. These hashes became the raw material for the next phase of the operation.

username
salt
SHA256 hash

are extracted from each config

═════════════════════════════════════════════════════
STAGE 4 – OFFLINE GPU CRACKING
═════════════════════════════════════════════════════
Instead of attacking live devices directly, attackers attempted to recover passwords offline. Because many older FortiGate configurations stored credentials using fast SHA-256-based hashes, modern GPU hardware could test billions of password candidates without generating any logs, triggering lockouts or interacting with the devices themselves. Weak and predictable passwords could therefore be recovered efficiently.

 

 

candidate password
↓
SHA256(salt + password)
↓
compare billions of attempts/sec

No logs.
No lockouts.
No MFA.

Pure offline attack.

═════════════════════════════════════════════════════
STAGE 5 – PASSWORD RECOVERY
═════════════════════════════════════════════════════
After extensive cracking operations, attackers successfully converted many hashes into plaintext credentials. In effect, they transformed previously unusable password hashes into working usernames and passwords. Devices protected by strong, unique passwords would likely have resisted this stage, whereas weak or reused passwords could be recovered relatively quickly.

admin: Winter2025!

vpnadmin: Company123!

support: Summer2024!

═════════════════════════════════════════════════════
STAGE 6 – LIVE VALIDATION
═════════════════════════════════════════════════════
Possessing a recovered password does not guarantee that it is still valid. Therefore, attackers attempted to authenticate to internet-facing FortiGate devices using the recovered credentials. Successful logins confirmed that the passwords remained active and that the corresponding systems were still accessible. Only these successfully authenticated devices became part of the final dataset.

Recovered passwords tested against active devices.

Successful logins
→ VERIFIED

═════════════════════════════════════════════════════
STAGE 7 – DATABASE BUILT
═════════════════════════════════════════════════════
The final result was not simply a collection of password hashes, but a structured database of verified devices and credentials. According to current public reporting, this database contained information on approximately 75,000 FortiGate devices across 194 countries, with over 30,000 credentials believed to have been successfully validated. This transformed years of individual compromises into a highly valuable intelligence dataset.

75,000 devices
30,791+ verified credentials
194 countries

The campaign only became public after researchers discovered evidence of the attackers’ infrastructure or exposed databases. Independent analysis by Bob Diachenko, Hudson Rock, Kevin Beaumont and SOCRadar confirmed that the data appeared genuine. Ironically, the compromise itself may have taken place over several years, while the public only became aware of it once the attackers’ own data was exposed or otherwise uncovered.

 

Why password hashes matter

The technical aspect receiving the most attention concerns password storage. Older FortiOS versions used fast SHA-256-based hashes.

Conceptually:

hash = SHA256(salt + password). SHA-256 is extremely fast. That is great for integrity checking. It is terrible for password storage. Attackers with GPU clusters can test billions of passwords.

 

Newer FortiOS releases move to PBKDF2: hash = PBKDF2(password, salt, iterations). PBKDF2 intentionally slows each password guess by performing thousands of repeated operations.

The result:

Algorithm	Offline cracking
SHA256	Easy at scale
PBKDF2	Much slower
Plaintext passwords	Immediate

However, upgrading firmware alone does not necessarily regenerate existing password material. Legacy hashes may remain until passwords are changed or migrated. This has become one of the leading explanations behind FortiBleed.

 

Haven’t we seen this before?

Interestingly, FortiBleed would not be the first case where large numbers of Fortinet credentials or configuration files surfaced years after the original compromises occurred. Previous incidents demonstrate that the discovery or publication date often differs significantly from the date on which devices were actually breached. In several cases, attackers quietly collected data over months or years before it eventually became public. Viewed in this context, FortiBleed appears less like an isolated event and more like the latest chapter in a series of long-running Fortinet credential exposures.

 

2021: CVE-2018-13379

• Half a million VPN credentials were eventually leaked.
• Compromises happened in 2019.
• Publication happened in 2021.

2025: Belsen Group

• 15,000 FortiGate configurations were released.
• Researchers believe many devices had actually been compromised around 2022.

 

2026: FortiBleed

• 75,000 devices.
• Unknown acquisition vector.
• Likely years of accumulated compromises.
• Very similar pattern.

 

The biggest unanswered question

One of the biggest unanswered questions surrounding FortiBleed is also the most important one:

Where did tens of thousands of FortiGate configuration files originally come from?

Despite extensive analysis and widespread media coverage, no definitive answer has emerged. While researchers broadly agree that the dataset itself appears to be genuine, the initial acquisition vector remains unknown. In other words, investigators have a fairly good understanding of what the attackers possessed, but not how they obtained it in the first place.

Several scenarios have been proposed, including the exploitation of historical Fortinet vulnerabilities, credential stuffing attacks, password reuse, previously compromised devices, and long-term collection efforts spanning multiple years. However, none of these theories has been conclusively proven.

What makes the situation particularly interesting is that some of the most respected researchers and organizations involved in the investigation—including Hudson Rock, Bob Diachenko, Kevin Beaumont, SOCRadar, Arctic Wolf, and Fortinet itself—have all reached essentially the same conclusion: the exposed data appears to be real, but no publicly available evidence currently explains the original source of the configuration files.

This distinction is important. The existence of a large database of compromised credentials does not automatically imply the existence of a new vulnerability. In fact, there is currently no public evidence suggesting that FortiBleed resulted from a previously unknown Fortinet zero-day. Instead, the available information points to a much more complicated picture involving historical compromises, accumulated over time and only discovered years later.

Ironically, the attackers themselves may ultimately become the weakest link in the story. Just as many previous cybercriminal operations have been exposed through mistakes, leaks, or misconfigured infrastructure, it is possible that FortiBleed became public not because the original attacks were detected, but because the attackers’ own databases or operational infrastructure were eventually discovered. Until more evidence emerges, however, the true origin of the tens of thousands of FortiGate configuration files remains one of the largest unresolved mysteries of the entire FortiBleed campaign.

 

Is FortiBleed really exceptional?

This is where a more critical perspective becomes important.

The headlines surrounding FortiBleed have understandably attracted significant attention. A database allegedly containing information related to approximately 75,000 FortiGate devices certainly sounds alarming, and the sheer scale of the exposure should not be dismissed. However, an important question remains: is FortiBleed truly an extraordinary event, or is it simply an unusually visible example of something that occurs every day across the Internet?

Cybercriminals continuously target internet-facing systems. Every day, thousands of SSH servers are subjected to brute-force attacks. Remote Desktop Protocol (RDP) systems are scanned and attacked around the clock. VPN appliances are probed for vulnerabilities and weak credentials. Routers and firewalls are exploited through known vulnerabilities, while infostealer malware harvests millions of usernames and passwords from infected computers. In parallel, widespread password reuse means that credentials stolen in one breach often provide attackers access to completely unrelated systems.

None of these activities are unusual. In fact, they represent the background noise of the modern Internet. Most attacks go unnoticed outside the affected organizations, and even when credentials or configuration files are stolen, the incidents rarely receive widespread media coverage. In many cases, compromised data remains in criminal hands for years without ever becoming public knowledge.

What makes FortiBleed different may not necessarily be the underlying attacks themselves, but rather the discovery of a large aggregated dataset and the attention that followed. Previous Fortinet-related incidents have shown that attackers frequently collect compromised credentials and configuration files over long periods of time before they are eventually leaked, sold, or inadvertently exposed. From this perspective, FortiBleed may simply represent years of accumulated compromises that were finally uncovered and packaged under a memorable name.

This is not to say that the incident should be ignored. The existence of tens of thousands of potentially compromised devices is significant, and organizations should take the findings seriously. However, there is a risk that the branding surrounding the event creates the impression of a sudden, unprecedented catastrophe when the reality may be far less dramatic. The cybersecurity industry has a long history of assigning catchy names to incidents, sometimes causing the narrative to overshadow the underlying technical facts.

Indeed, one could argue that the most remarkable aspect of FortiBleed is not that attackers targeted Fortinet devices—something that happens every day—but that researchers happened to uncover a sufficiently large dataset for the story to gain international attention. Had the same information remained hidden in criminal infrastructure, the compromises themselves might never have made headlines at all.

Viewed in this light, FortiBleed may be less a story about a single extraordinary attack and more a reminder of a much broader and persistent reality: cybercriminals continuously exploit weak passwords, reused credentials, exposed services, and historical vulnerabilities. Eventually, enough individual compromises accumulate, someone discovers the resulting database, and the cybersecurity community gives the phenomenon a name. In that sense, FortiBleed may be significant—but perhaps not nearly as exceptional as some of the headlines would suggest.

 

Is FortiBleed Another Heartbleed?

At first glance, the name “FortiBleed” inevitably invites comparisons with Heartbleed, one of the most famous cybersecurity vulnerabilities in history. However, despite the similarity in naming, the two events appear to have very little in common from a technical perspective.

Heartbleed, disclosed in 2014, was a clearly defined software vulnerability affecting OpenSSL. Researchers quickly identified the root cause, understood exactly how the flaw could be exploited, and demonstrated that attackers could extract sensitive information directly from vulnerable systems. The vulnerability itself was well understood, the exploitation method was known, and organizations around the world were immediately able to determine whether they were affected. In essence, Heartbleed represented a specific bug that caused widespread and immediate exposure.

FortiBleed, at least based on what is currently known, appears to represent something fundamentally different. There is no public evidence pointing to a new Fortinet vulnerability, nor has a single exploit or attack technique been identified as the root cause. Instead, the available evidence suggests that the exposed dataset may be the result of years of accumulated compromises involving weak or reused passwords, previously exploited vulnerabilities, exported configuration files, and the offline cracking of legacy password hashes.

Rather than a single catastrophic event, FortiBleed appears to be the product of many separate incidents that may have occurred over several years. Some devices may have been compromised through historical Fortinet vulnerabilities. Others may have fallen victim to credential stuffing or password reuse. Once attackers obtained administrator access, configuration files could be exported and password hashes extracted. Weak passwords could then be recovered through offline cracking and validated against still-accessible systems.

This distinction is important because it fundamentally changes how the incident should be viewed. Heartbleed represented an immediate and widespread software flaw that required urgent patching. FortiBleed, on the other hand, appears to be a large collection of the consequences of numerous independent security failures accumulated over time. The problem is not necessarily one specific vulnerability, but rather a combination of historical compromises, legacy password storage mechanisms, exposed management interfaces, and poor credential hygiene.

For this reason, comparing FortiBleed to Heartbleed may ultimately be misleading. Heartbleed was a single vulnerability with a known exploit path and a clearly identifiable cause. FortiBleed currently appears to be a symptom of something much broader and more familiar: the gradual accumulation of weak passwords, old compromises, and historical attack vectors that have quietly persisted for years before finally coming to light.

In that sense, FortiBleed may not represent another Heartbleed at all. Instead, it may serve as a reminder that some of the greatest cybersecurity risks do not always arise from spectacular new vulnerabilities, but from the long-term consequences of weaknesses that organizations have known about—and struggled with—for decades.

 

Final Thoughts

There is little reason to doubt that the FortiBleed dataset itself is real. Multiple independent researchers have examined portions of the data, and there is broad agreement that the credentials and device information are genuine. But that does not automatically mean that FortiBleed represents a new cybersecurity catastrophe—or that it deserves to be spoken about in the same breath as Heartbleed or other landmark vulnerabilities.

Based on everything currently known, FortiBleed does not appear to be the result of a newly discovered Fortinet flaw or a sophisticated breakthrough attack. Rather, it looks like the predictable outcome of years of familiar problems: exposed management interfaces, weak passwords, password reuse, historical compromises, legacy hash formats, and ordinary cybercrime. None of these are new. None are particularly surprising. And none require the existence of a mysterious zero-day vulnerability.

This is where some skepticism is warranted. The cybersecurity industry has a tendency to package almost every noteworthy event into a branded incident complete with catchy names, logos, dramatic headlines, and apocalyptic predictions. Naming something “FortiBleed” inevitably invites comparisons to Heartbleed, even though the technical similarities appear to be minimal. The name itself creates the impression of a single, newly discovered flaw causing an immediate global crisis, when the evidence points toward something much less sensational: the accumulation of compromises that may have occurred over several years.

One could argue that the most remarkable aspect of FortiBleed is not the attack itself, but the marketing narrative that has formed around it. Reading some headlines, one might conclude that 75,000 Fortinet devices were suddenly hacked overnight. In reality, there is no evidence supporting such a scenario. A more accurate interpretation may be that researchers discovered a large database containing the results of many unrelated incidents that had accumulated over time. The discovery is important, but that is very different from claiming that a new mass compromise has occurred.

Perhaps the most uncomfortable question is this: if the exact same database had contained 75,000 Cisco, Palo Alto, SonicWall, VPN, SSH, or RDP systems, but nobody had given it a memorable name, would anyone be calling it one of the biggest cybersecurity events of the decade?

Probably not.

In fact, similar collections of compromised credentials exist throughout the cybercrime ecosystem. Millions of passwords stolen by infostealers circulate daily. Countless VPN credentials are bought and sold in underground markets. Configuration files and access databases routinely appear on criminal forums. Most of these incidents never receive dedicated logos, media campaigns, or dramatic branding. They simply disappear into the endless background noise of cybercrime.

This does not mean organizations should ignore FortiBleed. On the contrary, the findings should serve as a reminder that weak passwords, exposed management interfaces, and poor credential hygiene remain serious problems. But there is a danger in confusing the existence of a large dataset with the existence of a large new threat.

Ultimately, FortiBleed may tell us less about Fortinet than it does about the cybersecurity industry’s appetite for narratives. The underlying story appears to be depressingly ordinary: attackers compromise systems, steal credentials, crack weak hashes, accumulate data over time, and eventually someone discovers the collection. The only thing that changed is that this time, somebody gave it a name.

And perhaps that is the most important lesson. Sometimes the difference between a routine consequence of decades-old security failures and “the next Heartbleed” is not a revolutionary attack technique or a catastrophic new vulnerability.

Sometimes, the difference is simply a press release.