CVE-2026-35616: FortiClient EMS Under Active Exploitation — The Pre-Auth Bypass Turning Endpoint Management Into an Intrusion Vector

When an authentication bypass vulnerability hits an edge device — a firewall, a VPN concentrator — the damage is severe but bounded: the attacker gets into the network. When the same class of vulnerability hits the enterprise endpoint management console, damage is an order of magnitude greater: the attacker does not enter the network, they inherit it. CVE-2026-35616 belongs to the second category, which is why Fortinet released an out-of-band patch and why CISA and international partners accelerated their advisories.

The vulnerability, rated CVSS 9.1, is described as a pre-authentication API access bypass leading to privilege escalation. In practice: an unauthenticated attacker able to reach the FortiClient EMS API can craft requests that make them recognized as administrator, bypassing authentication, and from there execute unauthorized code or commands in the service context. First in-the-wild exploitation attempts were recorded on March 31, 2026 — before public disclosure, a sign that at least one attacker cluster had advance access to the information.

What FortiClient EMS Is and Why the Vulnerability Is So Severe

FortiClient Enterprise Management Server (EMS) is the central platform through which organizations adopting the Fortinet ecosystem manage the FortiClient endpoint agent. Through EMS pass agent deployment, policy management (VPN access, antivirus posture, application control), endpoint telemetry collection, and centralized fleet compliance visibility. It is, in other words, the control panel through which thousands or tens of thousands of corporate workstations and laptops are managed.

This architectural position explains why CVE-2026-35616 is particularly dangerous. An attacker gaining code execution on the EMS server has not breached an endpoint: they have taken command of the console that distributes policies, scripts, and (in some configurations) software to all managed endpoints. The natural exploitation trajectory does not stop at EMS — it propagates to the underlying endpoints via the legitimate management channel, leveraging the pre-established trust agents have toward the management server. This is the same pattern seen in Kaseya (REvil ransomware, 2021), SolarWinds (2020), and most recently in the Stryker-Handala case with Microsoft Intune (documented by AEGIDA on April 9, 2026).

Anatomy of the Bypass: When the API Recognizes an Admin Without Credentials

Fortinet's public description and intelligence partners' advisories (Arctic Wolf in particular) converge on a dynamic typical of this bug class: the EMS API surface includes a code path where authentication check is performed after some request parameters are interpreted. An attacker crafting a specifically malformed request can cause the process to skip the authentication gate and proceed directly to management operations, which by default require administrative privileges.

This is not the first bug of this family for EMS: in 2024, CVE-2024-48887 had already shown that the console API stack presented analogous fragilities. The recurrence suggests the console attack surface has not received the same hardening attention as the FortiGate firewall, despite playing an architectural role of equal or greater criticality. It is a structural industry problem for EDR/XDR: management consoles grow in functionality very quickly (cloud integration, automation APIs, third-party connectors), and the rate of critical vulnerability discovery follows.

Exploitation: What an Attacker Does After the Bypass

The observed or plausible attack chain, based on analogous campaigns, proceeds in five phases. First: the API bypass to obtain admin role without credentials. Second: enumeration of the managed endpoint fleet — host list, users, OS versions, applied policies, EDR state. Third: creation of a policy or deployment script that executes an arbitrary payload on target endpoints, leveraging the legitimate agent-console channel. Fourth: activation of the policy on a subset of high-value endpoints (domain servers, sysadmin workstations, developer endpoints). Fifth: trace removal — log modification, temporary alert rule deactivation, creation of persistent access independent of EMS to survive the patch.

In mature scenarios, such as those documented in Handala and CyberAv3ngers campaigns, the window between initial intrusion and observable impact can be days or weeks: the attacker uses time to map the network, harvest credentials, identify critical financial or operational systems, before activating the final stage (data exfiltration, ransomware, wiper, or combination). A defender who discovers compromise only at the final stage has already lost: all detection and response work then concentrates on damage mitigation, not prevention.

• Phase 1 — Pre-auth API bypass on EMS (CVE-2026-35616)
• Phase 2 — Enumeration of endpoint fleet, users, policies, EDR state
• Phase 3 — Malicious policy/script propagated via legitimate channel
• Phase 4 — Activation on high-value endpoints (DC, admin workstation, dev)
• Phase 5 — Trace removal + persistence independent of EMS

Who Is Exposed and Why the Patch Alone Is Not Enough

Every organization exposing the FortiClient EMS admin interface to the Internet — to manage remote endpoints, for admin access from outside the corporate network, or out of configuration laziness — is in the first risk tier. Internet-wide scanners have already identified thousands of exposed EMS instances, and the service fingerprint is reliably recognizable. Even organizations placing EMS behind a reverse proxy or VPN must evaluate the scenario in which an attacker accesses the VPN with compromised credentials (via phishing, password spraying, or other bug) and then exploits CVE-2026-35616 from within the administrative network.

The out-of-band patch is necessary but not sufficient. If an instance was reachable on the Internet between March 31 (first observed exploit) and the update, it must be treated as potentially compromised. This mandates a forensic investigation: analysis of API logs for anomalous requests on admin endpoints before the patch, comparison of active policies vs. expected ones, search for admin accounts created or modified during the exposure window, verification of deployment scripts executed on managed endpoints. Only after this verification can the patch be considered incident-closed; otherwise you are closing the entry door while the attacker is still inside.

Operational Recommendations

1. 1.Immediate application of Fortinet's out-of-band patch to all FortiClient EMS instances. Do not wait for the maintenance window: this patch is a priority comparable to an active incident.
2. 2.Exposure audit: check if the EMS management interface has been reachable from the Internet at any point from March 31, 2026 onward. Use Shodan, Censys, or internal scanners to confirm.
3. 3.Forensic investigation of potentially exposed instances: review API logs, modified policies, admin accounts, deployment scripts sent to endpoints during the vulnerable period.
4. 4.Isolation of the management console from the user network: EMS must live on a dedicated administrative segment, accessible only via authenticated bastion host with phishing-resistant MFA.
5. 5.Deployment policy review: every active policy must trace back to an approved change ticket. Any anomaly must be treated as potential compromise until proven otherwise.
6. 6.Rotation of admin credentials used on EMS and connected systems (AD, certificate authority, SCCM if integrated).
7. 7.Activation of alerts on EMS policy modifications and unplanned mass deployments — a control underused in many installations.
8. 8.Threat hunting on managed endpoints: look for anomalous process executions from FortiClient agent, creation of undocumented scheduled tasks, persistence registry key modifications.
9. 9.Extended segmentation plan: treat every endpoint management console (EMS, Intune, SCCM, Workspace ONE, Jamf) as critical infrastructure on par with domain controllers. Same hardening, monitoring, backup, and restore testing regime.

Conclusion: Management Consoles Are the New Center of Gravity

CVE-2026-35616 is not an isolated case: it is another chapter of a clear 2024-2026 trend, in which attackers have shifted their center of gravity from the single endpoint and the perimeter to centralized management platforms. Kaseya, SolarWinds, Ivanti, ConnectWise, Intune, now FortiClient EMS: the list is long and destined to grow, because the attacker's logic is rational. Why compromise a thousand endpoints one at a time when you can compromise the console that manages them all?

For defenders, the operational consequence is that the traditional mental model — "the firewall protects the perimeter, EDR protects the endpoint, the management console is an admin tool" — must be superseded. The management console is not a tool: it is a critical asset, often the most critical on the network, because from its compromise descends the compromise of everything it manages. Hardening, segmentation, monitoring, and patch management on these platforms must be top priority, not routine practice. CVE-2026-35616 is this week's reminder. The next will arrive soon.