FortiClient EMS CVE-2026-35616: Fake Patch Pushes EKZ Infostealer

FortiClient Endpoint Management Server admins have a new reason to revisit an already urgent patch: CVE-2026-35616 is being used to push EKZ Infostealer through trusted endpoint-management workflows. Arctic Wolf said on May 27, 2026, that it observed attackers abusing affected FortiClient EMS deployments to run PowerShell on managed endpoints and deliver a fake Fortinet patch named FortiEndpoint_Patch.exe.^[1]

The bug is not just another exposed admin panel problem. FortiClient EMS is designed to manage endpoint policy and VPN configuration at scale, so a compromised EMS path can become a software-distribution lane. Fortinet’s advisory tracks the issue as FG-IR-26-099, and the CVE record lists FortiClientEMS 7.4.5 through 7.4.6 as affected by improper access control that may let an unauthenticated attacker execute unauthorized code or commands through crafted requests.^[2]^[3]

CISA added the vulnerability to the Known Exploited Vulnerabilities catalog in April, with federal remediation due by April 9, 2026.^[4] The newer Arctic Wolf reporting gives defenders the missing campaign detail: the attacker did not need to compromise every laptop one by one. Once EMS configuration was modified, endpoints that established affected FortiClient VPN workflows could receive script execution that looked like normal management activity.

Editorial cartoon of FortiClient EMS distributing a fake patch that leaks credentials to EKZ Infostealer — Patch day gets awkward when the trusted courier is carrying someone else’s bag.

What FortiClient EMS admins should check now

Arctic Wolf reported EMS log behavior worth hunting for, including Certificate not found in request header. followed in real incidents by a certificate-user update line tied to fortinet-ca2. The same report named Tor exit-node logins from 185[.]220.101.15 and 192[.]42.116.14, configuration changes such as remind_upgrade_after, and Remote Access Profile or endpoint-policy edits that inserted malicious scripts.^[1]

On endpoints, the suspicious chain was more concrete: fortitray.exe or ipsec.exe launched cmd.exe, which launched PowerShell, which then downloaded and ran FortiEndpoint_Patch.exe. Arctic Wolf said the script path used GUID-named .cmd files below C:Program FilesFortinetFortiClientlogsTracescripts, and that the stealer staged output in ProgramDatalog.txt before HTTP exfiltration to 83[.]138.53[.]110.^[1]

EKZ is dangerous because it targets credentials users already trust their browsers to protect. The stealer supports Chromium-family browsers and Firefox/Gecko-family stores, and Arctic Wolf says it can retrieve saved passwords, cookies, autofill data, credit-card details, addresses, and phone numbers. That makes response larger than removing one binary: organizations should rotate credentials used on affected endpoints, revoke active browser and SaaS sessions where possible, and treat stolen cookies as a potential MFA bypass path.

For immediate containment, update FortiClient EMS to a fixed build or apply Fortinet’s hotfix path, then confirm EMS is not internet-exposed. BleepingComputer noted that Shadowserver had previously seen roughly 2,000 internet-exposed EMS instances, which is a reminder that management planes should not be discoverable from the open web.^[5] Teams that recently reviewed older Fortinet internet-exposure issues should include EMS in that same external-attack-surface sweep.

After patching, compare EMS configuration history with endpoint telemetry. Focus on Remote Access Profile XML, VPN on_connect and script directives, unexpected PowerShell launched by FortiClient processes, and outbound traffic to the reported infrastructure. The response pattern is closer to a supply-chain or management-channel compromise than a single-user malware infection, similar in impact to previous credential-theft cases such as the Laravel-Lang package hijack. For VPN-heavy environments, the lesson also overlaps with recent edge-access incidents like the SonicWall Gen6 MFA bypass attacks: patching the appliance is only the start; session, credential, and policy review decide whether the incident is actually closed.

References