[HIGH] | No patch available | Active credential abuse confirmed | Act on mitigations now

TL;DR

FortiBleed is an active credential-exposure campaign targeting internet-facing Fortinet FortiGate firewalls and FortiOS SSL VPN gateways (the remote-access endpoints that allow employees to connect to the corporate network from outside).

As of June 19, 2026, confirmed credentials from roughly 86,644 unique devices across 194 countries had been harvested, representing approximately half of all internet-facing Fortinet firewalls, and there is no patch that closes this exposure.

Restrict management interface and VPN exposure from the public internet now, rotate all administrator and VPN credentials, and enforce multi-factor authentication on every admin and VPN account. Bitdefender MDR monitors for FortiBleed behavioral indicators, including anomalous authentication and configuration export events; GravityZone EASM identifies internet-exposed management surfaces before attackers find them. For exact remediation steps, including how to identify affected systems and assess for prior compromise, see What To Do below.
NOTE: This campaign does not exploit a software vulnerability: there is no patch that closes it.

Advisory History

June 22, 2026: Fortinet published its formal response to FortiBleed activity, referencing internal advisories FG-IR-26-060 and FG-IR-25-647 and characterizing the activity as credential reuse from prior incidents combined with brute force against devices lacking strong password hygiene and MFA. Advisory published on this date as the primary publication trigger.

June 19, 2026: SpyCloud issued research on the attacker methods, tools, and tactics, with assessments on affected devices, victim profiles, and other useful context about the FortiBleed threat.

June 18, 2026: CISA issued a hardening alert urging organizations to restrict access to the Fortinet management interface and rotate credentials. CISA Fortinet hardening alert, June 2026.

June 13, 2026: Researcher Volodymyr “Bob” Diachenko publicly disclosed an exposed threat-actor server containing a validated database of FortiGate administrator and VPN credentials. Analysis by Kevin Beaumont in collaboration with Hudson Rock followed shortly after. As a result of the work with Hudson Rock, a searchable database was built for potential victims of domain exposures: https://www.hudsonrock.com/fortinet

The FortiBleed Situation

On or around June 13, 2026, security researcher Volodymyr “Bob” Diachenko publicly disclosed an exposed threat-actor server hosting a growing, validated database of FortiGate administrator and VPN credentials, revealing a credential harvesting campaign already operating at scale. Security researcher Kevin Beaumont published a follow-up technical analysis in collaboration with Hudson Rock: Kevin Beaumont, “An Update on FortiBleed”, June 2026.

By June 19, 2026, the confirmed device count had reached approximately 86,644 unique devices across 194 countries, representing roughly half of all internet-facing Fortinet firewalls. CISA Fortinet hardening alert, June 2026.

Fortinet responded on June 22, 2026, referencing two internal advisories: FG-IR-26-060 and FG-IR-25-647. Fortinet’s position is that the activity involves credential reuse from prior incidents plus brute force against devices with weak password hygiene and no MFA and is “not related to any recent incident or advisory.”

Active credential abuse at a documented scale is confirmed. NOTE: This campaign does not exploit a software vulnerability: there is no patch that closes it.

How It’s Exploited

FortiBleed is more dangerous than a typical critical CVE because there is nothing to patch. A credential campaign targeting half the internet-facing Fortinet fleet does not trigger exploit signatures, does not deploy malware at the entry point, and does not announce itself in any way that a perimeter block can detect.

The credentials are valid. The usernames are correct. The logins look legitimate because they are legitimate. Any remediation strategy built around waiting for the vendor to ship a software fix will fail here: the attack surface is access, not software, and access cannot be patched away.

The campaign targets FortiGate devices with management interfaces or SSL VPN endpoints directly reachable from the public internet. An SSL VPN gateway is a remote-access service built into FortiGate firewalls that allows employees to connect securely to the corporate network from outside; any such endpoint exposed to the internet is an entry point for this campaign. The attacker scans for exposed devices, exfiltrates device configuration files containing stored password hashes, and cracks those hashes offline, recovering administrator and VPN user credentials without any further interaction with the target. The technical details of each stage are in How it Works below.

