The dangerous part of a firewall credential leak is not the password itself. It is where that password works. On an internet-facing FortiGate, a valid administrator or VPN credential can turn the perimeter device into an attacker-controlled access point—and a patch alone does not revoke it.

SOCRadar’s report calls the campaign FortiBleed and says it collected and validated FortiGate and SSL-VPN credentials at large scale. Fortinet has since acknowledged the campaign in a PSIRT blog, saying its initial analysis indicates that threat actors reused credentials from previous incidents and used brute-force techniques against devices with weak password hygiene and no MFA. Fortinet also says it identified potentially compromised systems and is contacting affected customers. The reported scale, infrastructure links, and Russian-speaking attribution remain findings from the researchers and subsequent reporting, rather than claims Fortinet makes in its PSIRT analysis.

TL;DR

  • Treat a positive exposure result as a potential compromise, not merely a password-reset task.
  • Fortinet says a recent campaign it investigated used exposed management interfaces, weak single-factor credentials, and password spraying—not a new FortiGate vulnerability.
  • SOCRadar’s subsequent research describes a post-compromise credential-collection stage: a custom tool uses FortiOS packet-capture diagnostics to collect authentication material crossing a compromised firewall.
  • Remove administrative access from public interfaces where possible; otherwise use trusted hosts or a local-in policy, enforce MFA, and rotate every credential that can authenticate to the appliance.
  • Preserve and export logs before changing configuration. Hunt for new administrators, VPN users, scheduled scripts, suspicious logins, and follow-on identity abuse.

What Fortinet confirms—and what remains reported

Fortinet confirms that FortiBleed is a credential-harvesting campaign against Fortinet devices. It says the activity is not a new Fortinet vulnerability and is not connected to a recent advisory; the company’s initial assessment points to credential reuse from previous incidents and brute-force activity against weak, non-MFA-protected accounts. Fortinet’s June 19 PSIRT analysis is the primary source for these points.

SOCRadar reports 86,644 working credential entries across 194 countries. SecurityWeek independently reported that researchers Kevin Beaumont and Hudson Rock validated recent working logins with some affected organizations, and that Huntress identified 845 affected partner organizations in its own data. Those reports support the campaign’s operational significance, but the precise global total and the Russian-speaking attribution should still be attributed to the reporting, not presented as a vendor-confirmed victim count. SOCRadar’s report and SecurityWeek’s reporting provide the available public detail.

Fortinet’s previous analysis of password-spraying activity reached the same practical conclusion: exposed management ports and weak single-factor credentials are enough to create initial access without exploiting a new vulnerability. MFA, trusted-host restrictions or local-in policies, and removing Internet-facing administrative access are the relevant controls. Fortinet’s guidance is unusually direct on the central point: an exposed management plane with a reusable password is an attack path.

Why a firmware update is necessary but insufficient

Firmware currency still matters. Historic FortiOS SSL-VPN flaws have had a long operational afterlife: for example, CVE-2018-13379 remains in CISA’s Known Exploited Vulnerabilities catalog. The flaw allowed unauthenticated path traversal on affected FortiOS and FortiProxy versions, and CISA records it as actively exploited. NVD’s entry links both the affected versions and the KEV record.

But patching closes a software flaw. It does not invalidate a password copied before the patch, remove an unauthorized local account, undo a changed VPN policy, or tell you whether that credential was used elsewhere. That is why an alert about exposed FortiGate credentials belongs in incident response and identity management as well as vulnerability management.

The practical attack path

The path does not require a zero-day:

  1. An attacker finds a public FortiGate administrative interface or SSL-VPN portal.
  2. They try reused, leaked, or sprayed credentials until one succeeds.
  3. With privileged access, they add an administrator or VPN user, alter configuration, or schedule a script for persistence.
  4. They use VPN access, directory integration, or trusted network position to move into internal systems.

Fortinet specifically advises looking for unexpected administrator access, unauthorized users, suspicious VPN configuration changes, and scheduled scripts. It also warns that an integrated AD/LDAP account should be treated as compromised if evidence points to appliance compromise, because that identity may be useful beyond the firewall. See Fortinet’s indicators and recovery guidance.

When the firewall becomes the credential collector

The newer SOCRadar whitepaper adds an important post-compromise stage. Its researchers describe a custom Go tool, FortigateSniffer, deployed after attackers gained access to a FortiGate. According to SOCRadar, the tool abuses FortiOS’s built-in diagnose sniffer packet command to passively capture authentication traffic across 24 protocols, then extracts credentials, hashes, tickets, cookies, and other identity material from those flows.

