FortiClient EMS Zero-Day CVE-2026-35616: Patch to 7.4.7 and Hunt for Compromise

If you run Fortinet across your endpoint estate, stop what you are doing and check your FortiClient EMS build. Fortinet disclosed CVE-2026-35616, a critical zero-day in FortiClient EMS (Enterprise Management Server) that is being exploited in the wild. It was a true zero-day — attackers were hitting it before Fortinet shipped a fix — and although the patched build (7.4.7) is now available, any organisation still running an unpatched EMS is sitting on a known, weaponised flaw. That exposure window is exactly what attackers count on.

This is not a peripheral bug. EMS is the brain that manages your FortiClient fleet. A flaw there is not a single-endpoint problem; it is a route to mass compromise. Below is what is confirmed, who is exposed, and the action list to close the door this week.

What FortiClient EMS is — and why a flaw here is worse than a normal CVE

FortiClient EMS is Fortinet’s central console for managing endpoints running the FortiClient agent. It pushes security policy, governs VPN access, enforces compliance posture, and orchestrates the agents sitting on laptops, servers, and workstations across the organisation. In other words, it is privileged infrastructure that talks to everything.

That centrality is what makes CVE-2026-35616 dangerous. Compromise a single laptop and you have a foothold. Compromise the server that manages every laptop and you potentially own the policy layer for the entire endpoint fleet — the ability to alter configurations, push malicious or weakened policy, harvest credentials, and pivot laterally into the wider network. A management plane is a force multiplier for an attacker, and EMS is squarely a management plane.

What we know about CVE-2026-35616

According to Fortinet’s PSIRT advisory and corroborating reporting, the vulnerability is an improper access control / authentication-and-authorization bypass issue. Help Net Security characterised it as an API authentication and authorization bypass that can let an unauthenticated attacker run unauthorized code or commands through crafted requests. Several outlets, including The Hacker News and CyberScoop, described the practical impact as unauthenticated remote code execution.

On severity: the CVSS score has been reported inconsistently across sources. CyberScoop and The Hacker News cited 9.8; Tenable and NHS England’s cyber alert cited 9.1. Either way it sits firmly in the critical band — treat it as such and do not let the exact decimal delay your patching. Confirm the authoritative score and any update against the Fortinet PSIRT advisory FG-IR-26-099 directly.

On exploitation: this was a genuine zero-day. watchTowr reported that its sensors observed exploitation attempts as early as 31 March 2026, ahead of Fortinet publishing its advisory on or around 4–5 April. Fortinet has confirmed exploitation in the wild. CyberScoop reported that initial probing was limited but that activity ramped up around 6 April once the flaw drew attention and the hotfix appeared. CISA added CVE-2026-35616 to its Known Exploited Vulnerabilities (KEV) catalog, with a remediation deadline set for US federal civilian agencies — a strong signal that everyone else should move with the same urgency.

Patch status: the fix is out — update to 7.4.7

The affected versions are FortiClient EMS 7.4.5 and 7.4.6, and Fortinet has fixed the flaw in FortiClient EMS 7.4.7. At disclosure Fortinet shipped an emergency hotfix and then the full fixed build, so the remediation is now generally available. CISA added CVE-2026-35616 to its Known Exploited Vulnerabilities catalog with an early-April 2026 deadline for US federal agencies — a clear signal that the fix existed and that patching was urgent. If you are still on 7.4.5 or 7.4.6, you are running a known-exploited build: upgrade now.

Always confirm against the source. Open FG-IR-26-099 on the Fortinet PSIRT site to confirm the exact fixed build and upgrade path for your version before you act — do not rely on this summary alone for your remediation decision.

Who is exposed

Any organisation running an affected FortiClient EMS build — particularly one with its management interface reachable from the internet. EMS is common in mid-to-large Indian enterprises, MSPs managing client fleets, and any team that standardised on the Fortinet stack for endpoint and VPN management. If your EMS console is internet-facing for the convenience of remote administration, assume you are in the line of fire and treat the box as potentially probed.

Action list — do this now

1. Apply the hotfix or fixed build per PSIRT

