FortiBleed Wasn’t a Bug: It Was a Password Problem

Network cables connected to a firewall and switch in a server rack
Photo by Kirill Sh on Unsplash

In June 2026, researchers found something alarming sitting in a threat actor’s open directory: login details, including many plaintext passwords, for tens of thousands of Fortinet firewalls and VPN gateways around the world.

The incident became known as FortiBleed. Researchers who reviewed the data counted roughly 73,932 unique firewall addresses across 194 countries and 21,632 affected domains, according to Censys. Months later, the problem hasn’t gone away. The FBI has warned that the FortiBleed attack chain is still being used as an entry point for ransomware, with attackers using stolen credentials and locking IT administrators out of their own systems (ITdaily).

What makes FortiBleed worth understanding, even if you’ve never owned a Fortinet device, is that, according to Fortinet, it wasn’t caused by a new software bug at all.

What Actually Happened

The leaked dataset contained firewall URLs, usernames, email addresses and, in many cases, plaintext passwords for FortiGate firewalls, SSL VPN gateways and their administrative management pages. Fortinet’s own analysis concluded the activity was not a new vulnerability in its products. Instead, the data appears to have been assembled from a mix of sources: credentials reused from earlier incidents, password-spraying attacks against exposed login pages, and offline cracking of password data pulled from device configuration files.

Researchers also pointed to a technical factor that made cracking easier. Older FortiGate configurations could store administrator passwords using legacy hashing methods that are far weaker than modern standards. If an attacker obtained a configuration file, through an old vulnerability, a phished login or a reused password, those weak hashes could be cracked offline at leisure.

Researchers still haven’t confirmed exactly how those configuration files were obtained. Older, previously patched Fortinet vulnerabilities may have played a role for some devices, which is one more reason an old exposure can keep causing damage long after the patch is installed.

Why “Not a Vulnerability” Is Actually Worse News

When a normal vulnerability makes headlines, the fix is clear: install the patch. FortiBleed doesn’t work that way. As Censys put it, there is no single patch for FortiBleed because the issue is credential exposure, not a product flaw.

That creates a dangerous blind spot. A business can have a firewall running the very latest firmware and still be wide open if the admin password was reused from another system, never changed from what an installer set years ago, or exposed in an earlier breach. Vulnerability scanners check software versions against known flaws. They don’t check whether the password protecting the device is already sitting in a criminal’s database.

In other words, “we’re patched” and “we’re secure” are not the same statement.

Why Firewalls Are Such a Valuable Target

A firewall sits at the edge of your network, deciding what gets in and what stays out. It’s often trusted implicitly by everything behind it, and it’s frequently monitored less closely than laptops and servers. For an attacker, logging in to the firewall with valid credentials is close to ideal.

From there, they can create their own VPN accounts, change firewall rules, turn off logging or security features, and move into the internal network looking for servers and data. Because they’re using real credentials, the activity can look like ordinary administrator work. Locking the actual IT team out of the device, as the FBI has observed, buys time to deploy ransomware before anyone can respond.

How Small Businesses End Up Exposed

The pattern behind FortiBleed is painfully familiar in small and mid-sized businesses:

  • The firewall was installed years ago by a vendor or former IT person, and the admin password was never changed
  • The same admin password is used across multiple sites, devices or systems
  • The management login page is reachable from the internet “for convenience”
  • Remote VPN access works with just a username and password, with no multi-factor authentication
  • VPN accounts for former employees or contractors were never removed
  • The device’s configuration still uses older, weaker password storage settings

None of these feel urgent on a normal day. Together, they’re exactly what FortiBleed exploited.

What To Do Now

  1. Check whether you were exposed. Hudson Rock offers a public lookup for FortiBleed exposure, referenced in the Censys advisory.
  2. Rotate every admin and VPN password on your firewall, and terminate any active sessions so stolen logins are cut off immediately.
  3. Require multi-factor authentication on VPN access and administrative logins, so a password alone is never enough.
  4. Take the management interface off the internet. Restrict admin access to trusted internal networks or a dedicated management path.
  5. Update the firmware and modernize password storage. Fortinet recommends current supported FortiOS releases and stronger PBKDF2-based password hashing for admin accounts.
  6. Remove stale accounts for former staff, contractors and vendors.
  7. Review logs and configuration for unfamiliar admin accounts, new VPN users or rule changes nobody remembers making.

The Lesson Applies to Every Brand

FortiBleed happened to involve Fortinet, but the underlying weakness isn’t unique to one vendor. Any firewall, VPN gateway or remote access appliance with a reused password, an internet-facing admin page and no MFA carries the same risk. Security researchers increasingly rank edge devices like firewalls, VPNs and gateways as some of the highest-risk assets an organization owns. If you run SonicWall, Cisco, Palo Alto, WatchGuard or anything else at your network edge, the checklist above applies just as much.

FortiBleed Questions

Is FortiBleed a Fortinet vulnerability?

Not a new one. Fortinet states it is not a newly disclosed product vulnerability. It’s a large-scale credential exposure built from reused, stolen and cracked passwords for FortiGate firewalls and VPNs, although some of the underlying data may trace back to devices compromised through older, already-patched flaws.

Will a firmware update protect me from FortiBleed?

Updating is still important, but it doesn’t invalidate passwords that have already been exposed. Rotating credentials and enforcing MFA are what actually close the door.

Does this matter if we don’t use Fortinet?

Yes. The same weaknesses, reused passwords, internet-facing admin pages and VPNs without MFA, put any firewall or remote access device at risk.

The Takeaway

FortiBleed is a reminder that some of the most damaging attacks don’t require a clever exploit at all. They just require a password that should have been changed, a login page that shouldn’t have been public, and a VPN that trusted a password on its own. The fix isn’t complicated: rotate credentials, require MFA, and get your firewall’s management page off the internet. The hard part is making sure someone actually does it.

Cloud9 Tech Solutions builds these protections into the security stack and network management we provide, aligned with the Zero Trust approach we bring to every environment.

If you’re not sure when your firewall’s admin password was last changed, or whether your VPN requires MFA, that’s worth finding out now. Schedule a free security assessment with Cloud9.