This changes the incident scope. The 86,644 figure cited earlier in this article refers to reported working FortiGate and SSL-VPN credential entries. SOCRadar’s later claim of more than 110 million credentials across 659 harvesting cycles describes downstream material collected from traffic passing through compromised devices, including RADIUS, NTLM, and Kerberos material. It does not mean that 110 million FortiGate administrator passwords were exposed.

SOCRadar’s assessment is that the operation has been active since at least February 2026 and follows a five-stage chain: reconnaissance, credential stuffing or brute force, sniffer deployment, offline hash cracking, and targeted data theft or session-cookie replay. Treat the scale, tooling, and attribution in that report as researcher findings. Fortinet’s public PSIRT analysis remains the authoritative source for the vendor’s position that the initial access did not rely on a new FortiGate vulnerability.

First hour: contain without destroying evidence

If an internal exposure check, threat-intelligence provider, or investigation identifies a device or credential, appoint an incident owner and preserve evidence before making broad changes.

  • Export FortiGate event, system, VPN, and administrator login logs to storage the appliance cannot modify. Record the current configuration and firmware version.
  • Restrict management access immediately. The strongest option is to remove it from Internet-facing interfaces and use an internal or out-of-band management path. If that cannot happen immediately, restrict source addresses with trusted hosts or a local-in policy.
  • Disable suspected accounts and sessions. Rotate local administrator passwords, SSL-VPN credentials, API tokens, IPsec pre-shared keys, and service credentials stored on or used by the firewall.
  • If the appliance uses AD/LDAP, reset or disable the involved directory account and hunt for its authentication activity in the directory, VPN, and identity-provider logs.
  • Do not simply restore the old configuration after a password reset. Review it for unauthorized accounts, VPN settings, automation stitches, scheduled scripts, and policy changes first.

Changing credentials before preserving logs can erase the timeline you need to determine whether the attacker only tested access or moved into the network. Containment should be fast; it should not be blind.

What to hunt for

Centralize FortiGate logs and correlate them with identity, VPN, endpoint, and network telemetry. Prioritize the period from the earliest suspicious login, not the date the report reached your team.

SignalWhy it mattersWhere to check
Successful admin login from an unfamiliar source or countryMay indicate initial appliance accessFortiGate administrator and system events
New or renamed administrator, local user, or VPN userCommon persistence or access expansionConfiguration history and authentication logs
Changes to SSL-VPN, IPsec, local-in policies, or trusted hostsCan create a durable re-entry routeConfiguration backups and event logs
New scheduled script or automationCan retain control using native featuresAutomation and script configuration
Unexpected administrator CLI activity or diagnostic packet captureA compromised appliance can be repurposed to observe authentication trafficAdministrator-session logs and any externally collected CLI-command audit telemetry
Directory logons by the firewall integration account from unusual systemsSuggests identity reuse beyond the applianceAD/LDAP and identity-provider logs

Fortinet has published two IP addresses as indicators for the campaign discussed in its March 2026 post: 212.11.64.250 and 185.196.11.225. Use them as pivots, not as a clean bill of health; an absence of these IPs does not rule out compromise. Fortinet’s post also lists example unauthorized account names observed in that investigation.

Hardening that changes the outcome

The durable fix is to reduce the number of ways a public system can accept a password.

  1. Separate management from remote access. Do not expose the administrative GUI or SSH on a public interface. If remote administration is required, use a controlled management network and source restrictions.
  2. Require MFA for every externally reachable administrative and remote-access workflow. Password complexity reduces guessing; MFA reduces the value of a stolen password. Neither compensates for an exposed, unmonitored management service by itself.
  3. Use unique, named accounts. Remove unused accounts, eliminate shared administrator credentials, and ensure break-glass accounts are tightly controlled and monitored.
  4. Maintain an edge-device inventory. Record public IPs, enabled services, owners, firmware, authentication method, and log destination. This turns emergency exposure notices into a lookup rather than a scavenger hunt.
  5. Keep a tested recovery procedure. Define when to isolate the device, how to rebuild from a known-good configuration, which credentials must be rotated, and how to validate that logs are still reaching an external collector.

The FortiBleed report may evolve as more evidence becomes public. The defensive lesson will not: once an attacker can authenticate to your edge device, your incident has already moved beyond patch management.

Sources