The most consequential element of this campaign is what comes next. Once a device is compromised, it does not simply become a victim. The attacker turns it into a listening post that intercepts credentials from legitimate VPN users whose traffic passes through it, feeding those credentials back into the scanning infrastructure to extend the campaign’s reach without requiring additional targeting effort. The campaign is self-amplifying. Each compromised device is simultaneously a victim and a recruitment node for the next wave of targets.

This is the structural reason why FortiBleed is harder to contain than a CVE with a known patch. A software vulnerability gives defenders a defined scope (unpatched versions) and a remediation deadline (the patch release date). A validated credential database gives attackers a persistent login window that survives any software update, because the credentials remain valid until each one is individually rotated.

An organization that patches every CVE in their Fortinet environment this week but does not also rotate all credentials and enforce MFA remains exposed. The patch window is bounded; the credential window is not, unless the organization closes it deliberately.

Exposure conditions: Your organization is in scope if you operate a FortiGate with its management interface or SSL VPN endpoint reachable directly from the public internet, and if administrator or local VPN user passwords were stored as legacy salted SHA-256 hashes. SHA-256 and PBKDF2 are two different methods for storing passwords securely: SHA-256 is an older, faster method that a well-equipped attacker can crack offline in practical time, while PBKDF2 is a slower method designed specifically to resist that offline cracking.

The SHA-256 exposure applies to any administrator who has not logged in after upgrading to FortiOS (Fortinet’s network operating system that runs on FortiGate appliances) builds 7.2.11, 7.4.8, or 7.6.1, which are the first builds to support PBKDF2 for new logins. Devices without MFA on administrator or VPN accounts face the highest ongoing exposure, even after credentials are rotated, because a reused credential has no second factor to block it.

Limiting factors: Organizations that already restrict management interface access to internal IP ranges, trusted jump hosts, or VPN-only access are largely outside the initial harvest scope. Organizations with MFA enforced on all administrator and VPN accounts have meaningful protection against credential reuse even if their credentials appear in the dataset. The PBKDF2 hash weakness resolves individually for each administrator upon their first post-upgrade login, rather than for all accounts at once when the upgrade completes.

Amplifying factors: The self-amplifying mechanism extends attacker reach without proportional attacker investment. Offline cracking of SHA-256 hashes is accessible to operators with dedicated hardware, and the barrier to that capability has been lowering steadily as cracking infrastructure becomes a commodity. The dataset is partly seeded by prior-incident credential reuse and by fresh harvests, meaning organizations that believed earlier incidents were fully resolved may still be exposed. Scale already at roughly half of the internet-facing Fortinet fleet as of June 19, 2026, and still climbing. Shadow or forgotten appliances (devices absent from internal software inventory) are invisible to agent-based scanning but fully visible to the attacker’s internet-wide scanner.

Confidence level: Confirmed playbook. Active exploitation is documented at scale. Organizations that have already restricted management exposure and enforced MFA face meaningfully lower realistic risk, and this advisory does not apply uniform alarm where those controls are in place.

If you have confirmed exposure, skip ahead to What To Do.

How It Works

Configuration exfiltration: The campaign begins with internet-wide scanning to identify FortiGate devices with publicly reachable management interfaces or SSL VPN endpoints. Once a device is located, the attacker requests or exfiltrates the device configuration file. This file, designed for backup and migration purposes, contains hashed representations of administrator and local user passwords alongside the full device configuration. Configuration file exports to external IP addresses have been documented as part of victim compromise investigations, serving as a behavioral detection opportunity for organizations reviewing FortiGate audit logs.

Offline credential cracking: The exfiltrated configuration file is processed against dedicated offline cracking infrastructure. According to a blog from SpyCloud, “The actors also rented GPU horsepower by-the-hour to crack passwords,” reportedly up to 45 GPUs at one point; however, this number has yet to be independently confirmed.

The attack targets legacy salted SHA-256 password hashes. Devices upgraded to FortiOS 7.2.11, 7.4.8, or 7.6.1 begin storing new passwords as PBKDF2 hashes, but existing administrator passwords remain stored as SHA-256 hashes until each individual administrator next authenticates post-upgrade.

