What the Fortinet Bypass Tells Us About Trusting the Edge
An authentication bypass does not look dramatic in your logs. That is precisely what makes it dangerous.
When most people picture an attack, they picture noise. Exploit traffic. Alerts. A scanner hammering a port. That mental image is comforting, because it implies you would see it coming. An authentication bypass offers no such courtesy. If the attacker can walk past the sign-on, the resulting activity looks like an administrator doing administrator things. The damage hides inside the ordinary.
The Fortinet FortiCloud single sign-on flaws of the past winter are a clean case study in this, so let me lay out what actually happened and what the attacker behaviour reveals.
The Timeline, Stated Precisely
In December 2025, Fortinet disclosed two vulnerabilities, CVE-2025-59718 and CVE-2025-59719, tracked together as FG-IR-25-647. Both were improper verification of a cryptographic signature. In plain terms, a crafted single sign-on message could let an unauthenticated attacker bypass the login on FortiOS, FortiWeb, FortiProxy, and FortiSwitchManager devices, provided the FortiCloud single sign-on feature was enabled. That feature is not on by factory default, but it is switched on when an administrator registers the device, unless they deliberately turn the toggle off. Many did not.
Exploitation followed disclosure almost immediately. Security firms observed attempts against internet-exposed devices within days, and confirmed intrusions through January.
Then the story took the turn that makes it worth a whole week of content. In late January 2026, Fortinet disclosed a third, separate flaw, CVE-2026-24858, tracked as FG-IR-26-060 and carrying a severity score of 9.4. This one was not a failure to patch. It worked against devices that had been fully updated to address the first two flaws. It was a new path to the same destination. The US Cybersecurity and Infrastructure Security Agency added it to its Known Exploited Vulnerabilities catalogue, with a remediation deadline for federal agencies.
A Known Exploited Vulnerabilities listing is not a suggestion. It does not mean interesting. It means known exploited. It is not a vibes-based advisory to file away for the next quiet maintenance window.
What the Attackers Actually Did
This is the part security teams should study, because it tells you where to look.
On affected devices, the observed malicious activity included unauthorised changes to firewall configuration, the creation of new accounts, and changes to virtual private network settings that granted those new accounts access. In several confirmed cases, this happened on devices already patched against the earlier flaws.
Read that list again and notice what is absent. There is no dramatic exploit payload in the description. There is no ransomware in the first move. There is configuration change and account creation: the digital equivalent of someone quietly cutting a new set of keys and adding their name to the access list.
Why the Edge Is Such a Prize
Edge devices are attractive to attackers for structural reasons, not fashion. They sit before the internal network. They usually face the internet. They are trusted by design, which is the whole point of them. And they frequently have weaker telemetry than the laptops and servers behind them, because organisations instrument their endpoints and forget their appliances.
They also hold useful intelligence even before any ransomware is deployed. Network ranges. Routing. VPN user lists. Object and policy names. Administrative patterns. Sometimes integrations with directory services. Access to an edge device can support reconnaissance, persistence, credential targeting, and a later, more damaging intrusion. The first login is rarely the last move.
And here is the operational sting. If the path in is authentication bypass, the signal does not sit in exploit traffic. It sits in admin activity. It sits in cloud login traces, configuration changes, and account creation. These are exactly the things most small businesses are not watching. Not watching is not the same as safe. It may only mean nobody was looking.
Patching Closes the Hole, It Does Not Rewind Time
The single most important sentence for any business responding to a flaw like this: patching is not a time machine.
Applying the vendor fix closes the known hole. It does not prove that nobody walked through it before you closed it. After patching an exploited authentication bypass, the necessary follow-up is investigative, not just remedial. Check administrative accounts. Check for new users. Check configuration changes. Check VPN settings. Check logins. Check cloud account activity. And critically, check whether logging was intact in the first place, because an answer of “we do not keep those logs” is not a technical footnote. It is a business risk disclosure.
How to Turn This Into a Competitive Advantage
Visibility at the edge is a capability you can demonstrate, and most of your competitors cannot.
You can answer the hard question. When a client or insurer asks whether you were exposed to a major edge-device flaw and what you did about it, a documented answer is a trust asset. Silence or fog is the opposite.
You catch the quiet attacks. A business that reviews admin activity and cloud login traces is the business that detects an authentication bypass while it is still a configuration change, not after it becomes an encrypted estate. That detection capability is a genuine market differentiator in a sector where most rely on prevention alone.
How to Sell This to Your Board
Three points framed for decision-makers.
Prevention will sometimes fail, so detection is not optional. The Fortinet case proves that a fully patched device can still be compromised through a new path. A board that funds only prevention has bought a strategy with no second move.
The cost of looking is small; the cost of not looking is the whole incident. Reviewing edge-device logs and admin activity is a modest operational habit. The alternative is discovering the intrusion when the attacker chooses to make it loud.
Evidence is becoming a regulatory and commercial expectation. Regulators, insurers, and customers increasingly ask whether reasonable steps were taken. Log retention and review at the edge is a reasonable step, and an absence of it is now something you have to explain.
What This Means for Your Business
-
Ask whether any of your edge devices were affected by the FortiCloud sign-on flaws, and what was checked before and after any patch. If you do not run Fortinet, ask the same shape of question about whatever you do run.
-
Confirm that management interfaces are not exposed to the internet without a specific, controlled, logged reason. Exposed edge management is the precondition that turns a vulnerability into a breach. See our guidance on keeping remote access off the open internet.
-
Check that logs exist for the systems you would rely on in an incident. Discovering during a breach that the relevant logs were never collected is the worst possible time to learn it.
-
Review administrative accounts on your edge devices. Look for accounts you do not recognise, and remove shared or stale admin accounts. New, unexplained admin accounts are the classic post-bypass artefact.
-
Treat KEV listings as a clock, not a newsletter. When a flaw is added to the Known Exploited Vulnerabilities catalogue, it is being used right now. Ask your provider how they handle KEV entries, covered in more depth in how DragonForce exploited remote management tools.
Attackers exploit gaps, not brand names. The Fortinet flaws were not a story about one vendor being uniquely careless. They were a demonstration of what happens when a trusted edge device fails and nobody is watching the layer behind it. The signal was always there. The question is whether anyone was reading it.
| Source | Article |
|---|---|
| CISA | Guidance on ongoing exploitation of CVE-2026-24858 |
| Fortinet PSIRT | FortiCloud SSO login authentication bypass (FG-IR-25-647) |
| Fortinet | Analysis of single sign-on abuse on FortiOS |
| Rapid7 | Critical Fortinet vulnerabilities exploited in the wild |
| Canadian Centre for Cyber Security | AL25-019: Fortinet FortiCloud SSO bypass advisory |
| Cybersecurity Dive | FortiGate devices targeted with malicious SSO logins |
Related Posts: