FortiBleed FortiGate credential leak: response guide

In June 2026, credentials associated with tens of thousands of FortiGate firewalls and VPN gateways appeared in a leaked dataset. The campaign became known as FortiBleed, and alerts were issued by Fortinet, the UK’s NCSC, Singapore’s CSA and Poland’s CSIRT NASK.

The Cyber Security Agency of Singapore said the dataset covered credentials linked to more than 70,000 FortiGate devices worldwide. That is a serious exposure signal, but not proof that every listed device was successfully compromised or that every password remains valid.

Fortinet’s most important clarification is explicit: this is not a new product vulnerability or new advisory. Its initial analysis connects reused historical data with brute force and credential stuffing against devices with weak password hygiene and no MFA.

What is confirmed

On 18 June, the UK NCSC described global targeting of internet-accessible Fortinet firewalls and VPN portals. The credential collection followed brute-force, dictionary and credential-stuffing attempts.

CSIRT NASK recommended account audits, alert review, removal of web and SSH management from the internet, MFA and external event logging. Organisations should not wait for individual confirmation from the vendor before checking exposure and unauthorised changes.

How an attack works without a new CVE

Credential stuffing tests credentials stolen from another service. Brute-force and dictionary attacks try common or predictable combinations. A successful login can look legitimate to the appliance because the attacker uses the normal interface with a valid password.

If MFA is absent and management access is not restricted by source, current firmware alone cannot stop that login. Patch management remains necessary, but identity, unique passwords, access configuration and monitoring are the key controls in this incident.

Why a FortiGate takeover is high impact

A firewall and VPN gateway sit at the network boundary. Administrative access can change policies, create users, inspect configuration and prepare movement into internal systems. A VPN account can provide a direct foothold for reconnaissance and lateral movement.

Assume that credentials and secrets visible in appliance configuration may be exposed after confirmed administrative compromise. Response must extend to dependent systems, directory authentication and remote-access activity.

Immediate response checklist

1. Preserve evidence first. Export logs, configuration, account lists, session state and relevant network telemetry before destructive recovery.
2. End active sessions and rotate credentials. Reset all administrator and VPN passwords on internet-exposed devices, and invalidate shared secrets used elsewhere.
3. Enforce MFA. Cover privileged accounts and VPN users, not only ordinary staff. See our MFA deployment guide.
4. Compare configuration with a known-good backup. Look for unknown users, routes, policies, VPN changes and support-like names such as fortinet-support.
5. Review device and directory logs. Investigate unusual administrative sources, password resets, account creation and later movement in Active Directory.
6. Remove management from the public internet. Use trusted hosts, local-in policy or internal-only administration.
7. Update using the official upgrade path. Fortinet recommends current supported FortiOS releases and stronger PBKDF2-based credential storage where applicable.
8. Rebuild when compromise is confirmed. After preserving evidence, a factory reset and restoration from verified configuration may be safer than deleting individual traces.

Changing a password is not enough if the attacker created persistence or stole reusable secrets. Apply a complete incident-response process.

What should not be inferred

FortiBleed is not the name of a new zero-day and does not establish a breach of Fortinet’s network. The 70,000-plus figure refers to records or devices represented in the dataset, not 70,000 independently verified full compromises. Some entries may originate from older incidents or unsuccessful guessing.

That uncertainty is not a reason for inaction. An exposed management panel, missing MFA, reused password or appearance in the dataset warrants urgent investigation. Correctly identifying the event as credential compromise leads to the right controls: rotation, session invalidation, access restriction, MFA, configuration review and lateral-movement analysis.

---

Sources: Fortinet PSIRT, UK NCSC alert, CSA advisory, CSIRT NASK recommendations.