A further complication: those FortiOS builds retain the original SHA-256 hash in a hidden “old-password” setting for backward compatibility. This setting persists alongside the new PBKDF2 hash until it is explicitly purged. The upgrade alone does not eliminate the crackable hash; it requires both the upgrade and a subsequent per-administrator login, followed by enabling the login-lockout-upon-weaker-encryption setting on 7.2.x and 7.4.x to fully remove the SHA-256 material.

Credential reuse and listening post deployment: With recovered credentials, the attacker authenticates to the FortiGate as a legitimate administrator. There is no exploit payload, no shellcode, no file dropped to disk. Authentication succeeds because the credentials are correct. From that administrative position, the attacker configures the device as a passive listening post to capture credentials from VPN traffic passing through it. Those harvested credentials re-enter the scanning infrastructure, extending the campaign without requiring a new targeting effort from the attacker.

Related prior CVEs: Three CVEs describe authentication weaknesses in FortiCloud SSO (the single-sign-on service Fortinet provides for cloud-managed devices) that enabled earlier credential capture from these devices and contributed to the prior-incident seeding Fortinet acknowledges:

• CVE-2026-24858 (patched January 2026)
• CVE-2025-59718 (patched December 2025)
• CVE-2025-59719 (patched December 2025)

These CVEs describe authentication-layer weaknesses, not the configuration-exfiltration mechanism driving the current campaign. Unpatched devices running affected builds should be updated, but patching these CVEs alone does not close the credential exposure. The access broker likely associated with this breach, SantaAd, has been known to target Fortinet and other firewalls or VPN and would likely have some familiarity with previous vulnerabilities.

What To Do

The steps below expand on the immediate actions summarized in the TL;DR.

1. Identify Exposure

Determine whether your FortiGate management interface or SSL VPN endpoint is reachable from the public internet. From an external network position, or via a service that simulates an external view, attempt to reach the FortiGate administration login and VPN portal. If either surface responds from an untrusted external IP address, you are in scope and should proceed immediately to step 2.

Audit your software inventory for all FortiGate and FortiOS versions in your environment. Identify any devices running builds older than 7.2.11, 7.4.8, or 7.6.1: those devices store all passwords as SHA-256 hashes with no path to PBKDF2 migration without upgrading first.

2. Patch or Mitigate

Immediate actions (perform now, regardless of patch status):

• Restrict management interface and SSL VPN access to internal IP ranges, trusted jump hosts, or VPN-only access. Remove direct public internet reachability for both surfaces. This is the single highest-impact mitigation available and takes effect before any software update.
• Rotate all administrator, local user, and SSL VPN credentials immediately. Do not wait until after patching. Treat credentials on any internet-facing FortiGate as potentially compromised.
• Enforce MFA on all administrator and VPN accounts. If MFA is not currently enforced, enable it now as a priority alongside credential rotation.

Software update and hash migration (perform after immediate actions):

• Upgrade to FortiOS 7.2.11, 7.4.8, or 7.6.1 or later to enable PBKDF2 hashing for new authentications.
• After upgrading, each administrator must log in to the device to replace their individual legacy SHA-256 hash with a PBKDF2 hash. The upgrade alone does not replace existing hashes.
• On FortiOS 7.2.x and 7.4.x, enable the login-lockout-upon-weaker-encryption setting to fully purge remaining SHA-256 hashes after each administrator has completed their post-upgrade login.

Reference Fortinet’s advisories FG-IR-26-060 and FG-IR-25-647 for official guidance. The CISA Fortinet hardening alert, June 2026 provides supplementary guidance consistent with these steps.

3. Assess for Prior Compromise

Review available FortiGate logs for the following indicators. The absence of matching entries does not confirm no compromise occurred, as compromised devices may have had logging configuration modified. Presence of any of these is a strong signal requiring immediate investigation:

