If you run a FortiGate at the edge of your network, stop reading in a minute and go check your admin accounts. A live campaign called FortiBleed, chained with an authentication bypass tracked as CVE-2026-24858, has been quietly harvesting verified administrator credentials from internet-facing firewalls across 194 countries. This is not a theoretical CVE waiting for proof-of-concept code. Attackers were already inside devices, creating local admin accounts, before most people had heard the name.

I manage perimeter devices for multiple sites, and this one made me re-audit every edge box I touch. Below is what happened, why it matters far beyond Fortinet, and the concrete steps to take today.

What actually happened

CVE-2026-24858 is an authentication bypass with a CVSS score of 9.4, tied to FortiOS single sign-on (SSO). It does not only affect FortiGate — FortiManager and FortiAnalyzer are in scope too, which matters because those are the boxes you use to centrally manage everything else.

The scary part is the timeline. On 20 January 2026, customers reported attackers creating new local admin accounts despite running the then-latest FortiOS. In other words, being fully patched at the time was not enough — this was a zero-day. Two malicious FortiCloud accounts used in the attack were locked out on 22 January 2026. Fortinet then began patching.

The broader FortiBleed campaign exposed verified administrator credentials for internet-facing FortiGate firewalls across 194 countries. Related exploited CVEs in the same cluster include CVE-2025-59718 and CVE-2025-59719. Separately, Amazon Threat Intelligence observed a parallel campaign between 11 January and 18 February 2026 using AI-assisted tooling to enumerate exposed management ports and attempt credential-based access.

Severity, deadlines and fixed versions

This got official attention fast. CISA added CVE-2026-24858 to its Known Exploited Vulnerabilities (KEV) catalog on 27 January 2026, with a federal remediation deadline of 30 January 2026. When CISA gives you three days, that tells you everything about how actively it is being exploited.

Fortinet patched the flaw in FortiOS v7.6.6. The recommended fixed branches are:

• 7.2.11 or later
• 7.4.8 or later
• 7.6.1 or later
• 8.0

If you cannot patch immediately, the interim workaround is clear: disable FortiCloud SSO on any device where it is enabled. That closes the specific door being used while you schedule the upgrade.

Why this matters beyond Fortinet

Here is the part I want every network person in the Gulf to internalize. The specific bug is Fortinet's, but the underlying problem is universal: we put too much trust and too many credentials at the perimeter, and we expose the management plane to the internet.

A firewall admin panel reachable from any IP is a standing invitation. It does not matter if the box says Fortinet, MikroTik, Cisco, pfSense or SonicWall. A mistake I keep seeing on networks I get called in to fix is a management interface — HTTPS admin, SSH, or a VPN portal — listening on the WAN with nothing but a password in front of it. When a bypass like this lands, that password stops mattering entirely, and the attacker walks in and creates their own admin account.

The AI-assisted scanning campaign makes this worse. Exposed management ports are being enumerated at scale, automatically. If your device is findable, assume it has already been probed.

Immediate actions for firewall admins

If you own FortiGate, FortiManager or FortiAnalyzer devices, do these in order:

1. Upgrade FortiOS to a fixed branch (7.2.11+, 7.4.8+, 7.6.1+, or 8.0). If you are on 7.6, target v7.6.6 specifically.
2. Disable FortiCloud SSO right now if you cannot patch this hour.
3. After upgrading, log in as every administrator at least once. This is not optional. The login forces PBKDF2 password encryption. Until you do, previous SHA-256 hashes remain stored in a hidden 'old-password' setting that is visible in a super_admin config backup — which means a stolen backup still leaks recoverable credentials.
4. Rotate every credential on the device, and crucially rotate any LDAP/Active Directory accounts connected to the firewall. If the firewall was breached, those bind accounts are compromised too.
5. Hunt through your logs. Look at FortiGate logs, SSL VPN logs, and your AD/domain controller logs for off-hours logins and unexpected local admin accounts. The attackers' signature was creating new local admins — search for exactly that.

Vendor-neutral hardening lessons

Whatever brand sits at your edge, these principles apply. This is how I harden multi-branch networks so that a single vendor CVE does not become a company-wide breach.

Restrict the management plane

The admin interface should never answer the open internet. On FortiGate, use local-in policies to limit admin access to trusted internal IP ranges. On other platforms the feature has a different name, but the principle is identical: management access from named source addresses only, ideally over an out-of-band or dedicated VPN.

Enforce phishing-resistant MFA

Passwords alone are finished at the perimeter. Enforce phishing-resistant / FIDO2 MFA on every administrative login. Note the honest limitation: an authentication bypass like this one can sidestep MFA at the protocol level — but MFA still blocks the far more common credential-reuse and stolen-password attacks, so it stays mandatory.

Rotate credentials on a schedule, not on panic

Build credential rotation into your routine, and always include the AD/LDAP service accounts your edge devices bind with. In one deployment I worked on, the firewall password was solid but the LDAP bind account had not been changed in years — that account was the real prize.

Threat-hunt continuously

Ship firewall, VPN and domain controller logs somewhere you actually read them. Off-hours admin logins and surprise admin accounts are the earliest signals you will get.

Field checklist: audit your own edge devices

• Is any admin interface (HTTPS/SSH/VPN portal) reachable from the WAN? Close it or lock it to trusted IPs.
• Is SSO enabled and does it need to be? If unsure, disable it.
• Are all firmware versions on a vendor-supported, patched branch?
• Have all admins logged in post-upgrade to force secure password hashing?
• Have you rotated firewall and connected LDAP/AD credentials?
• Is MFA enforced on every admin account?
• Are logs from firewalls, VPN and domain controllers centralized and reviewed for off-hours activity and new local admins?

FortiBleed will fade from the headlines, but the lesson will not. Your firewall is only as strong as its most exposed management interface. Treat the edge as hostile territory, keep the management plane private, and rotate the credentials that a breach would hand over. Do that, and the next vendor CVE becomes a scheduled maintenance task instead of an emergency.

References

• Fortinet Patches CVE-2026-24858 After Active FortiOS SSO Exploitation Detected
• Fortinet starts patching exploited FortiCloud SSO zero-day (CVE-2026-24858) — Help Net Security
• Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries — Arctic Wolf
• FortiBleed: Default Credential Exploitation and Mass Fortinet Compromise — Cloud Security Alliance
• CVE-2026-24858 Detail — NVD (NIST)
• FortiBleed Attack 2026: Is Your FortiGate Firewall at Risk? — Hassium Solutions

Image: DaveHabben — BY (via Openverse)