Confirm your installed EMS version, then upgrade to FortiClient EMS 7.4.7 or later (or apply the hotfix Fortinet specifies in FG-IR-26-099 for your build). This is the only step that actually fixes the vulnerability; everything below reduces blast radius but does not close the hole.

2. Take the management interface off the internet

EMS administration should never be exposed to the open internet. Restrict the management interface to a VPN, jump host, or trusted IP allow-list. If you cannot patch immediately, this is your single most effective interim control against unauthenticated exploitation.

3. Network-segment the EMS server

Place EMS in a tightly controlled management segment with strict egress filtering. A management server should not be able to reach the internet freely or talk to arbitrary internal hosts. Segmentation limits how far an attacker can pivot if the box is already compromised.

4. Hunt for compromise — do not assume you patched in time

Because exploitation predates the advisory, patching alone is not “case closed.” Review EMS logs for anomalous API requests, unexpected admin sessions, new or modified policies, unfamiliar accounts, and unusual outbound connections from the server. Check endpoints for policy changes you did not authorise. If you have an MDR or SOC capability, scope a targeted hunt around this host now — and if you are weighing whether you even have the right monitoring in place, our breakdown of MDR vs SOC vs SIEM for Indian SMBs is a useful starting point.

5. Enforce MFA on all admin access

Require multi-factor authentication for every administrative login to EMS and to the infrastructure around it. It will not stop an unauthenticated bypass on its own, but it raises the cost of credential-based follow-on activity and post-exploitation lateral movement.

The 2026 pattern: edge and management appliances keep getting hit

CVE-2026-35616 is not an isolated incident — it fits a relentless 2026 pattern of zero-days in Fortinet and other edge and security-appliance products. VPN gateways, firewalls, management consoles: the very devices we deploy to protect the perimeter have become the perimeter’s softest targets, because they are internet-facing, highly privileged, and slow to patch.

The lesson is a structural one. Edge and management appliances need their own patch SLA — measured in hours, not the weeks you might tolerate for an internal app — plus dedicated monitoring and an explicit rule that their admin planes never face the public internet. If your patch process treats a FortiClient EMS the same as a marketing CMS, this class of bug will keep catching you out. Build the appliance tier into your VAPT scope and your asset inventory deliberately; our VAPT services exist precisely to find this exposure before an attacker does.

If you have been breached: the CERT-In clock is running

If your investigation turns up evidence of compromise, remember that India’s reporting obligations are tight. Under the CERT-In directions, in-scope cybersecurity incidents must be reported to CERT-In within 6 hours of noticing or being made aware of them. Build that timeline into your incident-response runbook now, before you need it — see our CERT-In direction guide for what counts as a reportable incident and how to file.

Frequently Asked Questions

Is there a patch for CVE-2026-35616?

Yes. Fortinet fixed the flaw in FortiClient EMS 7.4.7 and issued an emergency hotfix for affected 7.4.5/7.4.6 builds. Upgrade to 7.4.7 or later as specified in the Fortinet PSIRT advisory FG-IR-26-099. Because the flaw was exploited as a zero-day before the fix shipped, also hunt for signs of prior compromise after patching.

We patched. Are we safe?

Patching closes the vulnerability, but it does not undo a compromise that may have already happened — exploitation was observed before the advisory was published. After applying the hotfix or fixed build, hunt for signs of prior intrusion in EMS logs, admin sessions, and pushed policies, and watch your managed endpoints for unauthorised changes.

What is the single most important interim step if we cannot patch today?

Remove the EMS management interface from the public internet. The vulnerability is exploitable by an unauthenticated remote attacker, so restricting access to a VPN, jump host, or IP allow-list dramatically cuts your exposure while you schedule the fix and run a compromise hunt.

Fortinet zero-days are now a recurring fixture, and a flaw in the server that manages your entire endpoint fleet is about as high-stakes as it gets. If you are unsure whether your FortiClient EMS is exposed, whether you have already been touched, or how to fit edge-appliance patching and monitoring into a defensible process, talk to RingSafe. We will help you triage CVE-2026-35616 exposure, hunt for compromise, and put a patch SLA in place so the next edge zero-day does not catch you flat-footed.