• Configuration file export events with an external destination IP address
• Administrator authentication from geographic locations or IP ranges outside your normal management access patterns
• New administrator accounts created outside normal provisioning workflows
• Changes to logging configuration, authentication settings, or interface permissions outside documented change control windows
• Outbound connections from the device to unrecognized external IP addresses, particularly persistent or recurring tunneling traffic
• SSL VPN authentication events for known users from unexpected geographic locations or at unexpected times

4. Establish Ongoing Monitoring

After completing credential rotation and exposure restriction, establish ongoing monitoring for:

• Administrator authentication attempts from any external IP address not in your approved management access list
• VPN authentication events showing geographic impossibility (the same user account authenticating from two widely separated locations within a window that does not allow for travel)
• Configuration change events in the FortiGate audit log, particularly to authentication settings, logging configuration, and interface permissions

Indicators of Compromise

No Bitdefender-proprietary IOC set is available for this cycle. If Bitdefender Labs publishes FortiBleed-related indicators, they will appear at the Bitdefender malware-ioc repository on GitHub. As of 22 June 2026, there are no known published indicators; however, various types of exploit scans targeted against edge network devices such as firewalls or VPN, or SQL servers and network storage devices, may have been apparent as far back as May 2026, followed by brute force attempts and/or successful logins. Bitdefender is continuing to monitor telemetry and intelligence reporting.

For current attacker infrastructure indicators from government and primary vendor sources, see the CISA Fortinet hardening alert, June 2026 and Fortinet advisories FG-IR-26-060 and FG-IR-25-647.

GravityZone Coverage

Bitdefender MDR

Bitdefender Managed Detection and Response (MDR) provides 24/7 threat monitoring and active response. For FortiBleed, the detection problem is precisely that the abuse resembles legitimate administrative activity: valid credentials, valid usernames, successful authentication. There is no exploit code to intercept at the perimeter and no malware signature to match at the door. Detection requires behavioral analysis of authentication patterns and configuration activity, not file scanning.

Bitdefender MDR is monitoring for FortiBleed behavioral indicators, including anomalous administrator authentication patterns, configuration export events to external destinations, and VPN authentication anomalies consistent with credential reuse from unexpected origins. Bitdefender Labs is continuing to investigate known and emerging threats from this campaign and will update signatures as needed.

MDR uses software inventory data from GravityZone to scope hunting campaigns. Customers with FortiGate devices in their environment should verify that those devices appear in their GravityZone software inventory to allow MDR to include them in the targeted threat hunt scope.

EASM (External Attack Surface Management)

GravityZone External Attack Surface Management (EASM) identifies internet-exposed assets from outside the network perimeter, without requiring an agent installed on the device. EASM sees a FortiGate management interface or SSL VPN endpoint exactly as the FortiBleed scanner sees it: as a service reachable from the public internet, regardless of whether that device appears in internal software inventory.

EASM is the prevention story for FortiBleed. The campaign begins with internet-wide scanning for exposed management surfaces. An organization that does not know one of its FortiGate devices is internet-reachable cannot restrict that exposure. EASM provides the external attacker-perspective view, including shadow or forgotten appliances that no endpoint agent covers.

EASM is distinct from GravityZone Risk Management: EASM is external and agentless, identifying exposure from outside the network perimeter; Risk Management is internal and agent-based, identifying vulnerabilities on managed endpoints already within the environment. For FortiBleed, EASM addresses the upstream exposure question; Risk Management addresses the patch posture of related CVEs on managed endpoints where FortiClient or related Fortinet software is installed.

GravityZone Risk Management

GravityZone Risk Management provides agent-based scanning of managed endpoints to identify unpatched software versions. This is a supporting capability for the patch-posture dimension of FortiBleed response; it does not scan network appliances directly, which is the role of EASM.

Detection Capabilities

Behavioral abuse patterns following successful FortiBleed credential reuse, including lateral movement using valid administrator credentials, anomalous internal network authentication, and post-access configuration modification, fall within the detection scope of GravityZone EDR and Advanced Threat Control (ATC) where endpoint telemetry is available from systems within the environment targeted by compromised FortiGate credentials.