CVE-2026-35616: critical Fortinet FortiClient EMS flaw

CVE-2026-35616 is a critical API access-control flaw in Fortinet FortiClient EMS. An unauthenticated attacker may use crafted requests to execute unauthorised code or commands. Fortinet confirms exploitation in the wild, and CISA added the flaw to KEV on 6 April 2026.

The sources display two CVSS values: Fortinet’s current PSIRT page shows 9.1, while the CNA record displayed by NVD contains 9.8. A reliable article should disclose that discrepancy rather than select the more dramatic number. Both are critical, and confirmed exploitation matters more operationally than the scoring difference.

What the problem is

FortiClient EMS centralises FortiClient endpoint management, policy and telemetry. A management-server compromise can therefore have broader consequences than loss of one workstation. The official advisory maps the issue to CWE-284, Improper Access Control, and records an external unauthenticated attack.

Do not attach unrelated CVE identifiers merely because they also concern EMS. The response plan should come from FG-IR-26-099: affected versions, the vendor hotfix and confirmed attacker activity.

Affected releases and fixes

Fortinet states that FortiClient EMS 7.4.5 and 7.4.6 are affected. The 7.2 branch is not affected according to the advisory. Apply the release-specific hotfix or upgrade to 7.4.7 or later when available in the relevant channel. Fortinet remediated FortiClient Cloud and FortiSASE, so those customers do not perform the local EMS action.

Inventory must distinguish on-premises EMS, the cloud service and FortiSASE. Using the FortiClient brand does not by itself establish exposure. For local servers, record version, build, API and administration exposure, and hotfix installation time.

What to do

1. Download the hotfix only from the channel specified in FG-IR-26-099 and match it to 7.4.5 or 7.4.6.
2. Back up configuration and prepare rollback.
3. Install the hotfix or move to a fixed release, then verify build and endpoint communication.
4. Restrict sources allowed to reach the EMS API and console. Public exposure should not be the default.
5. Preserve pre-update logs and investigate if an attacker could reach the vulnerable server.

Investigating the exposure window

Patching closes the vulnerability but does not remove an earlier compromise. Determine when the server ran an affected release and which networks could reach it. Preserve application, operating-system, proxy, WAF and EDR logs. Review accounts, configuration, processes, services, scheduled tasks and outbound connections for deviations.

Blindly rotating every secret can disrupt operations, while narrow rotation may leave attacker access intact. Identify credentials and keys stored on, or reachable from, the server. Rotate by risk and monitor attempts to use old values. Where evidence confirms compromise, rebuilding from a trusted source is stronger than deleting isolated artefacts.

Closure evidence

Close remediation only after collecting four items: a safe build or hotfix, a functional test, restricted exposure and a security review covering the vulnerable period. Verify that backups and deployment templates cannot restore the old release.

The broader lesson

Security appliances and servers (VPNs, firewalls, management consoles) are concentrated, high-value targets — one compromise grants access to many systems. So treat them with the highest patching priority and keep them off the public internet. The same “active exploitation first” principle recurs in our piece on vulnerability prioritisation, and fast patching of edge systems is one of the pillars of defence against ransomware.

If you’d like to review the exposure of your edge systems, get in touch.

---

Sources: Fortinet PSIRT FG-IR-26-099, CISA KEV — CVE-2026-35616, NVD — CVE-2026-35616.