CVE-2026-44277: Fortinet FortiAuthenticator improper access control, patched before exploitation
The short version: Fortinet FortiAuthenticator — the identity, MFA, and RADIUS/SSO appliance — has an improper-access-control flaw (CVE-2026-44277) that could let an unauthenticated attacker reach protected API functionality via crafted requests. Fortinet found it internally and shipped fixes; there's no known exploitation or public exploit yet, and it isn't in CISA's KEV catalog. This is a patch-on-schedule item, not a fire drill — but it guards your identity plane, so don't sit on it. Steady hands.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — serious on paper, but not exploited and freshly patched (see below) |
| CVSS v3.1 (Fortinet CNA) | 9.8 base — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Fortinet's headline 9.1 is temporal-adjusted; NVD analysis pending at time of writing) |
| EPSS | ~0.55% · 42nd percentile (2026-07-17) |
| In CISA KEV? | No — not listed at time of writing |
| Known exploited? | No — discovered internally during a Fortinet audit; no reports of exploitation or public PoC at time of writing |
| Vulnerability type | CWE-284 improper access control → unauthenticated access to protected API functionality |
| Requires authenticated session? | No — reported as pre-authentication |
| Affected | FortiAuthenticator 6.5.0–6.5.6, 6.6.0–6.6.8, 8.0.0–8.0.2 (FortiAuthenticator Cloud not affected) |
| Fixed in | FortiAuthenticator 6.5.7 · 6.6.9 · 8.0.3 and later |
What you need to know
CVE-2026-44277 is an improper-access-control flaw affecting FortiAuthenticator's API handlers: certain protected endpoints could be reached without proper authorization, which Fortinet describes as potentially allowing an attacker to execute unauthorized code or commands via crafted requests.
Two things shape how to read it:
- The target is your identity plane. FortiAuthenticator issues MFA, and brokers RADIUS/TACACS+, SSO, and certificate services. Compromise there has outsized reach — it can undermine authentication for everything that trusts it. That's why we don't shrug this off despite the quiet exploitation picture.
- The exploitation picture is quiet — for now. It was found internally, there's no confirmed in-the-wild activity or public exploit, EPSS is low, and it isn't in KEV. On-premises appliances are affected; the Cloud offering is not.
How serious we see it
High — a case where the honest read sits below the paper score.
On paper this is a 9.8-class flaw on a sensitive appliance. In the real world, it was caught internally, patched before anyone weaponized it, carries a low EPSS, and has no KEV deadline. We rate it High rather than Critical to reflect that gap — the potential impact is real and the appliance is important, but there's no evidence of exploitation and a fix is already in hand. The reassuring, bounded part: a small set of on-prem versions is affected, the fixes are published, and Cloud customers need do nothing. The move here is prompt, scheduled patching — not an emergency scramble.
Recommendations
Straight from Fortinet's advisory (FG-IR-26-128):
- Patch promptly. Upgrade to FortiAuthenticator 6.5.7 / 6.6.9 / 8.0.3 or later.
- If you can't patch immediately, restrict API access. Fortinet's workaround is to limit API access on exposed interfaces (Network → Interfaces → Access Rights).
- Get the appliance off the public internet. An identity broker rarely needs to be internet-facing; restrict it to trusted management networks.
- Watch the identity plane. Given the reach of the appliance, keep an eye on admin activity and API access even absent known exploitation.
- Confirm your exposure first. Verify whether you run an affected on-prem FortiAuthenticator build (Cloud is not affected).
How BreachRisk sees it
BreachRisk discovers internet-facing FortiAuthenticator interfaces from little more than your domain, fingerprints the version, and flags exposure against known-affected builds. Where authorized, it goes beyond detection and safely probes the relevant API paths in a bounded, non-disruptive way to gauge whether protected functionality is reachable, rather than flagging a maybe.
That outside-in view is especially useful for a flaw like this — high potential impact but no exploitation forcing the issue. Having an exposed identity appliance mapped and ranked means it gets patched on its merits, before someone else finds the same endpoints.