Skip to content
The Cyber Security Place

A 9.4 in the single sign-on, and the patch did not help

Event dated 21 January 2026 · Published 2 September 2026 · 4 sources

An authentication bypass in FortiCloud single sign-on, tracked as CVE-2026-24858 and scored 9.4, reached active exploitation on 21 January 2026. It affects FortiOS, FortiManager, FortiAnalyzer and FortiProxy, and it granted unauthenticated administrative access in seconds. The detail that matters for anybody running a patching queue: it worked against devices that were already fully patched, because the weakness was in the sign-on path rather than in the firmware those patches update. Reported dwell between disclosure and exploitation was under a week.

Most critical findings are a race. Something is disclosed, an exploit follows, and the organisations that lose are the ones whose queue moved slower than the attacker's. That story is well understood, and the whole apparatus of severity scores and patch windows exists to run it.

This one broke the frame. The devices exploited from 21 January were not behind on updates. They were current, and they were still opened by an unauthenticated request that produced administrative access in the time it takes to load a page. Patching had happened and patching was not the control that mattered, because the flaw sat in how the device decided who you were rather than in the code being patched.

Why an SSO bypass is a different category

Single sign-on exists to move the authentication decision away from each device and into one place that does it properly. The trade is deliberate and normally sound: one well-guarded decision beats a dozen improvised ones. The cost of the trade is that the place doing the deciding becomes load-bearing for everything that trusts it.

When that decision is wrong, nothing downstream can notice. A firewall that has been told the request carries valid administrative authority behaves exactly as designed — it does what the administrator asked. There is no malformed packet, no exploit payload, no signature. The traffic is a successful login followed by legitimate administrative actions, which is what the logs will show afterwards.

What this changes for the queue

Not the ranking, which was already right: exploitation is now the leading route in, and internet-facing appliances take a disproportionate share of it. What it changes is the assumption sitting underneath the ranking — that a device with current firmware is a device you have dealt with.

The practical consequence is narrow and worth doing. For every appliance reachable from the internet, the question is no longer only whether it is patched, but which authentication path reaches its administrative interface and whether that path is exposed at all. An administrative console that is not reachable from outside cannot be bypassed from outside, and that remains true whatever score the next advisory carries.

The second consequence is about detection, and it is uncomfortable. If the compromise presents as a valid administrative session, then the signal is not in the network but in the behaviour: an administrator logging in at an unusual hour, from an unusual place, or making changes nobody requested. That is a harder thing to watch for, and it is the only thing there was to watch.

What is not yet known

The published accounts agree on the score, the affected products and the date exploitation began. They do not establish how many devices were reached, who was behind it, or whether the access was used immediately or held. Anybody stating those numbers this week is estimating, and the estimate deserves the same scepticism as any figure whose original question cannot be recovered.