FortiBleed: Thousands of FortiGate Credentials Circulating on Criminal Forums

A credential harvesting operation known as FortiBleed has surfaced on the Exploit.in cybercrime forum, with a threat actor selling thousands of valid Fortinet FortiGate VPN credentials. The listings appeared over the past week, with the same actor posting two separate batches: 6,355 valid accesses priced at $7,000 and a second batch of 1,115 valid accesses at $5,000. Individual credential sales are also on offer. The targeted organisations span revenue ranges from $1 million to $200 billion, suggesting a broad, indiscriminate harvest rather than targeted selection.

If your organisation uses Fortinet FortiGate VPN appliances, you should treat this as an active threat and take action now.

What FortiBleed is

FortiBleed is the name given to a large-scale credential harvesting campaign targeting FortiGate SSL-VPN appliances. The operation exploits known vulnerabilities in Fortinet's FortiOS to extract session tokens and plaintext credentials from unpatched or inadequately hardened devices — a technique with a long history against Fortinet products. The resulting credentials are pre-validated and sold as ready-to-use network access, meaning buyers do not need to conduct any exploitation themselves. They purchase a working set of credentials and walk straight into your network.

This is not a novel attack class. Fortinet appliances have been a persistent target due to their prevalence at network perimeters and the frequency with which critical vulnerabilities have been disclosed and exploited before organisations have patched. The FortiBleed operation follows a well-established playbook: harvest credentials at scale from exposed, vulnerable devices, validate them, and monetise access on criminal forums.

Where it came from

FortiGate devices have been subject to a series of critical vulnerabilities over recent years that, when left unpatched, allow unauthenticated attackers to read files from the device's filesystem — including files containing session tokens and credentials for active VPN sessions. Prominent among these are path traversal vulnerabilities in the SSL-VPN interface that allow directory traversal outside the web root, as well as authentication bypass and heap overflow vulnerabilities that have been assigned CVSSv3 scores of 9.8 (critical).

The FortiBleed campaign appears to have harvested credentials from devices left exposed to the internet without timely patching applied. Fortinet has issued advisories for multiple critical vulnerabilities across FortiOS versions, and guidance has consistently recommended immediate patching and credential rotation after any period of exposure. Many organisations do not act on that guidance promptly — and this is the result.

The credentials now being sold were validated before listing. The forum post explicitly states "VALID ACCESS" and targets organisations by revenue, which suggests the operator ran automated validation against live targets. You cannot assume that because your credentials are old, or because you have since patched, that the harvested credentials are no longer valid. If your FortiGate was exposed during a vulnerable period and credentials were not rotated, those credentials may be in this dataset.

What was seen on Exploit.in

The following screenshots were taken from the Exploit.in forum and show the two credential batches being offered for sale. Both posts originate from the same threat actor account, which joined on 19 June 2026 and lists activity under "hacking." The use of escrow and a TOX messaging address are consistent with a criminal operation conducting high-value access sales.

Who is affected

Any organisation that uses Fortinet FortiGate appliances for SSL-VPN or remote access, and that has not applied all critical security patches and rotated credentials following disclosure, should consider themselves potentially exposed. The dataset spans organisations globally and across all revenue bands. There is no sector or geography-specific targeting — this is volume harvesting.

Credentials sold in this manner are typically purchased by initial access brokers or ransomware affiliates who use them to establish a foothold in the target network. From that point, the playbook is well understood: privilege escalation, lateral movement, data exfiltration, and in many cases ransomware deployment weeks later. The window between credential sale and downstream exploitation can be very short.

Check whether your credentials are in the breach

SOCRadar provides a free credential check tool that allows you to query whether your organisation's credentials appear in known breach datasets, including FortiBleed. Check your exposure at:

https://socradar.io/free-tools/fortibleed

Use this to assess whether your organisation's credentials are in circulation. A clean result here does not guarantee safety — datasets may not be fully indexed — but a positive result should be treated as a confirmed incident requiring immediate response.

What to do now

The remediation steps are not complicated, but they need to happen quickly. Priority actions for any organisation running FortiGate devices:

• Patch immediately. Apply all current Fortinet security advisories to every FortiGate device. Focus first on devices with SSL-VPN interfaces exposed to the internet. Check Fortinet's PSIRT advisory page for all current critical and high-severity advisories and apply them without delay.
• Rotate all VPN credentials. Force a password reset for every account with FortiGate VPN access. Do not wait to determine whether specific accounts are in the breach — rotate everything. Session tokens should also be invalidated by restarting the SSL-VPN service after patching.
• Revoke and reissue certificates and API keys. If your FortiGate configuration includes API tokens or certificates used for automation or third-party integrations, treat these as compromised and rotate them.
• Enable multi-factor authentication. If MFA is not already enforced for all VPN users, implement it immediately. Valid credentials alone should not be sufficient for network access. This is the single most effective control for reducing the impact of credential exposure.
• Review authentication logs for anomalous access. Look for successful VPN logins from unusual IP addresses, at unusual times, or for accounts that do not typically use remote access. Pay particular attention to the period since the vulnerabilities were first disclosed. Treat any unexplained successful authentication as a potential indicator of compromise.
• Audit administrative access. Remove any unnecessary administrative accounts, confirm that admin access to the FortiGate management interface is not exposed to the internet, and verify that firewall policies have not been modified without authorisation.
• Engage your incident response capability. If log review indicates any successful access that cannot be accounted for, treat this as a confirmed breach and initiate your incident response process. Do not attempt to assess the scope of compromise without preserving forensic evidence first.

Longer-term posture

This incident is part of a consistent pattern. FortiGate appliances have been exploited at scale in 2019, 2022, 2023, 2024, and now again in 2026. Each time, the root cause is the same: critical vulnerabilities in internet-facing appliances that were not patched before being exploited. The credentials or access sold in each wave come from organisations that applied patches too slowly.

The appropriate long-term response is not a one-off remediation but a change to how your organisation handles vulnerability management for network perimeter devices. Critical vulnerabilities on internet-facing appliances should be patched within 24 to 48 hours of disclosure. If your current patching process cannot achieve that, the process needs to change — or you need a managed service that maintains patch currency on your behalf.

Zero-trust network access architecture removes the class of risk entirely. When there is no internet-facing SSL-VPN to exploit, credential harvesting from that attack surface is not possible. If your organisation is still dependent on a traditional VPN perimeter model, now is a good time to consider whether that should change.