CVE-2026-35616: Fortinet FortiClient EMS improper access control, exploited as a zero-day
The short version: Fortinet FortiClient EMS — the central endpoint-management server — has an improper-access-control flaw (CVE-2026-35616) that lets an unauthenticated attacker bypass API authorization and execute commands. It was exploited as a zero-day before Fortinet's advisory, and CISA added it to KEV with an unusually short three-day remediation window. If you run EMS 7.4.5 or 7.4.6, this is patch-and-hunt right now. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| 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 | ~89% · 99.76th percentile (2026-07-17) |
| In CISA KEV? | Yes — added 2026-04-06; remediation was due 2026-04-09 (accelerated three-day deadline) |
| Known exploited? | Yes — exploited as a zero-day; activity observed from ~2026-03-31, before Fortinet's advisory |
| Vulnerability type | CWE-284 improper access control → API authentication/authorization bypass → command execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | FortiClient EMS 7.4.5–7.4.6 (7.2.x and earlier not affected) |
| Fixed in | FortiClient EMS 7.4.7 and later (Fortinet also issued an out-of-band hotfix for 7.4.5/7.4.6) |
What you need to know
CVE-2026-35616 is an improper-access-control flaw in FortiClient EMS. Crafted requests bypass the API's authentication and authorization checks, letting an unauthenticated attacker reach privileged functionality and execute unauthorized code or commands on the management server.
- It's the endpoint-management brain. EMS enforces device policy, governs VPN access, and manages compliance across your fleet. Control of it means the ability to push malicious policy and pivot toward managed endpoints.
- It's pre-authentication and network-reachable wherever EMS is exposed — and many deployments are.
- It was live before the fix. Exploitation was observed roughly a week before Fortinet's advisory, and CISA's three-day KEV deadline reflects how seriously the agency took it — so an exposed server may already have been touched.
How serious we see it
High — unauthenticated command execution on a fleet-management server, exploited as a zero-day.
The combination — pre-auth, network-reachable, code execution on a system that controls your endpoints, with confirmed zero-day activity and an accelerated KEV deadline — is as top-of-queue as it gets. The bounded, reassuring part: only FortiClient EMS 7.4.5–7.4.6 is affected, the fix (and an out-of-band hotfix) is available, and exposure is quick to determine. The catch is the pre-patch window — check for signs of compromise, because a patched EMS isn't automatically a clean one.
Recommendations
Straight from Fortinet's advisory (FG-IR-26-099) and CISA:
- Patch or hotfix now. Upgrade to FortiClient EMS 7.4.7 or later, or apply Fortinet's out-of-band hotfix for 7.4.5/7.4.6 immediately.
- Get EMS off the public internet. Require VPN or strict IP allow-listing for the management interface; segment it onto a management VLAN.
- Hunt for prior compromise. Given the zero-day window, review admin activity, pushed policies, and logs; rotate administrative credentials and keys, and enforce MFA on admin accounts.
- If you find indicators, respond fully. Rebuild where warranted and treat managed endpoints as potentially reachable from the compromised server.
- Confirm your exposure first. Verify whether you run EMS 7.4.5 or 7.4.6 and whether it's internet-facing.
How BreachRisk sees it
BreachRisk discovers internet-facing FortiClient EMS servers from little more than your domain, fingerprints the version, and flags exposure tied to KEV-listed, actively exploited flaws like this one — surfaced at the top of your results because it's in KEV and carries an accelerated deadline. This one is detected by fingerprinting the exposed, affected version and flagging it; we identify and prioritize the exposure rather than exploiting it.
That outside-in, continuous view is exactly what a three-day KEV deadline demands: the exposed server is already mapped and ranked, so you're not inventorying assets while the clock runs.