FortiBleed Is a VPN Story, Not Just a Fortinet Story
On June 18, 2026, Fortinet said it was seeing a credential-compromise campaign against internet-facing FortiGate devices, where attackers were focusing on exposed VPN and firewall services to obtain valid access. In simple terms, this was not a single isolated break-in; it was a broader attempt to exploit weak, reused, or exposed credentials at the network edge. The fact that Fortinet made this public also reflects the kind of transparency and professionalism you expect from serious cybersecurity companies, which is exactly how responsible vendors handle incidents like this.
The FortiBleed campaign is a reminder that the edge of the network is often the most dangerous place in the environment. When a firewall or SSL VPN gateway sits on the internet, it is no longer just a convenience for remote access; it becomes a frontline identity and trust system that adversaries will probe, harvest, and reuse.
Why This Incident Matters to Organizations That Were not Directly Affected
What makes this campaign important is not only the scale of the credential theft, but the fact that it exposes a persistent weakness in how organizations think about VPN security. Too many teams still treat a VPN as though encryption alone is enough. In practice, the real problem is everything that surrounds the tunnel: passwords, exposed management services, device hygiene, logging, session control, and the discipline to respond quickly when something looks wrong.
That is why this incident matters even to organizations that were not directly affected. It reinforces a simple truth: if a VPN gateway is internet-facing, it must be treated like a high-value asset, not a background utility.
The first lesson is that credential theft campaigns work because valid access is often easier to use than a fresh exploit. Fortinet’s own analysis says the activity involved reused credentials from previous incidents, combined with brute-force, dictionary, and credential-stuffing attempts against devices with weak password hygiene and no MFA. That is not a niche problem; it is a familiar one, and that is exactly why it keeps succeeding.
At a technical level, the threat model here is straightforward but dangerous. A FortiGate exposed to the public internet with SSL VPN enabled gives an attacker a reachable authentication surface, a potentially enumerable set of usernames, and, in some cases, a path to device-adjacent artifacts that reveal enough about the environment to accelerate compromise. If the operator can collect valid credentials, session tokens, or hashed secrets, the firewall stops being a boundary device and becomes a launchpad.
That is what makes these campaigns different from noisy opportunistic scanning. The initial access phase may begin with brute force or credential stuffing, but the objective is persistence and reuse. Once valid access is established, the attacker may be able to test internal routing, enumerate administrative capabilities, extract configuration details, alter policy, or pivot through trusted paths that normal users never see. This is why perimeter compromise is rarely a single-event problem.
The NCSC guidance is especially useful because it treats the device as an incident platform, not just a login point. It recommends checking for unauthorized account creation, abnormal log activity, unexplained configuration changes, gaps in event history, suspicious outbound traffic, and signs that configuration files may have been copied. Those are exactly the kinds of artifacts a competent defender should expect to find if the firewall or VPN gateway has been touched by a credential-theft actor.
Changing Passwords Alone may not be Sufficient
A key point here is that changing passwords alone may not be sufficient. If a threat actor has established persistence, rotated credentials may simply close one door while leaving another one open. That is why the recommended response includes isolating the device from the internet and internal network if compromise is suspected, collecting logs and configuration evidence before anything is destroyed, and factory resetting the appliance when persistence cannot be ruled out.
From a defensive architecture perspective, the lesson is not simply “use MFA.” It is broader and more operationally demanding than that. MFA should be enforced on all VPN and administrative logins, but it should be paired with strong password policy, unique credentials, minimized external exposure, and a clean separation between user access and device administration. If administrators can manage the firewall from the same network path used for remote employees, the organization is compressing two very different trust levels into one attack surface.
The same logic applies to shared credentials. If the same password is reused across edge devices, administrative portals, or support accounts, then compromise of one perimeter system can become compromise of several. The NCSC specifically calls out investigating other edge devices that share credentials with the affected system, and that recommendation should be read as a warning about the fragility of operational shortcuts.
There is also a larger point about device lifecycle. Unsupported edge systems are particularly dangerous because they sit in the most exposed part of the network while receiving the least favorable maintenance posture. If an internet-facing VPN appliance is out of support, running obsolete firmware, or relying on legacy hashing mechanisms for administrator accounts, the organization is effectively asking a modern attacker to exploit old assumptions. Fortinet’s guidance emphasizes updating to the latest supported version, removing out-of-support systems, and enabling PBKDF2 for administrator credential storage.
That last control matters more than it may appear at first glance. PBKDF2 does not make a device invulnerable, but it raises the cost of offline password cracking if credential material is stolen. In campaigns like FortiBleed, where the compromise is not necessarily a single CVE but rather a combination of exposed portals, weak secrets, and large-scale credential abuse, the strength of stored password hashes becomes part of the security boundary.
Another lesson is that logging has to be useful, not ceremonial. A firewall that logs only minimally, or that stores logs too briefly to support investigation, will not help much when something goes wrong. Security teams need enough telemetry to reconstruct who authenticated, from where, whether MFA was used, whether a configuration file was exported, whether admin rights changed, and whether traffic patterns shifted after the initial login. If you cannot answer those questions quickly, the device is too important to be operating blind.
This is why I would frame FortiBleed as an identity incident as much as a network incident. The firewall is not just filtering packets; it is asserting trust. Once that trust is abused, the impact can reach authentication systems, internal routing, management planes, and downstream services that assume the perimeter is behaving honestly. The better mental model is not “our VPN was attacked,” but “our trust boundary was tested and may have been repurposed.”
How Can Organizations Get Ahead of the Problem
For organizations that want to get ahead of the problem, the practical sequence is clear. First, inventory every Fortinet edge device and confirm whether any management interface is publicly reachable. Second, enforce MFA on all administrative and VPN access, including any privileged service workflows that touch the appliance. Third, review logs for unauthorized accounts, suspicious logins, configuration changes, unexplained egress, and signs of credential reuse. Fourth, compare the live configuration against a known-good baseline and validate firmware and support status. Fifth, if compromise is suspected, isolate first, preserve evidence, and then decide whether reimaging or factory reset is required.
Organizations should also review segmentation beyond the edge. If a compromised VPN account can reach the entire internal network, then the VPN is not truly granting remote access; it is granting broad internal reach. That design is convenient, but it is risky. Strong segmentation, least privilege, device posture checks, and tighter internal access policies reduce the blast radius when credentials inevitably fail.
From an incident response standpoint, the most important shift is to stop treating edge devices as “set and forget” infrastructure. They are live, stateful, identity-rich systems that deserve the same scrutiny you would give a domain controller, an IAM provider, or a privileged cloud control plane. When they fail, they fail at the point where trust is concentrated.
In my view, the message is not that VPNs are broken because, if fact, and in details, they are. It is that a VPN is only as strong as the identity controls, logging discipline, administrative hygiene, and lifecycle management around it. If the gateway is exposed, the credentials are weak, and the telemetry is thin, the organization is gambling with the one place where it can least afford uncertainty.
That is why this belongs in the category of strategic security, not vendor-specific commentary. FortiBleed is a reminder that remote access is now one of the most contested parts of the enterprise, and the organizations that treat it accordingly will be the ones that recover fastest and suffer less when the next campaign arrives.
References
Fortinet. (2026, June 18). Analysis of reported credential compromise of FortiGate devices. Fortinet PSIRT. https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices
National Cyber Security Centre. (2026, June 18). Alert: NCSC issues advice following global targeting of Fortinet firewalls and VPN gateways. UK NCSC. https://www.ncsc.gov.uk/news/advice-following-global-targeting-of-fortinet-firewalls-and-vpn-gateways
National Cyber Security Centre. (2026, June 18). NCSC Advisory: Global Targeting of Fortinet Firewalls and VPN Gateways. PDF. https://www.ncsc.gov.ie/pdfs/Fortinet-Fortibleed-180626.pdf
Noguerol, L. O. (2026). VPN Insecurity Compendium: Essential Techniques. Amazon. https://www.amazon.com/VPN-Insecurity-Compendium-Essential-Techniques/dp/B0G3J1WGBY
Share this
You May Also Like
These Related Stories

5 Key Cybersecurity Statistics for 2025

Deepfakes, Fraud, and Identity: What CISOs Are Saying Behind Closed Doors


