FortiClient EMS flaw exploited to push EKZ infostealer as fake Fortinet patch

Attackers are exploiting a critical FortiClient EMS vulnerability to deliver a newly documented credential stealer disguised as a Fortinet endpoint patch. The campaign targets FortiClient EMS-managed endpoints and turns trusted endpoint management infrastructure into a malware delivery channel.

The activity was detailed by Arctic Wolf Labs, which observed exploitation of CVE-2026-35616 in May 2026. The payload, named EKZ Infostealer by researchers, was delivered as FortiEndpoint_Patch.exe and focused on stealing browser credentials, cookies, and autofill data.

Fortinet previously confirmed that CVE-2026-35616 had been exploited in the wild. The Fortinet PSIRT advisory describes the issue as an improper access control vulnerability that may allow unauthenticated attackers to execute unauthorized code or commands through crafted requests.

What CVE-2026-35616 affects

CVE-2026-35616 affects FortiClient EMS 7.4.5 and 7.4.6. Fortinet says FortiClient EMS 7.2 is not affected, while FortiClient Cloud and FortiSASE have been remediated on the vendor side.

The vulnerability matters because FortiClient EMS is a management plane. It centrally controls FortiClient configurations, endpoint policies, VPN profiles, and other settings across managed devices. If attackers control that platform, they can affect many endpoints without compromising each one separately.

The NVD entry for CVE-2026-35616 lists the flaw as affecting FortiClientEMS 7.4.5 and 7.4.6 and identifies it as CWE-284, improper access control.

Item	Details
CVE	CVE-2026-35616
Product	FortiClient Endpoint Management Server
Affected versions	FortiClient EMS 7.4.5 and 7.4.6
Unaffected branch	FortiClient EMS 7.2
Fixed version	FortiClient EMS 7.4.7 or later
Attack type	Unauthenticated crafted requests

How attackers abused FortiClient EMS

The campaign did not rely on a normal phishing attachment or a separate malware installer sent to each employee. Instead, attackers modified FortiClient EMS configuration and abused the platform’s own management features.

According to watchTowr, exploitation of the flaw was observed before Fortinet published its advisory in April. The same analysis warned that a compromised EMS server could let attackers manipulate endpoint configurations and push malicious policies.

In the later EKZ campaign, attackers changed Remote Access Profile and endpoint policy settings. When affected endpoints established an IPsec VPN tunnel, FortiClient processes launched command scripts from a FortiClient logs directory.

EKZ infostealer was disguised as a Fortinet patch

The malicious scripts launched PowerShell, downloaded a file named p.exe, and ran it on the endpoint as FortiEndpoint_Patch.exe. That filename made the malware look like a legitimate Fortinet update.

The infostealer targeted browser data from Chromium-based browsers such as Chrome and Microsoft Edge, as well as Gecko-based software such as Firefox, LibreWolf, Waterfox, Pale Moon, and Thunderbird.

The Arctic Wolf report says EKZ could extract saved passwords, cookies, and autofill data. Stolen cookies are especially risky because attackers may reuse active sessions and bypass some multi-factor authentication prompts.

• Credential stealer name: EKZ Infostealer
• Local filename: FortiEndpoint_Patch.exe
• Remote filename: p.exe
• Targeted data: browser passwords, cookies, autofill entries, addresses, phone numbers, and payment-related autofill data
• Observed staging file: C:\ProgramData\log.txt
• Observed parent chain: fortitray.exe or ipsec.exe to cmd.exe to powershell.exe

Why this attack is dangerous for enterprises

The attack is serious because it uses a trusted control plane. Endpoint management tools already have permission to push configurations and run approved actions. When attackers hijack that trust, malicious activity can look like normal administration.

That makes detection harder. A security team may not immediately treat FortiClient-launched scripts as suspicious, especially if VPN profile changes appear to come from the legitimate EMS platform.

The risk also grows with scale. One exposed or compromised EMS deployment can create fleet-wide exposure across managed endpoints, especially where many devices receive the same VPN and endpoint policy updates.

Risk area	Why it matters
Management plane compromise	Attackers can affect many endpoints from one EMS server
Trusted process chain	Malware execution may appear tied to normal FortiClient behavior
Browser cookie theft	Attackers may hijack active sessions without needing passwords again
Delayed detection	Legitimate tools and paths can reduce the chance of quick alerts

Fortinet patch guidance

Organizations running FortiClient EMS 7.4.5 or 7.4.6 should upgrade to 7.4.7 or later. The FortiClient EMS 7.4.7 release notes list CVE-2026-35616 under vulnerabilities and exposures fixed in that version.

Fortinet also provided hotfix guidance for affected 7.4.5 and 7.4.6 deployments. However, given the current availability of 7.4.7, teams should plan the upgrade path carefully and confirm version compatibility before making changes in production.

The Fortinet advisory also notes that Fortinet observed exploitation in the wild, which means exposed vulnerable systems should be treated as possible incident response cases rather than simple patch management tasks.

What defenders should look for

Security teams should review EMS logs, endpoint telemetry, VPN profile settings, and FortiClient script paths. The strongest signals combine suspicious management-plane activity with unexpected endpoint script execution.

The NVD vulnerability record also notes that CISA added CVE-2026-35616 to its Known Exploited Vulnerabilities catalog, which reinforces the need for fast remediation.

Organizations should look for unusual administrative changes, logins from Tor or unfamiliar hosting providers, and Remote Access Profile entries that include unauthorized on_connect scripts.

• EMS logs showing certificate authentication anomalies
• Unexpected EMS accounts or configuration changes
• Remote Access Profiles modified with unauthorized script directives
• GUID-named .cmd files in FortiClient script paths
• PowerShell launched by cmd.exe after FortiClient VPN activity
• FortiEndpoint_Patch.exe or p.exe staged on endpoints
• C:\ProgramData\log.txt created and removed shortly after execution
• HTTP traffic to suspicious raw IP infrastructure

Recommended response steps

Companies should first identify every FortiClient EMS instance, confirm the installed version, and determine whether the system was reachable during the exploitation window. Internet-facing management interfaces need urgent review.

Teams should then upgrade affected systems, inspect EMS configuration, audit Remote Access Profiles, and hunt across managed endpoints for the EKZ activity chain. Credentials and browser sessions on affected endpoints should be treated as potentially exposed.

The watchTowr analysis also recommends treating compromised EMS instances carefully, since a management server may no longer be trustworthy after successful exploitation.

Priority	Action
1	Upgrade FortiClient EMS 7.4.5 or 7.4.6 to 7.4.7 or later
2	Restrict EMS management access to trusted IP ranges
3	Audit Remote Access Profiles and endpoint policy changes
4	Hunt for FortiClient-launched PowerShell and suspicious .cmd files
5	Rotate credentials and invalidate sessions from affected endpoints

Bottom line

The EKZ campaign shows how quickly a vulnerability in endpoint management infrastructure can become a fleet-wide malware delivery problem. FortiClient EMS is not just another server. It is a control point for endpoint behavior.

Organizations using FortiClient EMS should confirm their version, upgrade vulnerable deployments, and inspect both the server and managed endpoints for signs of compromise.

The FortiClient EMS 7.4.7 release notes provide the current fixed-version reference, but defenders should also review logs and rotate exposed credentials if EKZ activity appears in their environment.

FAQ