Fortibleed

Worth saying clearly up front: FortiBleed is not a new Fortinet vulnerability and there is no patch that fixes it. It is a credential-compromise campaign that reuses passwords leaked from earlier Fortinet incidents, infostealer logs and config dumps against internet-exposed devices. So the remediation is hardening the management plane, rotating credentials, and verifying the device was not already compromised. Concretely, have the customer do the following.

Take all management access off the internet. The admin GUI (HTTPS) and SSH should not be reachable from the WAN at all. Administration happens over VPN or from the internal network only. This single step removes the device from the scan-and-stuff surface the campaign relies on.

Lock down the management plane with local-in policies and trusted hosts. Even where a service has to listen, restrict it to known internal source IPs or the management VPN range, so the box does not answer admin or VPN requests from the public internet. Local-in policies are the right tool because they filter traffic destined to the FortiGate itself, which normal firewall policies do not.

Enforce MFA on every account, all users and all admins, with no exceptions. Most of the successful logins in this campaign were plain username and password against admin or default accounts, so MFA on the admin and VPN logins breaks the attack even if a credential is known. Move admin login to SAML or FortiToken, and require MFA on SSL VPN and IPsec dial-up users.

Rotate all credentials now and clean up accounts. That means admin accounts, local users, SSL VPN and IPsec users, API keys and pre-shared keys. Remove default and generic accounts, disable anything unused, and enforce unique strong passwords. Assume any credential that ever sat on an internet-facing device is already in the attacker's list.

Investigate for compromise, do not just change passwords. Review the admin login history, look for unknown admin accounts, unexpected configuration changes, logins from unusual geographies, and any automation stitches or scripts you did not create. If management or SSL VPN was exposed with old or weak credentials, treat the device as already breached and run a proper cleanup, since the attackers use compromised devices as listening posts to harvest more credentials.

Reduce SSL VPN exposure. Where possible move remote access from SSL VPN to IPsec, which also lines up with Fortinet removing SSL VPN tunnel mode from 7.6.3 onward.

Run a current, Fortinet-recommended release. That is 7.6.7 at the moment. It will not fix FortiBleed by itself, but it closes the older config-disclosure and credential-exposure issues that fed these password lists in the first place.

Opening a ticket was the right move, but do not expect Fortinet to ship a fix here. The mitigation is on the configuration and credential side, and for any device that was internet-exposed with weak or reused credentials, the safe assumption is compromise, not a clean reset.

Thank you Christian.